Monday 16 October 2017

linux-4.13-ck1, MuQSS version 0.161 for linux-4.13

Announcing a new -ck release, 4.13-ck1  with the latest version of the Multiple Queue Skiplist Scheduler, version 0.161. These are patches designed to improve system responsiveness and interactivity with specific emphasis on the desktop, but configurable for any workload.
-ck1 patches:

Git tree:

MuQSS only:

Git tree:

This version is no more than a resync from 4.12-ck2



  1. It would be interesting to see if the broken suspend problem exists with this release. Personally, I love to use this kernel but the hangup after wakeup is too much to live with unfortunately.

  2. There have been fixes for that on linux-block for a while now. My suspend/resume has been working fine on 4.13 for weeks. I think these are key, but post-factum (Oleksandr) would know for sure, as I've pulled in a lot of other things:
    And you'd prob want this too:

    If you're using bfq as well though, there's a bunch of patches for that too.

    Anyway, thanks Con! Getting bored w/ the new car yet? :-P

  3. I have a kernel panic when booting a kernel build with 4.13.7-ck. This is on Archlinux with i7-6700. Kernel logs:

    1. This is fixed with patch

    2. That's not a patch, that's a link back to this page.

  4. It seems as though bfq is to blame. For me, booting elevator=cfq in the boot loader works as expected. Can others confirm?

  5. Anyone running the nvidia driver 387.12 ?
    I'm getting errors with muqss vanille is working here the error message:
    nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state:

    1. There's a much newer nvidia driver. Are you limited in version due to older hardware or something? It sucks once you're in the unsupported hardware group.

    2. No problem here:

      emerge -pv nvidia-drivers

      These are the packages that would be merged, in order:

      Calculating dependencies... done!
      [ebuild R ] x11-drivers/nvidia-drivers-387.12:0/387::gentoo USE="X acpi driver gtk3 kms multilib tools uvm wayland -compat -pax_kernel -static-libs" ABI_X86="32 (64) (-x32)" 81087 KiB

      Total: 1 package (1 reinstall), Size of downloads: 81087 KiB

      asus-ux303 ~ # uname -a
      Linux asus-ux303 4.13.9-ck #1 SMP PREEMPT Sun Oct 22 07:36:53 CEST 2017 x86_64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz GenuineIntel GNU/Linux

  6. 387.12 is the newest beta driver.
    I now reverted back to 384.90 which works fine.
    My card is a 1050 Ti so pretty recent.

  7. Hi CK. The boot freezing from my email seems to be a direct effect for BFQ. If I reverse apply 0015-Enable-and-make-BFQ-default-IO-scheduler-overriding-.patch after applying patch-4.13-ck1, everything works as expected.

    My understanding is that this will remove BFQ from the patchset though. A work around which is applied to the Arch Linux linux-zen package (that includes MuQSS) is:

    That enables bfq by default in block/elevator.c that switches e = elevator_get("mq-deadline", false); to e = elevator_get("bfq", false); if #if defined(CONFIG_ZEN_INTERACTIVE) && defined(CONFIG_IOSCHED_BFQ)
    That would enable bfq by default with a one line change if you enabled CONFIG_SCSI_MQ_DEFAULT in the .config

    sq-bfq the bfq for when multiqueue is off also the bfq from before it was merged into mainline is

    Rather than me hacking this together, I'd like for you to review and consider a ck2.

    1. Thanks Graysky. It will not remove BFQ from the patchset since BFQ is part of mainline. That's why this is a most unusual bug since it is just a change in the default configuration which is doable even without this patch - it should not hang otherwise it's a mainline bug. I'll think about a -ck2.

    2. Yes it is an upstream bug as referenced
      The difference between 4.12-ck2 and 4.13-ck1 is the removal of Select SCSI_MQ_DEFAULT automatically when required by default io schedulers patch. Which prevented the mismatch. Even under 4.12-ck2 selecting bfq by default fails because bfq in mainline is a multiqueue based scheduler and hardcodes the choice for that in the code itself.
      There are checks in mainline that prevent picking a none multiqeue scheduler when queue is multiqueue but not the reverse. If you could pursue the issue of lack of checks with upstream on the block mailing list that would be great.

    3. More likely I will just remove the defaulting to BFQ for lack of time to pursue upstream bugs.

    4. If you want to keep it you would need to do as graysky indicated have one default for multiqueue queues and one default for none multiqueue queues and add back the pre merged bfq scheduler under a different name and specify that as the default for none multiqueues. If you do not touch block/Kconfig.iosched then the .config choice is limited to the three elevators that do not trigger the issue but you can still trigger the issue if you specify elevator=bfq on the command line and the system is using a none multiqeue queue.

  8. To be clear, credit for that info should go to loqs:

  9. Hacking Bitcoin with scripting

  10. Hello, CK.
    I noticed recently that my SD card reader RT5227 driven by RTSX_PCI stopped working. The card insertion causes
    Dec 04 09:01:56 localhost kernel: mmc0: cannot verify signal voltage switch
    Dec 04 09:01:56 localhost kernel: mmc0: new ultra high speed SDR50 SDXC card at address 59b4
    Dec 04 09:01:56 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000014
    Dec 04 09:01:56 localhost kernel: IP: blk_mq_init_sched+0x32/0x150

    I run -ck patch set on 4.13. A matching gentoo patch set for 4.13 allows RTSX-PCI work ok. OOPS doesn't fit here - so