Hi, On 11/24/18 12:42 AM, Cesare Leonardi wrote: > Bug still present with the new 4.18.0-3-amd64 (4.18.20-1). > > This morning I've tryed to boot this new kernel version, removing the > workaround given by the following kernel parameters: > scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0 > > The system showed disk hangs in less than 5 hours, and, as in previous > 4.17 and 4.18, normal disk activities was restored after some minutes, > without apparent data loss. I experienced two hangs before rebooting, > but one of them didn't produce an oops in dmesg. It was not the first > time I saw an hang without oops: maybe those that can recover in less > than 120 seconds, doesn't produce oopses in dmesg?
You didn't share any part of your logging. Can you share a part of dmesg logging that shows Oops in it? If a task hangs while doing disk IO, it might cause messages like these in dmesg: INFO: task kthxbye:1157 blocked for more than 120 seconds. Not tainted blah #1 Debian someversion [...] <Some stack trace thing> These are 'just' informational messages. The process will still wait until it can continue. A kernel Oops is something really different. It usually means that some data structures or code to be executed are corrupt and there's a real problem going on, it's not just stalled and waiting. > And just to be clear, it doesn't seem a bug related to LVM but more > precisely to various types (all?) of LVM RAID. In fact my notebook disk > uses LVM linear volumes and never showed those hangs and oopses. Have fun, Hans