Re: Kernel lockup, might be helpful log.

Hugo Mills posted on Mon, 14 Dec 2015 08:35:24 + as excerpted: > It's not just btrfs. Invalid opcode is the way that the kernel's BUG and > BUG_ON macro is implemented. Thanks. I indicated that I suspected broader kernel use further down the reply, but it's very nice to have confirmation,

Re: Kernel lockup, might be helpful log.

On Sun, Dec 13, 2015 at 10:55 PM, Birdsarenice wrote: > I've finally finished deleting all those nasty unreliable Seagate drives > from my array. During the process I crashed my server - over, and over, and > over. Completely gone - screen blank, controls unresponsive, no

Re: Kernel lockup, might be helpful log.

I've no need for a fix. I know exactly what the underlying cause is: Those Seagate 8TB Archive drives and their known compatibility issues with some kernel versions. I just shared the log because it's a situation that btrfs handles very, very poorly, and the error handling could be improved.

Re: Kernel lockup, might be helpful log.

On Mon, Dec 14, 2015 at 06:51:41AM +, Duncan wrote: > Birdsarenice posted on Sun, 13 Dec 2015 22:55:19 + as excerpted: > > > Meanwhile, I did get lucky: At one crash I happened to be logged in and > > was able to hit dmesg seconds before it went completely. So what I have > > here is

Re: Kernel lockup, might be helpful log.

Birdsarenice posted on Sun, 13 Dec 2015 22:55:19 + as excerpted: > Meanwhile, I did get lucky: At one crash I happened to be logged in and > was able to hit dmesg seconds before it went completely. So what I have > here is information that looks like it'll help you track down a >

Re: Kernel lockup, might be helpful log.

I can't help with the call traces. But several (not all) of the hard resetting link messages are hallmark cases where the SCSI command timer default of 30 seconds looks like it's being hit while the drive itself is hung up doing a sector read recovery (multiple attempts). It's worth seeing if