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

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

Bug#913138: linux: I/O on md RAID 6 hangs completely

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#913138: linux: I/O on md RAID 6 hangs completely Stanisław <staszek3@wp.pl> - 2018-11-08 23:40 +0100
    Bug#913138: linux: I/O on md RAID 6 hangs completely Cesare Leonardi <celeonar@gmail.com> - 2018-11-22 16:10 +0100

#62481 — Bug#913138: linux: I/O on md RAID 6 hangs completely

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

I suffer the same problem while running RAID1 with kernel 4.18.10-2.   I have found a hint in the Debian kernel mailing list, however, I haven't tested it yet:   "...Someone else suggested this might be related to using "blk-mq", so  could you try with these parameter:   dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0   Also, do you have laptop-mode-tools installed?   Ben..."   Please, read:  lists.debian.org lists.debian.org  lists.debian.org lists.debian.org  lists.debian.org lists.debian.org

[toc] | [next] | [standalone]

#62522

On Thu, 08 Nov 2018 23:28:16 +0100 =?UTF-8?Q?Stanis=C5=82aw?= 
<staszek3@wp.pl> wrote:
> I suffer the same problem while running RAID1 with kernel 4.18.10-2.

Me too.
For me this happens since the switch from 4.16 to 4.17.x, with two 
different PCs, both with LVM based RAID1. I've already opened bug 
#913119, then I've found this bug report and the reply from Stanislav 
was really helpful for me.
To me this bug, mine and the already closed bug #904822 have the same 
root: the stack traces reported by dmesg are very similar. And the 
common denominators are some sort of LVM RAID and the range of kernel used.

> "...Someone else suggested this might be related to using "blk-mq", so
> could you try with these parameter:
> 
> dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0

This seems to have solved the problem for me.
I've tested these boot parameters on one of the affected PC and now it's 
running for more than three days. Before, with kernel from 4.17.x to the 
current Debian's 4.18.10-2+b1, the system showed an oops within 0.5/1 day.

Disabling these parameters is plausible, since Debian's kernel enabled 
SCSI_MQ_DEFAULT and DM_MQ_DEFAULT with 4.17~rc7-1~exp1.

> Also, do you have laptop-mode-tools installed?

No, not installed here.

I've checked with two other distributions I have here, to see what they 
have done with SCSI_MQ_DEFAULT and DM_MQ_DEFAULT parameters:

- Arch Linux (kernel 4.18.16-arch1-1-ARCH): both disabled.
- Arch Linux (kernel 4.19.2-arch1-1-ARCH): both enabled.

- Fedora server 29 (kernel 4.18.17-300.fc29.x86_64): both disabled.
- Fedora server 29 (kernel 4.19.2-301.fc29.x86_64): both disabled.

But I was unable to find if upstream is aware of this problem and if 
it's already resolved in 4.19.

Cesare.

[toc] | [prev] | [standalone]

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

csiph-web