[opensuse] 12.3 and acpi vs. lm_sensors, cpufreq, fancontrol (nvidia graphics) and power-off

Carl Hartung

22 Mar 2013 22 Mar '13

19:04

Hi All, Unlike the prior quiet running 11.4 (x86_64/GNOME2) installation I had on this system, 12.3 (x86_64/KDE) is exhibiting the following: a) At installation via DVD, the system hung almost immediately at udev. Typing 'acpi=off' before selecting 'Installation' circumvented the hang. b) 12.3 is beautiful, and fast! Thanks everyone! I love it :-) But I seem to have lost correct sensor driven GPU fan control. It now has only two speeds ... loud and loudest o_O. It starts out in 'loudest' mode then eventually drops to 'loud'. Very annoying. c) Selecting 'Leave' then 'Shut down' works right up to the point where nothing is mounted, no processes are running and the system is not in any way responsive ... but it does not power-off. Pressing and holding the power button briefly turns it off. (Interestingly, 'Leave' and 'Restart' works.) The system is an ASUS laptop, model X83VB-X1, with nVidia GeForce 9300M GS graphics adapter (512 MB video RAM.) The mainboard is an 'N80VB (ver. 1)'. It's configured with 4 GB RAM and an internal 500 GB SATA HD. These symptoms strike me as related to ACPI (and to the 'acpi=off' invocation at install.) After a bit of research, I followed the steps described here: https://bugzilla.novell.com/show_bug.cgi?id=810344 (03/19/2013, 12.3, status "NEW"; "Summary: fancontol not starting") No joy. Just these afterward from '# systemctl list-units' (results wrapped by me): lm_sensors.service loaded active exited Initialize hardware monitoring sensors cpufreq.service loaded failed failed LSB: CPUFreq modules loader fancontrol_local.service loaded failed failed Initialize fancontrol There's also this: # fancontrol --help Loading configuration from /etc/fancontrol ... Error: Can't read configuration file [Related, but tangential: Under 11.4 GNOME2, I ran a taskbar applet which graphically displayed the activity of each core, side by side, in addition to the CPU operating frequency. It usually ran at 800 MHz and only peaked 'on demand' nicely at 2.0 GHz -- and I could tell this by the sound of the fans. Is there a KDE equivalent to that applet available? I like being able to tell at a glance when the system is peaking 'on demand.'] These are the _only_ wrinkles remaining to be ironed out on this otherwise beautiful installation. I'd like to avoid burning out the GPU and/or it's fan while undergoing my combined 12.3 / KDE / systemd learning curve. Ideas and suggestions will be gratefully appreciated. TIA & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Cristian Rodríguez

22 Mar 22 Mar

19:51

El 22/03/13 16:04, Carl Hartung escribió:

...

Hi All,

Unlike the prior quiet running 11.4 (x86_64/GNOME2) installation I had on this system, 12.3 (x86_64/KDE) is exhibiting the following:

a) At installation via DVD, the system hung almost immediately at udev. Typing 'acpi=off' before selecting 'Installation' circumvented the hang.

OK, udev "hanging" without "acpi=off" is a bug in the kernel, please file one, however acpi=off is like a using a tank to kill ants. You need to figure exactly what piece is broken.

...

The system is an ASUS laptop, model X83VB-X1, with nVidia GeForce 9300M GS graphics adapter (512 MB video RAM.) The mainboard is an 'N80VB (ver. 1)'. It's configured with 4 GB RAM and an internal 500 GB SATA HD.

Ok, the "nouveau" driver does not handle the nvidia card fans properly, this is a known problem, my only suggestion will be installing the nvidia propietary driver.

...

cpufreq.service loaded failed failed LSB: CPUFreq modules loader

The CPUfreq service is a legacy x86 specific thing, that was needed in the distant past when the kernel did not autoload the needed drivers, you should mask it. systemctl mask cpufreq Now, in the case the kernel does not autoload a cpufreq driver, you have to fill a bug report in the kernel, doing this is not userspace work.

...

These are the _only_ wrinkles remaining to be ironed out on this otherwise beautiful installation. I'd like to avoid burning out the GPU and/or it's fan while undergoing my combined 12.3 / KDE / systemd learning curve. Ideas and suggestions will be gratefully appreciated.

the GPU issue only solution is to install the nvidia propietary driver. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carl Hartung

20:51

On Fri, 22 Mar 2013 16:51:08 -0300 Cristian Rodríguez wrote:

...

OK, udev "hanging" without "acpi=off" is a bug in the kernel, please file one, however acpi=off is like a using a tank to kill ants. You need to figure exactly what piece is broken.

Thank you for your feedback, Cristian. Very much appreciated! Yes, 'acpi=off' is overkill, but it allowed the installation to proceed. :-) The 'hang on udev' bug seems to only affect the installation kernel and I'm pretty sure it's already been reported.

...

...
The system is an ASUS laptop, model X83VB-X1, with nVidia GeForce 9300M GS graphics adapter (512 MB video RAM.) The mainboard is an 'N80VB (ver. 1)'. It's configured with 4 GB RAM and an internal 500 GB SATA HD.

Ok, the "nouveau" driver does not handle the nvidia card fans properly, this is a known problem, my only suggestion will be installing the nvidia propietary driver.

I'm going to explore my 11.4 backup to see how this was being handled there. Even with the proprietary driver the fan is stuck in 'middle gear,' i.e. on 'high' after booting then a short while later throttling back ... just a bit. Thanks again! Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

20:59

El 22/03/13 17:51, Carl Hartung escribió:

...

I'm going to explore my 11.4 backup to see how this was being handled there. Even with the proprietary driver the fan is stuck in 'middle gear,' i.e. on 'high' after booting then a short while later throttling back ... just a bit.

the propietary driver comes with a tool "nvidia X server settings" that you can use to control the thermal settings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

23 Mar 23 Mar

04:04

В Fri, 22 Mar 2013 16:51:08 -0300 Cristian Rodríguez пишет:

...

...
cpufreq.service loaded failed failed LSB: CPUFreq modules loader

The CPUfreq service is a legacy x86 specific thing, that was needed in the distant past when the kernel did not autoload the needed drivers, you should mask it.

systemctl mask cpufreq

Who should load governors then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

04:08

El 23/03/13 01:04, Andrey Borzenkov escribió:

...

Who should load governors then?

the kernel.. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

04:15

В Sat, 23 Mar 2013 01:08:39 -0300 Cristian Rodríguez пишет:

...

El 23/03/13 01:04, Andrey Borzenkov escribió:

...
Who should load governors then?

the kernel..

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea...

I rephrase - how should kernel know *which* governor to load? "Policy belongs to userspace not kernel", does not it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

05:17

On 03/23/2013 01:15 AM, Andrey Borzenkov wrote:

...

В Sat, 23 Mar 2013 01:08:39 -0300 Cristian Rodríguez пишет:

...
El 23/03/13 01:04, Andrey Borzenkov escribió:

...
Who should load governors then?

the kernel..

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea...

I rephrase - how should kernel know *which* governor to load? "Policy belongs to userspace not kernel", does not it?

Correct, userspace should direct the kernel modifing /sys/devices/system/cpu/cpuN/cpufreq/scaling_governor with an specilized app (cli or desktop) but not directly in a generic init script.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carl Hartung

22 Mar 22 Mar

19:56

On Fri, 22 Mar 2013 15:04:45 -0400 Carl Hartung wrote: <snipped> Update: Removing "acpi=off" from /etc/default/grub then running 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterward restored correct powering down of the laptop. It also resolved the failed 'cpufreq' service under systemd: from '# systemctl list-units' (wrapped by me): cpufreq.service loaded active exited LSB: CPUFreq modules loader However, the 'fancontrol_local.service' I created still fails: fancontrol_local.service loaded failed failed Initialize fancontrol regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez

21:01

El 22/03/13 16:56, Carl Hartung escribió:

...

On Fri, 22 Mar 2013 15:04:45 -0400 Carl Hartung wrote: <snipped>

Update:

Removing "acpi=off" from /etc/default/grub then running 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterward restored correct powering down of the laptop. It also resolved the failed 'cpufreq' service under systemd:

Yes, most "power control" stuff in x86 depends on acpi, and a lot of other functionality too..

...

However, the 'fancontrol_local.service' I created still fails:

fancontrol_local.service loaded failed failed Initialize fancontrol

What do you have in the fancontrol_local service and what fans you pretend to control with it ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carl Hartung

23 Mar 23 Mar

00:09

New subject: [SOLVED] Re: [opensuse] 12.3 and acpi vs. lm_sensors, cpufreq, fancontrol (nvidia graphics) and power-off

On Fri, 22 Mar 2013 18:01:41 -0300 Cristian Rodríguez wrote:

...

El 22/03/13 16:56, Carl Hartung escribió:

...
On Fri, 22 Mar 2013 15:04:45 -0400 Carl Hartung wrote: <snipped>

Update:

Removing "acpi=off" from /etc/default/grub then running 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterward restored correct powering down of the laptop. It also resolved the failed 'cpufreq' service under systemd:

Yes, most "power control" stuff in x86 depends on acpi, and a lot of other functionality too..

...
However, the 'fancontrol_local.service' I created still fails:

fancontrol_local.service loaded failed failed Initialize fancontrol

What do you have in the fancontrol_local service and what fans you pretend to control with it ?

It's attached as a proposed solution to the bug report that I originally referenced: https://bugzilla.novell.com/show_bug.cgi?id=810344 It obviously didn't work in my case so I backed it out. I've marked the thread 'solved' because my fan is now cycling properly between 'quiet', 'loud' and 'louder,' as it did before. However, KDE4 has /way/ more eye candy. I'm just going to have to get used to it being a bit louder more frequently than it was before. For certain the original problems I inquired about are solved. Here's what did it for me: a) removing "acpi=off" from /etc/default/grub b) running "grub2-mkconfig -o /boot/grub2/grub.cfg" afterward c) installing the proprietary nVidia driver That's it! Thanks again for your input, Cristian! Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov

04:02

New subject: [SOLVED] Re: [opensuse] 12.3 and acpi vs. lm_sensors, cpufreq, fancontrol (nvidia graphics) and power-off

В Fri, 22 Mar 2013 20:09:08 -0400 Carl Hartung пишет:

...

On Fri, 22 Mar 2013 18:01:41 -0300 Cristian Rodríguez wrote:

...
El 22/03/13 16:56, Carl Hartung escribió:

...
On Fri, 22 Mar 2013 15:04:45 -0400 Carl Hartung wrote: <snipped>

Update:

Removing "acpi=off" from /etc/default/grub then running 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterward restored correct powering down of the laptop. It also resolved the failed 'cpufreq' service under systemd:

Yes, most "power control" stuff in x86 depends on acpi, and a lot of other functionality too..

...
However, the 'fancontrol_local.service' I created still fails:

fancontrol_local.service loaded failed failed Initialize fancontrol

What do you have in the fancontrol_local service and what fans you pretend to control with it ?

It's attached as a proposed solution to the bug report that I originally referenced:

https://bugzilla.novell.com/show_bug.cgi?id=810344

It obviously didn't work in my case so I backed it out.

If you have some new information relevant for this bug report, it is prudent to add it to comment there. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carl Hartung

04:33

New subject: [SOLVED] Re: [opensuse] 12.3 and acpi vs. lm_sensors, cpufreq, fancontrol (nvidia graphics) and power-off

On Sat, 23 Mar 2013 08:02:37 +0400 Andrey Borzenkov wrote:

...

If you have some new information relevant for this bug report, it is prudent to add it to comment there.

I would, Andrey, but it seems I picked a wrong bug report; ultimately a 'dead end.' Similar symptoms, different causation. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Rodney Baker

10:30

On Fri, 22 Mar 2013 15:04:45 Carl Hartung wrote:

...

[...]

c) Selecting 'Leave' then 'Shut down' works right up to the point where nothing is mounted, no processes are running and the system is not in any way responsive ... but it does not power-off. Pressing and holding the power button briefly turns it off. (Interestingly, 'Leave' and 'Restart' works.)

This is because installing with "acpi=off" has caused this parameter to be copied to the grub2 command line. If you press "e" to edit the grub2 command at boot time and remove "acpi=off", then press ctrl-x to boot, you'll find it will work OK. The catch is that this is not a permanent change - you'll need to modify the grub2 default configs and rebuild the boot configuration for the change to stick. Unfortunately this is nowhere near as easy as editing menu.lst any more. :-( I did it but I can't remember exactly what I did now. Others may be able to help, or if all else fails there is google. Sorry I can't be more specific on that point. I know it is frowned upon but I may have even hand-edited the relevant grub2 config file in /boot/grub2. That is not the kosher way to do it and if you do it that way, next time you update the kernel and the grub2 configs are rebuilt your changes will be lost. I just can't remember off the top of my head which file(s) needed to be edited to fix it and make it stick. There was a bug report about this and I'm pretty sure I commented on it with more details. https://bugzilla.novell.com/show_bug.cgi?id=794889 Regards, Rodney. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Mariusz Fik

14:51

Dnia piątek, 22 marca 2013 15:04:45 Carl Hartung pisze:

...

c) Selecting 'Leave' then 'Shut down' works right up to the point where nothing is mounted, no processes are running and the system is not in any way responsive ... but it does not power-off. Pressing and holding the power button briefly turns it off. (Interestingly, 'Leave' and 'Restart' works.)

I had similar issue after upgrade 12.2 → 12.3 with Dell Vostro 3450. But after some time it finally shuts down. I used this url to debug problem: http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Ev... But proper path to debug.sh file in openSUSE is /usr/lib/systemd/system- shutdown/debug.sh Then I found that acpid.service reaches timeout so I stopped and disabled this service with: | systemctl stop acpid.service | systemctl disable acpid.service Now, system shutdowns quite fast. -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member GPG: 5FCE 7241 B3B9 32FD 455B C30E 42D6 6C88 9E83 7C3D

4118

Age (days ago)

4119

Last active (days ago)

List overview

Download

14 comments

5 participants

participants (5)

Andrey Borzenkov
Carl Hartung
Cristian Rodríguez
Mariusz Fik
Rodney Baker