[SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

loqs · 2017-07-13 21:40:26

https://git.archlinux.org/svntogit/pack … 5dd7bf82ea
unset CONFIG_SCSI_MQ_DEFAULT for the reason stated in the title but there is no reference to what the instability issue is.
Is there an upstream bug report or mailing list thread tracking / referencing this?
Edit:
Marked solved as the original question has been answered.

Last edited by loqs (2017-07-14 17:58:48)

graysky · 2017-07-13 22:11:02

Interesting... I am using my own 4.12.1 with 'scsi_mod.use_blk_mq=1' as a boot parameter. Should probably look into this.

tom.ty89 · 2017-07-14 06:08:11

https://git.kernel.org/pub/scm/linux/ke … 6005b066fa

Coz it's statically enabled by default now.

Last edited by tom.ty89 (2017-07-14 06:47:07)

graysky · 2017-07-14 06:46:14

tom.ty89 wrote:

https://git.kernel.org/pub/scm/linux/ke … 6005b066fa
Coz it's statically enabled by default now.

No indication of instability in that link... hefteg's commit message, "4.12.1-2: FS#54788 KASLR, no SCSI_MQ (unstable)," is confusing to me too.

tom.ty89 · 2017-07-14 06:47:32

Wait, the commit hasn't got into mainline yet. So we've been having it enabled, and in the next major release it would be enabled statically by default, but then we have it disabled for this release downstream? No idea what heftig is doing.

https://git.kernel.org/pub/scm/linux/ke … .c?h=v4.12

https://git.kernel.org/pub/scm/linux/ke … nux-4.12.y

Last edited by tom.ty89 (2017-07-14 06:48:05)

heftig · 2017-07-14 06:54:45

Foutrelis' laptop (HDD, LUKS, ext4, mq-deadline) hangs on resume from suspend, while mine (SSD, LUKS, btrfs, bfq) hangs when pulling multiple git repos at once, messing up the repos quite badly and corrupting the FS. This was only discussed in IRC; I unfortunately have very little time to follow up on this.

Last edited by heftig (2017-07-14 06:59:21)

graysky · 2017-07-14 07:15:13

heftig wrote:

Foutrelis' laptop (HDD, LUKS, ext4, mq-deadline) hangs on resume from suspend, while mine (SSD, LUKS, btrfs, bfq) hangs when pulling multiple git repos at once, messing up the repos quite badly and corrupting the FS. This was only discussed in IRC; I unfortunately have very little time to follow up on this.

Thank you for the clarification, heftig. My suspicion is that your issues lie with btrfs

R00KIE · 2017-07-14 08:34:36

Problems do happen with ext4 and btrfs so probably btrfs is not to blame (this time ). If we're going to play the guessing game maybe it's the new changes to support disk schedulers.

loqs · 2017-07-14 09:10:18

My understanding is NVME devices can only use blk_mq so would they not still be exposed to the issue? It is a pity no one is able to follow this up.
Edit:
Possibly relevant as both affected systems were using LUKS https://bugs.archlinux.org/task/54700

Last edited by loqs (2017-07-14 09:21:28)

graysky · 2017-07-14 09:52:18

loqs wrote:

My understanding is NVME devices can only use blk_mq so would they not still be exposed to the issue?

If that is true, unless explicitally booting with the enable option, wouldn't that make a system running a NVMe drive and booting into 4.12.1-2 unbootable? I can try later today on my machine.

loqs · 2017-07-14 09:58:27

My understanding is as NVME can only use blk_mq such devices ignore scsi_mod.use_blk_mq=0

graysky · 2017-07-14 12:45:13

but in this case, having the module disabled should result in a failure to read on boot assuming it is the boot device, yes? -2 excludes it from the kernel all together if I understand it correctly.

tom.ty89 · 2017-07-14 13:17:31

nvme drives are not scsi devices, the kernel doesn't even wrap them as scsi devices as it does for ATA drives AFAIK (iirc the nvme driver does have some scsi emulation implemented for compatibility, though that shouldn't matter here). The config option is a scsi layer one, not a block layer one. Neither do we know that "the issue(s)" would affect nvme drives as well.

The commit does not exclude it altogether either. It's just the default set to disabled. You can still override it with scsi_mod.use_blk_mq=1.

Last edited by tom.ty89 (2017-07-14 13:24:23)

loqs · 2017-07-14 14:12:55

tom.ty89 wrote:

nvme drives are not scsi devices, the kernel doesn't even wrap them as scsi devices as it does for ATA drives AFAIK (iirc the nvme driver does have some scsi emulation implemented for compatibility, though that shouldn't matter here). The config option is a scsi layer one, not a block layer one. Neither do we know that "the issue(s)" would affect nvme drives as well.

Yes further investigation is needed to find the cause of the issue then its extent can be understood. As you noted with the changes for 4.13 arch will have to patch the kernel or force the kernel boot parameter to keep it disabled by default.

tom.ty89 wrote:

The commit does not exclude it altogether either. It's just the default set to disabled. You can still override it with scsi_mod.use_blk_mq=1.

Or just not use that commit or manually set the option back etc.
Edit:
If you are including 54700 in "the issue(s)" that should be independent of the underlying block device
boot with slub_debug parameter, adjust block device to be something else if desired repeat a few times ( including rebooting ) until the mount errors.

#!/usr/bin/bash
sudo bash -c "echo 7 > /proc/sys/kernel/printk"
cat /proc/sys/kernel/printk
cd /tmp/
dd if=/dev/zero of=disk.img bs=1M count=256
sudo losetup /dev/loop0 disk.img
sudo cryptsetup -y -c aes -s 256 create home-aes /dev/loop0
sudo mkfs.xfs /dev/mapper/home-aes
sync
sudo mount -t xfs -o discard,noatime /dev/mapper/home-aes /mnt

Edit2:
@tom.ty89 Thank you for clarifying the distinction for nvme devices.
Edit3:
@heftig Thank you for the response perhaps you will find time to investigate the issue further at some future point.
This system has logged over a hundreds hours including idling using SCSI_MQ on 4.12 so I am undecided whether to disable it or not.

Last edited by loqs (2017-07-14 18:39:12)

Arch Linux

#1 2017-07-13 21:40:26

[SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#2 2017-07-13 22:11:02

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#3 2017-07-14 06:08:11

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#4 2017-07-14 06:46:14

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#5 2017-07-14 06:47:32

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#6 2017-07-14 06:54:45

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#7 2017-07-14 07:15:13

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#8 2017-07-14 08:34:36

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#9 2017-07-14 09:10:18

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#10 2017-07-14 09:52:18

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#11 2017-07-14 09:58:27

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#12 2017-07-14 12:45:13

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#13 2017-07-14 13:17:31

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

#14 2017-07-14 14:12:55

Re: [SOLVED] linux 4.12.1-2 no SCSI_MQ (unstable)

Board footer