You are not logged in.
I am unable to build/test 4.12.7-1 (CK) right now, but as stated, it does make that modification (see the AUR git log); if I can get some feedback from a few users to verify that it does work, I will trigger the repo-ck build and push out 4.12.7-1.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Users should be able to boot by using the option scsi_mod.use_blk_mq=1 as well. Going to be busy for the next few hours then will test if still needed.
Edit:
linux-ck 4.12.7-1 boots without issue provided the option scsi_mod.use_blk_mq=0 is not specified.
Hopefully ck can work with upstream to fix this issue. No AUR account so posted here apologies.
Edit2:
You can use scsi_mod.use_blk_mq=0 as long as you combine it with elevator=cfq or elevator=noop or elevator=deadline.
Edit3:
You might want to add a note that the default io scheduler will be mq-deadline for single queue devices and none for multiqueue devices.
Edit4:
This should allow you to use CONFIG_SCSI_MQ_DEFAULT=n and scsi_mod.use_blk_mq=0
It does not address both the mq and none mq bfq elevators use the name bfg see http://elixir.free-electrons.com/linux/ … tor.c#L905
Only one is registered apparently the mq one so the none mq one is inaccessible. Renaming the none mq one to something else or changing the kernel config so only one can be built would address that.
diff --git a/block/elevator.c b/block/elevator.c
index dac99fbfc273..5fb2cc5b2ef0 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -218,6 +218,14 @@ int elevator_init(struct request_queue *q, char *name)
if (!e)
printk(KERN_ERR "I/O scheduler %s not found\n",
chosen_elevator);
+ else {
+ if (e->uses_mq) {
+ printk(KERN_ERR "I/O scheduler %s uses mq ignoring as default\n",
+ chosen_elevator);
+ elevator_put(e);
+ e = NULL;
+ }
+ }
}
if (!e) {
@@ -232,8 +240,15 @@ int elevator_init(struct request_queue *q, char *name)
e = elevator_get("mq-deadline", false);
if (!e)
return 0;
- } else
+ } else {
e = elevator_get(CONFIG_DEFAULT_IOSCHED, false);
+ if (e->uses_mq) {
+ printk(KERN_ERR "I/O scheduler %s uses mq will not use on none mq queue\n",
+ e->elevator_name);
+ elevator_put(e);
+ e = NULL;
+ }
+ }
if (!e) {
printk(KERN_ERR
Edit5:
Replaced patch with improved version.
Edit6:
https://aur.archlinux.org/cgit/aur.git/ … ux-ck#n406
CONFIG_DEFAULT_IOSCHED="bfq" this was the cause of the none boot. The bfq scheduler in linux-ck 4.12.7-1 is the mq one and the code expects the specified default to be one of the none mq schedulers.
Edit8:
https://github.com/ckolivas/linux/commi … 1e22fa1728 avoids the boot failure but selection will not be honored by the elevator.
Edit9:
In response to https://ck-hack.blogspot.co.uk/2017/08/ … 9122898386
See edits 8 and the following commits
https://github.com/ckolivas/linux/commi … 933b6fcce8
https://github.com/ckolivas/linux/commi … c0db2c3032
and this line of block/elevator.c
https://github.com/ckolivas/linux/blob/ … tor.c#L216
Edit10:
In response to
https://ck-hack.blogspot.com/2017/08/li … 1897409199
Yes it is set but ck does not appear to have checked the scheduler actually in use
Already covered in edit 9 why his patch is failing
diff --git a/block/elevator.c b/block/elevator.c
index dac99fbfc273..52c24f5e9323 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -208,38 +208,39 @@ int elevator_init(struct request_queue *q, char *name)
}
/*
- * Use the default elevator specified by config boot param for
- * non-mq devices, or by config option. Don't try to load modules
+ * Use the default elevator specified by config boot param
+ * or by config option. Don't try to load modules
* as we could be running off async and request_module() isn't
* allowed from async.
*/
- if (!e && !q->mq_ops && *chosen_elevator) {
+ if (!e && *chosen_elevator) {
e = elevator_get(chosen_elevator, false);
if (!e)
printk(KERN_ERR "I/O scheduler %s not found\n",
chosen_elevator);
+ else {
+ if ((e->uses_mq && !q->mq_ops) || (!e->uses_mq && q->mq_ops)) {
+ printk(KERN_ERR "I/O scheduler %s mismatch with queue mq use\n",
+ chosen_elevator);
+ elevator_put(e);
+ e = NULL;
+ }
+ }
}
if (!e) {
- /*
- * For blk-mq devices, we default to using mq-deadline,
- * if available, for single queue devices. If deadline
- * isn't available OR we have multiple queues, default
- * to "none".
- */
- if (q->mq_ops) {
- if (q->nr_hw_queues == 1)
+ e = elevator_get(CONFIG_DEFAULT_IOSCHED, false);
+ if ((e->uses_mq && !q->mq_ops) || (!e->uses_mq && q->mq_ops)) {
+ printk(KERN_ERR "I/O scheduler %s mismatch with queue mq use\n",
+ e->elevator_name);
+ elevator_put(e);
+ e = NULL;
+ if (q->mq_ops) {
e = elevator_get("mq-deadline", false);
- if (!e)
- return 0;
- } else
- e = elevator_get(CONFIG_DEFAULT_IOSCHED, false);
-
- if (!e) {
- printk(KERN_ERR
- "Default I/O scheduler not found. " \
- "Using noop.\n");
- e = elevator_get("noop", false);
+ if (!e)
+ return 0;
+ } else
+ e = elevator_get("noop", false);
}
}
Proof of concept patch whitespace is incorrect along with printk error but it should honor the config io scheduler selection provide it is safe to do so.
Edit11:
Cleaned up patch slightly removed the obvious printk error.
Last edited by loqs (2017-08-17 22:00:15)
Offline
@graysky does the proof of concept patch work for you?
Offline
Haven't had a free minute yet... hopefully tomorrow.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
As a test I tryed linux-zen which have bfq too and they dissabled it for rotating and aparently all the other kernels too...
well look like in the mergin in mailine just make bfq into a only for non-ratating fature and aparently they even want to depreciate elevator...
so yeah now i going to miss bfq on my normal hdd
Well, I suppose that this is somekind of signature, no?
Offline
@Jristz you could ask for the bug report to be opened. The first of my two patches will cause a warning to be printed instead of failure to boot however I would expect it be classed as an upstream bug.
So unless someone raises it upstream the issue will remain. The elevator option will probably remain until upstream removes none mq io schedulers.
Offline
You are misunderstanding jristz. The multi queue change is also applicable to rotational devices as well and it did receive schedulers (like well bfq) precisely so that rotational drives can benefit from it as well. The comment on the wiki article has been written before there were any schedulers for the multiqueue something which has been addressed now with the inclusion of BFQ.
Offline
You are misunderstanding jristz. The multi queue change is also applicable to rotational devices as well and it did receive schedulers (like well bfq) precisely so that rotational drives can benefit from it as well. The comment on the wiki article has been written before there were any schedulers for the multiqueue something which has been addressed now with the inclusion of BFQ.
Are... you... quoting what I post on the wiki?
Anyways if I get confised at that point it look like the wording on that article is even poorer that I thought and think are rolling faster too.
@Jristz you could ask for the bug report to be opened. The first of my two patches will cause a warning to be printed instead of failure to boot however I would expect it be classed as an upstream bug.
So unless someone raises it upstream the issue will remain. The elevator option will probably remain until upstream removes none mq io schedulers.
Well this it surely will marked as upstream if it need a non upstreamed patch, that the tradition on arch.
I don't even know where to report the bug since liek there are bugzillas for anyplace (fedora, redhat, suse all look like they talk to upstream somehow).
Well, I suppose that this is somekind of signature, no?
Offline
I don't even know where to report the bug since liek there are bugzillas for anyplace (fedora, redhat, suse all look like they talk to upstream somehow).
https://bugzilla.kernel.org/ Category IO/Storage Component Block Layer or the linux-block mailing list.
Edit:
To demonstrate the issue boot 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.
Edit:
https://bugzilla.kernel.org/show_bug.cgi?id=196695
Edit2:
Still got a non-bootable kernel, both from here or from repo-ck freezes at boot since version 4.12.7. Normal arch kernel boots without any issues. Just a blinking cursor and after 2 minutes it shows "Triggering uevents" but thats it.
Given that users are still encountering the issue you might want to pin a comment on the AUR page that the kernel parameter elevator should not be set to bfq, kyber or mq-deadline without an additional patch.
Edit:
Request to reopen FS#54964 denied
Reason for denial:
Any number of dumb things can cause the system not to boot. This is a config issue..
No further progress possible.
Last edited by loqs (2017-08-21 16:20:01)
Offline
...
Edit:
Request to reopen FS#54964 deniedReason for denial:
Any number of dumb things can cause the system not to boot. This is a config issue..No further progress possible.
I told you, is the tradition in arch, also considering that from a vanilla stand the introduction of bfq is a new feature then it should be upstream bug or feature depending on if was intentional or not.
Well, I suppose that this is somekind of signature, no?
Offline
I told you, is the tradition in arch, also considering that from a vanilla stand the introduction of bfq is a new feature then it should be upstream bug or feature depending on if was intentional or not.
Given the lack of interest displayed so far by all other parties perhaps it would just be better to cancel the upstream bug report.
Offline
Hello,
I'm using linux-ck-pildriver kernel and the last weeks I had a problem with nvidia drivers(both from ck repo and from linux repository), when the pc wakes up from suspend. I created a thread about this here:
https://bbs.archlinux.org/viewtopic.php … 5#p1732125
After I tried a lot of nvidia driver versions I booted from the normal arch kernel and I found that there are no problems with suspend. So it seems that isn't nvidia' s driver problem but ck kernel' s.
I didn't have this problem in the past(I' using ck kernel more than a year), so something's changed in the last versions.
Last edited by zaxdan69 (2017-08-23 13:05:46)
Offline
Can anyone verify if v 4.12.9 solved the freeze bug?
zaxdan69: There is a known conflict between the multi queue I/O schedulers and suspend. It maybe your case.
Offline
@Tharbad have you tried rebuilding with CONFIG_SCHED_MUQSS=n? To see if the issue you are experiencing is MuQSS related.
If that fails would try scsi_mod.use_blk_mq=0 elevator=cfq with CONFIG_SCHED_MUQSS=n still set.
Edit:
@Tharbad if you post on the AUR package page again could you ask hotty to try my first patch or booting with scsi_mod.use_blk_mq=0 elevator=cfq.
Last edited by loqs (2017-08-27 18:06:30)
Offline
zaxdan69: There is a known conflict between the multi queue I/O schedulers and suspend. It maybe your case.
I don't know. I tried to set scsi_mod.use_blk_mq=0 as suggested in linux-ck aur page, but that didn't make any difference. I' m using version 4.11.12-1 for now, which doesn't have this issue and suspend working fine.
Offline
@zaxdan69 have you tried rebuilding with CONFIG_SCHED_MUQSS=n? To see if the issue you are experiencing is MuQSS related.
You could also try linux-zen which also uses MuQSS and BFQ.
Offline
No, I don't know how to do that. I'll try linux-zen.
EDIT:
No problems when wake up from suspend with linux-zen also.
Last edited by zaxdan69 (2017-08-29 17:29:22)
Offline
No, I don't know how to do that.
You might want to move the existing packages out the way first then
Edit config.x86_64 or config.i686 whichever arch you using change the line CONFIG_SCHED_MUQSS=y to CONFIG_SCHED_MUQSS=n
then run
$ updpkgsums
$ makepkg -rsiC
EDIT:
No problems when wake up from suspend with linux-zen also.
I am reading this to mean both kernels have the issue.
Offline
You mean to uninstall the kernel? I have the previous version right now (4.11.12).
And where is the config.x86_64 file?
Last edited by zaxdan69 (2017-08-29 18:16:24)
Offline
And where is the config.x86_64 file?
$ git clone https://aur.archlinux.org/linux-ck.git
Cloning into 'linux-ck'...
remote: Counting objects: 814, done.
remote: Compressing objects: 100% (452/452), done.
remote: Total 814 (delta 551), reused 571 (delta 362)
Receiving objects: 100% (814/814), 368.49 KiB | 1.11 MiB/s, done.
Resolving deltas: 100% (551/551), done.
$ cd linux-ck/
$ ls
90-linux.hook config.x86_64
bonding-ratelimit-failed-speed-duplex-update-warning.patch linux.install
bonding-require-speed-duplex-only-for-802.3ad-alb-an.patch linux.preset
config.i686 PKGBUILD
I am guessing you use the package from repo-ck rather than building it from the PKGBUILD supplied on AUR.
You could also try linux-zen 4.12.7 from Arch_Linux_Archive that contains MuQSS 0.157 rather than 0.160.
Otherwise try filing a report upstream with ck and wait for him to return.
Offline
I rebuilt the kernel with change CONFIG_SCHED_MUQSS=y to CONFIG_SCHED_MUQSS=n, but the issue still remains. This time the behaviour is litte different though. Again after wake up from suspend the desktop appears and the mouse cursor can move but not click. But after some seconds the screen freezes completely and the mouse cursor disappears. Also this time I cannot switch to other ttys at all.
What I' ve done.
- I downloaded the linux-ck from aur by git clone command and cd to linux-ck
- I edited the pkgbuild to use my current kernel' s(linux-ck-piledriver 4.11.12 version) config file
- Then I run updpkgsums command
- When finished I edited the config file to change the CONFIG_SCHED_MUQSS line to no
- After that I ran the makepkg -rsiC command which failed because the above file didn't pass the check proccess(because I edited it I suppose)
- I ran again the above command, but this time I used --skipchecksums parameter also and this time the build and install completed.
So it seems that something else causes the problem.
Offline
@zaxdan69 with the kernel you built running please post the output from the following commands
$ zgrep CONFIG_DEFAULT_IOSCHED /proc/config.gz
$ zgrep CONFIG_SCSI_MQ_DEFAULT /proc/config.gz
$ cat /proc/cmdline
Offline
This is the output of the 3 commands:
CONFIG_DEFAULT_IOSCHED="bfq"
CONFIG_SCSI_MQ_DEFAULT=y
BOOT_IMAGE=/boot/vmlinuz-linux-ck root=UUID=d28d2d85-0c43-4d25-925d-a189c5d957ed rw nvidia-drm modeset=1
Offline
Try adding scsi_mod.use_blk_mq=0 elevator=cfq to the kernel command line. Does your system have any NVME devices?
Offline
With these both in kernel command line suspend works.
As for NVME, "nvme list" doesn't have any entry, so I don't have.
Offline