|Summary:||>=sys-kernel/gentoo-sources-4.4.19[experimental] hangs on suspend to RAM|
|Product:||Gentoo Linux||Reporter:||Shiba <shibotto>|
|Component:||Current packages||Assignee:||Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Shiba 2016-09-13 09:07:40 UTC
Trying to suspend to RAM either by GUI or pm-suspend hangs the PC before it successfully suspends, no reaction to sysrq nor kernel panic's blinking lights. I tried tracking this down and it doesn't happen with [-experimental] nor with GCC 4.9 optimizations alone, so I think this is BFQ related. Unfortunately kern.log shows nothing useful. It does not happen with =sys-kernel/gentoo-sources-4.4.6[experimental]. Reproducible: Always
Comment 3 Thomas Deutschmann 2016-09-14 09:54:32 UTC
Are you really using BFQ? Just enabling the patch shouldn't activate usage. Check > cat /sys/block/*/queue/scheduler output for "bfq". Another test would be to exclude BFQ patches, just to be sure: https://wiki.gentoo.org/wiki/Project:Kernel/Experimental#Dealing_With_Patch_Conflicts_.28if_you_use_User_Patches.29 So is your problem really BFQ-related?
Comment 4 Shiba 2016-09-14 10:40:25 UTC
I'm dead sure, I've been using for several months. If you look in my config you'll find CONFIG_DEFAULT_BFQ=y and CONFIG_DEFAULT_IOSCHED="bfq". To be even more sure: shiba ~ > cat /sys/block/sda/queue/scheduler noop deadline cfq [bfq] I tried without BFQ patcheset (only GCC 4.9 optimizations) and it works fine. As soon as I get home I'll try to apply the patches and keep BFQ disabled.
Comment 5 Thomas Deutschmann 2016-09-14 10:50:50 UTC
OK. Please test the following thing: Switch scheduler at runtime. Try to reproduce. If you can't (that's what I am expecting if it is BFQ which is causing the problem) switch back to BFQ again (still at runtime). Now you should if it is really BFQ causing any troubles. CC'ing Tom to have a look..
Comment 6 Shiba 2016-09-14 14:40:50 UTC
I did what you asked and I was expecting the very same thing, but sadly it didn't turn out better. I changed the scheduler to CFQ for sda and sr0, the only two I have, and cat /sys/block/*/queue/scheduler confirmed the change was effective. However even with CFQ it still hangs before successfully suspending. I'll say this one more time to leave no doubt: without BFQ patches and using CFQ this does not occur, I tried an entire afternoon and I'm sure about this.
Comment 7 Thomas Deutschmann 2016-09-14 15:09:24 UTC
See bug 591828. Maybe you are affected by the same crash. Are you able to emerge gentoo-source-4.4.20 without BFQ patch set, grab the patch set from 4.7.2 and give it a try (hopefully they apply against 4.4.20...)?
Comment 8 Shiba 2016-09-14 15:59:21 UTC
All four patches from 4.7.3 applied against 4.4.20-gentoo like a charm and suspension works again! :D shiba ~ > dmesg | grep BFQ [ 0.758250] BFQ I/O-scheduler: v8r3 (with cgroups support)
Comment 9 Thomas Deutschmann 2016-09-14 16:14:07 UTC
Thank you for your patience and confirmation. So we will also update the BFQ patch set for 4.4.x. However this will happen with the next bump, i.e. when upstream releases 4.4.21.
Comment 10 Shiba 2016-09-15 07:20:49 UTC
Thank you for your support! If before 4.4.21 comes out I notice anything unusual with this configuration I'll let you know in this bug report.
Comment 11 Mike Pagano 2016-09-17 10:25:43 UTC
Please test 4.4.21. commit 8632a366685f17a7cd19d791a623ac95220ebd63 Author: Mike Pagano <email@example.com> Date: Fri Sep 16 18:15:31 2016 -0400 sys-kernel/gentoo-sources: Linux patch 4.4.21. BFQ Bump to fix bug #593648 Package-Manager: portage-2.2.28
Comment 12 Shiba 2016-09-21 09:44:27 UTC
Since 4.4.21 with BFQ v8r3 suspends fine, I think this can be marked as solved. If I experience any other problems related to this new BFQ I'll open another bug report.