Booting with the options scsi_mod.use_blk_mq=0 elevator=bfq (or elevator=mq-deadline or elevator=kyber) observe system fails to boot. Alternately build a kernel with CONFIG_DEFAULT_IOSCHED="bfq" and boot with the option scsi_mod.use_blk_mq=0. Second point is probably only relevant to custom kernels. Documented on the arch linux forums here https://bbs.archlinux.org/viewtopic.php?pid=1730573#p1730573 Reproduced on 4.13-rc5 and 4.12.7 with no additional patches. Apologies if this is not a bug but intended behaviour.
I can confirm and also add that older versions of bfq don't need the scsi_mod.use_blk_mq to work and even used to work just exporting elevator=bfq so the issue could relly on how was implemented in the kernel. I think kyber and bfq should be exposed indiferently from the scsi_mod.use_blk_mq option used since a system could need operate with any indirefent if one is optimized for other kind of system either for decire or mostly for testing prupose.
The elevator= boot option is being phased out, we don't want to add it for the mq side of things.
Could you add a check that mirrors d1a987f35ebf859a771ac530e95a89933b6fcce8 for the case where !e && !q->mq_ops && *chosen_elevator but chosen_elevator is one of bfq, mq_deadline or kyber until the elevator parameter is phased out please. Related Line 236 seems to assumes e = elevator_get(CONFIG_DEFAULT_IOSCHED, false); will not return a mq elevator and unless the .Kconfig is adjusted that assumption seems valid not sure if the kernel should check e is not mq regardless.
I'll be happy to take a patch that fixes up any issues that causes us not to boot.
Created attachment 260375 [details] prevent mismatch of mq use for elevator and CONFIG_DEFAULT_IOSCHED This was the patch originally I drafted but it allows the elevator to be mq as long as the queue is.
Created attachment 260377 [details] minimal example fix This fix stops the mismatch with mq usage keeping the requirement that the elevator parameter and CONFIG_DEFAULT_IOSCHED must not be mq does not change commenting or error messages but hopefully shows the intent of what I am trying to fix.
That last patch, can you send that as a proper patch with commit message, etc? Looks fine to me, but you need to fix the whitespace issues (space after 'if'). If you want me to carry it to completion, that's fine too. Just let me know.
Created attachment 260379 [details] MQ vs non-mq load
Created an alternative patch. Totally untested... But I prefer this approach, so we pass in whether we want MQ or not to the API. Can you give it a whirl?
Created attachment 260381 [details] MQ vs non-mq load Lets push it a bit further...
That patch fixes the issue. When root device is using a none mq device and the elevator is an mq one eg bfq it now generates the error message "I/O scheduler bfq not found" and boots successfully
Great, thanks for testing. I'll post it for review and include it upstream.
If the patch is accepted into mainline 4.15 could it be backported to 4.14 stable?
It could, but not sure it's grave enough to warrant stable backports.