Setting ignore_nice_load (echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load) works fine. After doing a suspend to RAM and waking the machine again, this setting is lost: cat /sys/devices/system/cpu/cpufreq/ondemand gives 0. I noticed this behaviour first with kernel 3.10.16 (it may have been introduced earlier). However, booting the system with kernel 3.7.10 doesn't show this bug. Workaround: ignore_nice_load can be set again manually after suspend2ram.
Possible to test an upstream kernel, say Linus' git tree?
Yes - same behaviour with kernels 3.11.5 and 3.12.0-rc5 :-( BTW: after suspend2ram, not only the content of /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load has changed - the CPU is indeed running at full speed although only low priority tasks are running ...
Kernels 3.9.11 and 3.8.13 don't show the bug so it probably has been introduced with the 3.10 series ...
I just check the issue on the linux-pm linux-next branch and doesn't find the issue. Could you please try it on your machine? http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/
Created attachment 111501 [details] Kernel config
I did "git clone -b bleeding-edge git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm" and can still reproduce the bug. I attached my current kernel config.
My Hardware configuration (output of lspci): 00:00.0 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a2) 00:01.0 ISA bridge: NVIDIA Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2) 00:01.1 SMBus: NVIDIA Corporation MCP78S [GeForce 8200] SMBus (rev a1) 00:01.2 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:01.3 Co-processor: NVIDIA Corporation MCP78S [GeForce 8200] Co-Processor (rev a2) 00:01.4 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1) 00:02.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:02.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:04.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1) 00:04.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1) 00:06.0 IDE interface: NVIDIA Corporation MCP78S [GeForce 8200] IDE (rev a1) 00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) 00:08.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:09.0 SATA controller: NVIDIA Corporation MCP78S [GeForce 8200] AHCI Controller (rev a2) 00:0a.0 Ethernet controller: NVIDIA Corporation MCP77 Ethernet (rev a2) 00:10.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:12.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) 00:13.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:14.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1) 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 01:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) 01:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 02:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2) 02:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) 04:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) 05:00.0 USB controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03)
Hi, sorry for later response and I can't boot up kernel with your config on my machine. Please provide the output of "grep . /sys/devices/system/cpu/cpu*/cpufreq/*"
No problem. I removed unnecessary components to speed up kernel builds so my kernel probably won't boot on different hardware. I attach the output ...
Created attachment 114741 [details] grep . /sys/devices/system/cpu/cpu*/cpufreq/*
BTW: CPU is AMD Phenom II X4 945.
Hi, please try this patch. http://www.spinics.net/lists/kernel/msg1636080.html
(In reply to Lan Tianyu from comment #12) > Hi, please try this patch. > > http://www.spinics.net/lists/kernel/msg1636080.html Pasting from my mail for records: Though the patch I have sent fixes a problem similar to this but I don't think patch of any of us will solve the issue Rainer is facing.. I checked his system configuration and its like this: - Four CPUs, all having separate clock domains (atleast from kernel perspective) and so separate policy structure. - All are using ondemand governor - not using CPUFREQ_HAVE_GOVERNOR_PER_POLICY feature - So there is a single set of tunables for ondemand governor that is applicable across all CPUs.. The way INIT/EXIT are designed in cpufreq_governor.c should take care of this scenario. memory for tunables must not be freed unless all the CPUs are removed. Which can't happen, as we only offline non-boot CPUs and so I believe that memory isn't getting freed and so your solution wouldn't address his problem.. Sorry if I said something stupid enough :)
Created attachment 115501 [details] debug.patch Yes, the previous patch seems not related with this bug and so ignore it. Current, have no idea about this bug. Please apply this patch which add debug info in the code path of storing ignore_nice_load. Let's see whether user space configures the sysfs interface during system resume.
Userspace seems to be innocent: After resume, "dmesg | fgrep cpufreq_ondemand" gives only one entry (probably my call from /etc/init.d/boot.local): [ 28.554411] cpufreq_ondemand: store_ignore_nice_load: ignore nice 1 And "cat /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load" still gives "0" ... So something is happening inside the kernel !?!
On Friday 22 November 2013 03:21 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=63081 > > --- Comment #15 from Rainer Kaluscha <rainer.kaluscha@web.de> --- > Userspace seems to be innocent: > > > After resume, "dmesg | fgrep cpufreq_ondemand" gives only one entry (probably > my call from /etc/init.d/boot.local): > [ 28.554411] cpufreq_ondemand: store_ignore_nice_load: ignore nice 1 > > And "cat /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load" still > gives > "0" ... > > So something is happening inside the kernel !?! Lan, Were you able to reproduce this stuff yet? I will also give it a try soon once I get some time.
(In reply to Viresh Kumar from comment #16) > Lan, > > Were you able to reproduce this stuff yet? I will also give it a try soon > once I > get some time. No, I tried to reproduce it but no progress.
Hi Rainer: Could you run the following the cmd, do s2ram and attach the output of dmesg? This is to open the cpufreq core dynamic debug. There maybe some clues. echo "file cpufreq.c +p" > /sys/kernel/debug/dynamic_debug/control BTW, there will be a lot of logs. so please add "log_buf_len=10M" kernel param to increase log buf.
Supplement to comment 16: It is consistent with the observation that kernel 3.7.10 still works. If something was happening in userspace it should also affect the older kernels, shouldn't it ?
Hi Lan, I did as requested and noticed a strange thing: After boot, machine is running with 4 low priority background jobs, all 4 cores at 800MhZ - as expected. If I call s2ram directly, suspend/resume works as expected (attachment s2ram), i.e. all 4 cores at 800Mhz after resume. However, if I use pm-suspend (attachment pm_suspend), I enter the bug - all 4 cores at 3000 MHz although there is only low priority work ... Nevertheless, pm-suspend doesn't manipulate ignore_nice_load directly as we saw. Maybe it is triggering something by e.g. unloading some kernel modules before suspend. I'll try to go into that deeper ... So the bug is probably not in the cpufreq code - thnx for your help anyway.
Created attachment 115621 [details] dmesg after s2ram -f
Created attachment 115631 [details] dmesg after pm-suspend
On 22 November 2013 12:14, <bugzilla-daemon@bugzilla.kernel.org> wrote: > So the bug is probably not in the cpufreq code - thnx for your help anyway. I am sort of relieved now.. I understand CPUFreq code very well and I wasn't able to guess which part screwed it up :)
On a quick glance at the dmesg output I already got a suspect: Calling s2ram directly gives "Restoring governor ONDEMAND for cpu 1" while using pm-suspend leads to "Restoring governor PERFORMANCE for cpu 1" ... Thnx again, Rainer
yes, this looks like a user space issue. So mark this bug as invalid.
Thnx to your help I tracked the issue down: pm-suspend sets - for reasons unknown to me - temporarily a new governor (performance) before suspending and re-enables the old one after resume. However, it seems to fail in storing also the corresponding settings of the governor so all non-default settings like ignore_nice_load=1 are lost :-( Thnx again, Rainer P.S. pm_suspend uses the interface under /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor so the issue didn't arise with older kernels where that option wasn't present or enabled.