On 01/13/2017 09:00 AM, Jens Axboe wrote: > On 01/13/2017 08:59 AM, Hannes Reinecke wrote: >> On 01/13/2017 04:34 PM, Jens Axboe wrote: >>> On 01/13/2017 08:33 AM, Hannes Reinecke wrote: >> [ .. ] >>>> Ah, indeed. >>>> There is an ominous udev rule here, trying to switch to 'deadline'. >>>> >>>> # cat 60-ssd-scheduler.rules >>>> # do not edit this file, it will be overwritten on update >>>> >>>> ACTION!="add", GOTO="ssd_scheduler_end" >>>> SUBSYSTEM!="block", GOTO="ssd_scheduler_end" >>>> >>>> IMPORT{cmdline}="elevator" >>>> ENV{elevator}=="*?", GOTO="ssd_scheduler_end" >>>> >>>> KERNEL=="sd*[!0-9]", ATTR{queue/rotational}=="0", >>>> ATTR{queue/scheduler}="deadline" >>>> >>>> LABEL="ssd_scheduler_end" >>>> >>>> Still shouldn't crash the kernel, though ... >>> >>> Of course not, and it's not a given that it does, it could just be >>> triggering after the device load and failing like expected. But just in >>> case, can you try and disable that rule and see if it still crashes with >>> MQ_DEADLINE set as the default? >>> >> Yes, it does. >> Same stacktrace as before. > > Alright, that's as expected. I've tried with your rule and making > everything modular, but it still boots fine for me. Very odd. Can you > send me your .config? And are all the SCSI disks hanging off ahci? Or > sdb specifically, is that ahci or something else?
Also, would be great if you could pull: git://git.kernel.dk/linux-block blk-mq-sched into current 'master' and see if it still reproduces. I expect that it will, but just want to ensure that it's a problem in the current code base as well. -- Jens Axboe