[Bug 580988] New: Service 'fancontrol' stops and cannot be restarted after coming back from "Suspend to RAM" hibernate
From that point, my workaround is to manually kill it once, than manually start/stop it very time I suspend to RAM. I stop it before I suspend to RAM,
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c0 Summary: Service 'fancontrol' stops and cannot be restarted after coming back from "Suspend to RAM" hibernate Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: frankebay99@gmail.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 openSUSE 11.2 final 64-bits. In /etc I have the file 'fancontrol', which got setup by 'pwmconfig' program. Every boot it starts running in KDM and controls fan speeds according to my personal needs. When I hibernate to RAM (Suspend to RAM function) and come back up, 'fancontrol' is not working. The BIOS then automatically takes over the fan speeds, just like if I had no 'fancontrol' file in /etc. That is not what a user should expect. Then if I go in konsole and try to start 'fancontrol' by typing the usual 'sudo fancontrol' command, it says the service is already running and refuses to start it up. Since it thinks the service is not running, I cannot stop it and restart it. Somehow with a grep on fancontrol I was able to find it in TOP command and killed it so that I could start it up again. then when I come back up I manually start it (from konsole). That is not an expected behavior. I did not try Suspend to DISK function yet. Should I? Suspend to DISK is not a 100% valid workaround for me, as Suspend to RAM is *much* quicker than suspend to DISK and does not require going over a full BIOS boot process. Reproducible: Always Steps to Reproduce: 1. Have 'fancontrol' control your fan speeds; 2. Suspend to RAM; 3. Come back from hibernate. Actual Results: 'fancontrol' actually stops working (and transfers the fans control over to the BIOS as default), but cannot be restarted due to the fact the system thinks it is still running and needs to be killed and manually controlled from now on. Expected Results: 'fancontrol' should either remain started, or stop when suspending to RAM and restart when coming back from hibernate. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c yang xiaoyu <xyyang@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xyyang@novell.com AssignedTo|bnc-team-screening@forge.pr |jdelvare@novell.com |ovo.novell.com | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c1 Jean Delvare <jdelvare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |ASSIGNED --- Comment #1 from Jean Delvare <jdelvare@novell.com> 2010-02-25 08:20:50 UTC --- Thanks for the detailed bug report. There is some inconsistency in it though, as well as missing information. Let's try to iron it out. 1* When you resume from suspend-to-RAM and fancontrol was running before, you say that you can't run fancontrol because "it says the service is already running and refuses to start it up" but at the same time you say: "Since it thinks the service is not running, I cannot stop it and restart it." I have a hard time understanding how both statements can be true at the same time. Please double check and provide the exact error messages you get when trying both. 2* Does a plain "sensors" return meaningful values after suspend-to-RAM? Do some values differ significantly between before and after suspend-to-RAM? Please attach the outputs of sensors before and after suspend-to-RAM for comparison purposes. Chances are high that the problem isn't in fancontrol itself but in the underlying kernel drivers your system needs for fan speed control. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c Jean Delvare <jdelvare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |frankebay99@gmail.com -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c2 --- Comment #2 from Francis Lamonde <frankebay99@gmail.com> 2010-02-26 02:20:51 UTC --- You are right, it wasn't easy to explain. Let's do it step by step. I will answer to *1 now and *2 partly now and fully on next suspend-to-RAM. *1 When fancontrol runs and I suspend-to-RAM (hereby and forever called STR), everything's ok during the suspend process. When I come back from STR, my fancontrol does not run, I mean for real, the actions/results fancontrol is providing normally is not happening, the fans are running at BIOS's speed, based on BIOS's settings to control the fans. Then I go in konsole and type the usual 'sudo fancontrol' to start it up, cuz to my eyes it is not running since the fans are controlled at the BIOS's settings (I know those settings, they increase by 200rpm my fans, I have set it up this way). When I start fancontrol after STR, the following happens: === Loading configuration from /etc/fancontrol ... Common settings: INTERVAL=5 Settings for hwmon5/device/pwm1: Depends on hwmon5/device/temp1_input Controls hwmon5/device/fan1_input MINTEMP=27 MAXTEMP=33 MINSTART=110 MINSTOP=110 MINPWM=110 MAXPWM=255 Settings for hwmon5/device/pwm2: Depends on hwmon5/device/temp2_input Controls hwmon5/device/fan2_input MINTEMP=28 MAXTEMP=40 MINSTART=105 MINSTOP=105 MINPWM=85 MAXPWM=255 File /var/run/fancontrol.pid exists, is fancontrol already running? === The .pid is running to the eyes of the kernel or whichever god controls the processes. But for real it's not controlling anything and when fancontrol does not control the fans, the BIOS takes over. I think I was not clear when I said "it thinks the service is NOT running". We should remove that statement. I CAN stop it and restart it, though really not the usual way. What I need to do is a 'sudo top | egrep fancontrol' After about 4-5 secs it finds the pid and returns something like 11738 root 20 0 12564 1728 1312 S 0 0.0 0:04.63 fancontrol So that I can 'sudo kill 11738' (11738 is subject to change of course) And then to start it up 'sudo fancontrol' It's a little less complicated then I originally thought, but still, fancontrol remains a pid part of top, though the service is really not running since the fans speeds are then controlled by the BIOS. When I restart fancontrol, the fan speeds immediately drop 200rpm like they should. These above steps need to be performed after each STR. *2 (partly) I suspect 'sensors' will return the real temps and speeds. I use gkrellm for all my sensors, gkrellm gets sensors' values and the values correspond to what they should be when the BIOS is controlling the speeds, not fancontrol. I will give it a true 'sensors' and see if it matches what I expect. I also don't believe it's fancontrol itself either. It really seems to be how the deamon or don't know what is controlling the fancontrol service. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c3 --- Comment #3 from Jean Delvare <jdelvare@novell.com> 2010-02-26 09:48:32 UTC --- OK, thanks for the clarification. Regarding 1*, you should be able to get fancontrol to work again after STR with "rclm_sensors restart" as root. This would be less tedious than your current approach. Please confirm that it does the trick. The "daemon" is fancontrol itself. There's nothing running on top of it. The real fix will most likely happen in one of the kernel drivers, which is one of the reasons why I wanted to see the output of "sensors": it will tell me which driver(s) you are using. The BIOS must be changing the state of your hardware monitoring chip, and its Linux driver should save and restore this state when going through a STR cycle. That being said, a user-space workaround would be possible, by simply restarting the lm_sensors service automatically at resume time (assuming your testing is positive.) I don't know if that would be considered clean enough as a permanent solution though. Reloading kernel drivers is obviously slower than having the drivers themselves perform the needed reinitialization. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c4 --- Comment #4 from Jean Delvare <jdelvare@novell.com> 2010-02-26 09:52:01 UTC --- Created an attachment (id=345080) --> (http://bugzilla.novell.com/attachment.cgi?id=345080) Candidate sleep.d script for lm_sensors This is a candidate sleep.d script for lm_sensors. You can copy it to /usr/lib/pm-utils/sleep.d to give it a try. I expect it to solve your problem, but I'm not yet sure if this can be considered the right fix. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c5 --- Comment #5 from Francis Lamonde <frankebay99@gmail.com> 2010-02-26 21:25:51 UTC --- Ok so 'sensors' before STR returns CHASSIS FANS around 611rpm (let's forget CPU FAN). Then STR. Then waking up from STR (letting CPU, Cores and Case temps increasing to normal and idle temps for better comparison). Then 'sensors' returns this: == atk0110-acpi-0 Adapter: ACPI interface Vcore Voltage: +1.16 V (min = +0.85 V, max = +1.60 V) +3.3 Voltage: +3.30 V (min = +2.97 V, max = +3.63 V) +5 Voltage: +4.94 V (min = +4.50 V, max = +5.50 V) +12 Voltage: +11.98 V (min = +10.20 V, max = +13.80 V) CPU FAN Speed: 878 RPM (min = 600 RPM) CHASSIS1 FAN Speed: 811 RPM (min = 600 RPM) CHASSIS2 FAN Speed: 770 RPM (min = 600 RPM) CHASSIS3 FAN Speed: 781 RPM (min = 800 RPM) CPU Temperature: +25.0°C (high = +60.0°C, crit = +95.0°C) MB Temperature: +27.0°C (high = +45.0°C, crit = +95.0°C) coretemp-isa-0000 Adapter: ISA adapter Core 0: +40.0°C (high = +82.0°C, crit = +100.0°C) coretemp-isa-0001 Adapter: ISA adapter Core 1: +39.0°C (high = +82.0°C, crit = +100.0°C) coretemp-isa-0002 Adapter: ISA adapter Core 2: +32.0°C (high = +82.0°C, crit = +100.0°C) coretemp-isa-0003 Adapter: ISA adapter Core 3: +36.0°C (high = +82.0°C, crit = +100.0°C) w83627dhg-isa-0290 Adapter: ISA adapter Vcore: +1.16 V (min = +0.00 V, max = +1.74 V) in1: +1.71 V (min = +1.02 V, max = +1.02 V) ALARM AVCC: +3.30 V (min = +1.02 V, max = +0.54 V) ALARM VCC: +3.30 V (min = +2.06 V, max = +1.15 V) ALARM in4: +1.38 V (min = +0.51 V, max = +0.05 V) ALARM in5: +1.65 V (min = +0.01 V, max = +1.03 V) ALARM in6: +1.39 V (min = +0.26 V, max = +0.00 V) ALARM 3VSB: +3.30 V (min = +0.00 V, max = +0.29 V) ALARM Vbat: +3.26 V (min = +2.06 V, max = +2.08 V) ALARM fan1: 795 RPM (min = 2636 RPM, div = 32) ALARM fan2: 902 RPM (min = 1298 RPM, div = 8) ALARM fan3: 795 RPM (min = 2636 RPM, div = 32) ALARM fan5: 770 RPM (min = 1318 RPM, div = 8) ALARM temp1: +27.0°C (high = +9.0°C, hyst = +80.0°C) sensor = thermistor temp2: +25.0°C (high = +80.0°C, hyst = +75.0°C) sensor = diode temp3: +121.5°C (high = +80.0°C, hyst = +75.0°C) ALARM sensor = thermistor === CHASSIS FANS are around 811 when I wake up from STR (and computer is colder at that point in time). I know I can control my fans based on 2 drivers, the 'atk0110' and the usual 'hwmon'. I use the 'hwmon' cuz I have a kernel parm setup at boot time in menu.lst which states the following: 'acpi_enforce_resources=lax' to support some legacy apci stuff, this changed starting with kernel 2.6.30 to prevent some very rare situations where something really bad could happen on a machine and it would kill all fans, leaving no control over temp increases. This is not my case, I verified on the web which machines this could happen to and how. I found much harder to get the sensors setup with 'atk0110' driver, 'pwmconfig' did not want to run so I went back with legacy support. 'rclm_sensors restart' seems to work. It restarted sensors and fancontrol Shutting down sensors, stopping fan control: done Starting up sensors, starting fan control: done It's just that today is warmer in my place, by 2-3C, so now the case temps have gone up 1-2C over the usual, it's now too late for me to compare. The comparison I did above is good though, cuz at the time I typed in 'sensors' the temps were as usual (cpu-case 28-26). I'm running fancontrol and gkrellm for over 2 years, I know my sensor values by heart and I can predict how they will behave when I come across a change in the normal situation (just like now). This is really good to get valid tests and results and compare what should be compared. Let me try something else. If I kill fancontrol now and restart it, the way I was doing before, my speeds should come back to what they are now. And they do. This tells me 'rclm_sensors restart' works, cuz fancontrol was working, I killed it and restarted it. Each increment of my fancontrol settings never match the ones of my BIOS. This is another trick for me to know if fancontrol runs or not. :) I will try your script. If it works, we'll see how valid a fix this is, but if it does work, I will certainly keep it until something better, if better is possible, will exist. I should post results this w-e. tnx -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c6 --- Comment #6 from Francis Lamonde <frankebay99@gmail.com> 2010-02-26 21:30:24 UTC --- I don't see a file name in the attachment, so I called it '80lm_sensors' -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c7 --- Comment #7 from Francis Lamonde <frankebay99@gmail.com> 2010-02-26 21:31:27 UTC --- Oh sorry I clicked on the wrong place, clicking on 'details' I can see the filename you gave. Which is the same I gave, so I am not that bad. :) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c8 --- Comment #8 from Francis Lamonde <frankebay99@gmail.com> 2010-03-01 02:30:56 UTC --- Oh, unfortunately the 80lm_sensors script did not work. Let me check I have given the executable attribute... Yes, it's executable. I did not get anything weird when I came back from STR, everything seemed to be exactly as before. Fans were running at higher speed, I checked in top and fancontrol was there, so I did the magical 'rclm_sensors restart' and it came back to normal. This means the script either did not run or failed. I do not know which log file can troubleshoot that, if any? BTW at the same time I created another file in sleep.d, '96cairo-dock', for which I took your script and changed the line where you start the sensors to start 'cairo-dock -o'. That didn't work either. I close cairo-dock when I STR, cuz there is a bug with nvidia drivers when it comes back from STR, a few icons become blank or white border around so I need to restart CD. If it didn't work, maybe I screwed up that script or the same problem as yours happened on mine... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c9 --- Comment #9 from Jean Delvare <jdelvare@novell.com> 2010-03-01 14:15:03 UTC --- I see that you are using both the ACPI-based asus_atk0110 monitoring driver and the native w83627ehf monitoring driver. Both access the same physical device, without any locking. This is VERY BAD and may explain at least part of your problems. You must only use ONE of these drivers at any given time. I presume that you passed an extra kernel parameter in order to be able to use the w83627ehf driver? It would have been fair to let me know as part of the initial bug report. If you did that as I suspect, then you MUST disable automatic fan speed control in the BIOS and you MUST prevent the asus_atk0110 driver from loading (blacklisting it should do the trick.) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c10 --- Comment #10 from Francis Lamonde <frankebay99@gmail.com> 2010-03-01 14:40:54 UTC --- Correct, I did mention I was not fully using atk0110 and that I was using a kernel parm. See Comment #5. I followed a procedure I found on the web, cuz I wasn't able to setup fancontrol using atk0110 (pwmconfig couldn't find any compatible driver or something), so I wanted to revert back to native w83627, using that kernel parm (acpi_resources=lax). Apparently, on my machine it has no harm, the date of my machine is too old (end of 2007) and using both drivers was bad only on more recent MBs. Now maybe that isn't fully true... If that is part of the problem, fine. I will take a look to disable automatic fan control in the BIOS (I hope I have the option). To blacklist atk0110, do you know how to do that? What I have found seems to require compiling the kernel. Maybe as another option I could try to have pwmconfig work with atk0110. And see if fancontrol starts up normally when coming back from STR. Do you have any preference? I think to make sure I should try both. First running only the native driver and see what happens and then trying the atk0110 (if I succeed with pwmconfig). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c11 Jean Delvare <jdelvare@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kronos.it@gmail.com --- Comment #11 from Jean Delvare <jdelvare@novell.com> 2010-03-07 14:25:47 UTC --- The asus_atk0110 driver interfaces with an ACPI implementation found on many recent Asus mainboards. This intermediate layer between the kernel and the hardware induces limits to what can be done, and in particular, manual fan speed control is not supported. So it is expected that pwmconfig doesn't work when using the asus_atk0110 driver. No amount of work on your end will help. When using the asus_atk0110 driver, you must configure the thermal profile in the BIOS, and then let the BIOS control the fan speed automatically for you. I have received mixed feedback from the users, apparently the BIOS profiles are too coarse-grained for many, but that's the best you have. Using the asus_atk0110 driver is also the only supported method. if you decide to use a native driver instead, you are essentially unsupported. Things may work, but if they do not, there's nothing we can do to help. Using both the asus_atk0110 driver and a native driver at the same time for the same chip is BAD for ALL boards. If you were told otherwise, you were misinformed. Blacklisting the asus_atk0110 driver can be done by adding the following line to any *.conf file in /etc/modprobe.d: blacklist asus_atk0110 No kernel recompilation is needed. But then again, if you go that route, you are unsupported. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c12 --- Comment #12 from Francis Lamonde <frankebay99@gmail.com> 2010-03-07 14:49:13 UTC --- Ok, so if I understood correctly, I have 2 options: 1- I use native driver (and blacklist atk0110, tnx for showing me how). Benefit: fancontrol works and will control my fan speed. Downside: I am unsupported and too bad for STR-STD I would have to find a workaround myself or live with it. 2- I use atk0110 driver. Benefit: I am supported. Downside: pwmconfig, in my case, does not work and no amount of work may make it work, therefore I cannot use fancontrol to control my fan speeds. Did I understand correctly the situation and available options? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c13 --- Comment #13 from Jean Delvare <jdelvare@novell.com> 2010-03-07 15:06:34 UTC --- Yes, you did. That being said, why the 80lm_sensors script did not work is still a mystery to me. But I am not too familiar with pm-utils either, I'll have to take a closer look to find out how to get it to work. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=580988 https://bugzilla.novell.com/show_bug.cgi?id=580988#c14 Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED InfoProvider|frankebay99@gmail.com | Resolution| |NORESPONSE --- Comment #14 from Andreas Jaeger <aj@suse.com> 2012-07-03 18:38:50 UTC --- This bug has been for over two years in state NEEDINFO. I'm closing it as NORESPONSE now. Feel free to reopen once you have supplied the requested information and can reproduce the issue with current openSUSE (12.1/12.2). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com