My kernel is working fine, I don’t have any reason to upgrade at the moment, especially when everyone here is having this issue with 4.12, it doesn’t give me any hope for a better experience, when 4.12.4 comes out of testing as mentioned in the message after yours, the solution is to default to the I/O scheduler that causes me problems anyway… If I were to downgrade kernel the 4.9 LTS isn’t any better, 4.8 doesn’t have the problem. I plan to upgrade to 4.13 when it’s available(assuming it will also have any fixes in 4.12 here.
I’m well aware of what this thread is about…
In 4.12 kernel, BFQ got mainlined with blk-mq scheduler, I’m guessing Manjaro uses this by default for 4.12 kernel?
I was trying to point out the similar behaviour with suspend/resume and BFQ that I had. Hasn’t the answer here been changing from the BFQ blk-mq scheduler fixes the issue? So it’s perhaps then possible that the BFQ bug that affects my system might happen to exist in the blk-mq scheduler in a similar form that affects users more easily?
Kernel 4.10 is EOL and hasn’t been getting any security-related updates from the kernel developers. If you’re happy running a vulnerable system, fine. Otherwise, you should be looking at updating. 4.12.4-2 doesn’t exhibit the suspend issues.
If you’re reporting a bug in the BFQ scheduler in kernel 4.9 it’s going to be worth checking a newer kernel to confirm. There’s not a lot of upstream development for older kernels, so any fixes will be in newer ones (unless backported, as in this case).
Switching from bfq-mq to bfq-sq.
If there’s a bug in single-queue (i.e. normal) BFQ it’s not the same as this one or everyone else would have hit it too. Let’s move this to another thread.
Vulnerable in what way? As a competent linux desktop user there is very little concern that I’ll be infected with anything or at much risk beyond someone gaining physical access to my machine.
4.12.4-2 might not exhibit suspend issues for the majority of users in this thread, BFQ still may not be in any better of a state for my similar issue, but perhaps blk-mq equivalent for BFQ doesn’t share the same problem with my system. I’ll upgrade at a later date.
I reported the bug many months ago, as well as on the kernel bug tracker which helped identify that it was due to BFQ and XFS on my system. I was on 4.9 for a while, I can’t recall why I updated to 4.10, something in the kernel features I guess(probably virtualization related). Maybe it’s been fixed by now, presently I’m fine with noop scheduler.
In which case, if the bug persists for my system as it did prior to blk-mq last I checked, that solution/workaround isn’t one for me.
Depends, I assume the blk-mq BFQ scheduler shares similar code to legacy BFQ one, but as the code/implementation is bound to have differences, perhaps blk-mq exposes the bug to a wider audience, a new code path that runs into the same bug I do(BFQ on XFS filesystem, possibly related to my hardware or something else, I don’t know how many others go with XFS over EXT4 which I think is the FS default for Manjaro?).
I definitely wouldn’t cross it out as related though. You should be able to further confirm with logrotate which would cause the same problem as suspend/resume when it ran as a midnight task. I think the command the systemd timer executed just had to be done twice via cli to get the same results. Here is my forum thread, dates back to March, it had been bothering me for sometime(4.9 released in december). That thread and related ones could potential help debug the problem…
In my 4.12, I have enabled blk-mq but I didn’t include the Manjaro mq-bfq patches. Suspend works.
Wouldn’t it be a better solution to just remove the mq-bfq patches altogether until they’re either stable or part of mainline kernel?