Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62523 > unrolled thread

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-22 16:10 +0100
    Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-24 00:50 +0100
      Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1 Cesare Leonardi <celeonar@gmail.com> - 2018-11-24 02:30 +0100

#62523 — Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

I've added some details in #913138, which I believe is the same bug as 
this one.
There a commenter suggested two kernel parameters that, so far, have 
resolved the problem for me.

Cesare.

[toc] | [next] | [standalone]

#62543

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?

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.

Cesare.

[toc] | [prev] | [next] | [standalone]

#62544

[Multipart message — attachments visible in raw view] — view raw

Hi Hans!

On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg 
<hans@knorrie.org> wrote:
> You didn't share any part of your logging. Can you share a part of dmesg
> logging that shows Oops in it?

Here it is, attached to this message.
Previously I didn't attached it because to me it looks substantially the 
same as the one I attached in the opening message of this bug (#913119).

> 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.

Thank you very much for this explanation: I didn't know this difference 
and indeed I realized that I didn't know what a oops really is.

Cesare.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web