Strange disk hang with new multi-queue block schedulers in 4.12+ kernels
 

Hey all,

I've been spending the last couple of days trying to get to the bottom of why my Thinkpad T430 was becoming unresponsive when switching to battery with any kernel from 4.12 on, and I figured I would share this info in case it's useful to others. It turns out that something is going on between udev and the block layer when using any of the new multiqueue schedulers (eg kyber, mq-deadline, bfq) that results in the disk hanging when switching between AC and battery power. For the time being I have resolved this by completely disabling the multi-queue IO block layer entirely by passing 'scsi_mod.use_blk_mq=0' on the kernel command-line at boot time.

It's strange because the problem doesn't exist in the 4.11 kernel branch, which is where the multi-queue block layer was introduced, just 4.12 and up. If anyone else has observed this or has any further insights on it, I'd be very appreciative.

I see in my notes I did a test of this back in March - prior to the latest updates, but probably at least 4.12 as I use rawhide kernels on Fedora. Unfortunately that timeframe is right in a 2 year hole in my journal - had a corruption I had to purge.
Anyway, with a non-mq (real spinning) disk, I noticed no effects, and no problems. However, I'm not sure I loaded the modules for any new schedulers - only mq-deadline showed up.
I'll test again, and also try it on a laptop that has a (old) SSD in it.

Confirmed - I suggest you open a ticket.
With this real disk, things work until suspend. On resume I can usually get a couple of commands in a terminal, but then the system locks up. Using the default mq-deadline, didn't bother with bfq or kyber (forgot to mention - 4.14.7 kernel)
The SSD system works as expected.

Thanks for confirming the issue on your end syg00. Funny that you have no problem with an SSD, as I installed an SSD in this T430, although there's also in mSATA card in place as well. Perhaps that's the source of the issue?

In any case, where exactly were you suggesting I open a ticket? I'd be happy to try and get more eyes on this, since it seems like a kernel issue that merits further investigation by folks with more knowledge of the block layer than I have.

I've read disk problems with this kernel
 

Try to deactivate PAE