http://bugzilla.novell.com/show_bug.cgi?id=580988 http://bugzilla.novell.com/show_bug.cgi?id=580988#c yang xiaoyu 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#c Jean Delvare 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#c3 --- Comment #3 from Jean Delvare 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#c5 --- Comment #5 from Francis Lamonde 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#c7 --- Comment #7 from Francis Lamonde 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#c9 --- Comment #9 from Jean Delvare 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#c11 Jean Delvare changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kronos.it@gmail.com --- Comment #11 from Jean Delvare 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#c13 --- Comment #13 from Jean Delvare 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.