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
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
