Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
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
Reply to: