On 4/06/2014 11:35 AM, Jochen Spieker wrote: > Bob Proulx: >> Andrew McGlashan wrote: >>> [ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds. >> >> This message and the ones that follow seem the most concerning to me. >> >> First, I don't know. If I were having those messages I would suspect >> that my hardware was having problems. Or that the kernel was not >> driving the hardware correctly. A bad kernel driver could do this. > > ACK. Quoting the trace again: > > [ 3839.679749] Call Trace: > [ 3839.679757] [<ffffffffa00bfb2e>] ? wait_barrier+0xd7/0x118 [raid1] > [ 3839.679763] [<ffffffff8103f6e2>] ? try_to_wake_up+0x197/0x197 > [ 3839.679770] [<ffffffffa00c298b>] ? make_request+0x111/0xa5b [raid1] > [ 3839.679777] [<ffffffffa0135712>] ? crypto_aes_decrypt_x86+0x5/0x5 [aes_x86_64] > [ 3839.679784] [<ffffffffa0135712>] ? crypto_aes_decrypt_x86+0x5/0x5 [aes_x86_64] > [ 3839.679791] [<ffffffffa012523a>] ? encrypt+0x3f/0x44 [xts] > [ 3839.679803] [<ffffffffa00d3d47>] ? md_make_request+0xee/0x1db [md_mod] > > What I found interesting is that the kernel hangs at wait_barrier. I > only know the term "barrier" from filesystems. I googled a bit for > barrier+cryptsetup and barrier-md-raid but didn't find anything that > helps. > > Searching for "kernel hang at wait_barrier" revelas a few kernel bugs > that might be related. I guess it's a software problem. Yes, my concern is [and I could be totally wrong] that this is due to btrfs kernel parts -- I know that Oracle /thinks/ that BTRFS is production ready, but I still don't trust it .... even so, parts of btrfs will be in the kernel. Thanks and Cheers A.
Attachment:
signature.asc
Description: OpenPGP digital signature