# Several things got broken during a major update

## arhenius

Dear All

After a major update to my laptop's gentoo system (last update was in September'10). I had to make several emerge -uvDN world, pearl-cleaner and python-updater. I also did the transition to openRC and baselaytou-2 without trouble and compiled a new kernel (2.6.39-r3). For the most part, everything is working fine in this ASUS UL30VT, including the nvidia card (I'm not trying to switch between videocards because  I'm quite interested in learning some CUDA). 

However, some things got broken and I would like to be able to address some issues:

 /proc/acpi is almost empty 

```
 ls /proc/acpi/

ac_adapter  battery  button  event  wakeup

```

This makes twisting things like cpu throttling and seting LCD brightness a lot more complicated, since I have to use the labirintic /sys directory. Is there any way to get the old /proc/acpi system back? Or a way to understand the /sys directory?

 $battery_time in conky does not showq the expected autonomy. Instead, it only say 'unknown'.  What happened to these very useful feature? I suppose it may have something to do with the migration of the acpi interface from /proc to /sys, but the /proc/acpi/battery folder and files are still present.   :Confused: 

 OpenRC tries to start net.eth0 on every boot. Since most of the time my laptop is not connected, this greatly increases boot time. I'm using wicd for managing this, and in the old init net.eth0 was deleted from the default level after installing wicd. 

```
# rc-update del net.eth0 

 * rc-update: service `net.eth0' is not in the runlevel `default'

 # rc-status 

Runlevel: default

 metalog                                                           [  started  ]

 sshd                                                              [  started  ]

 netmount                                                          [  started  ]

 xdm                                                               [  started  ]

 acpid                                                             [  started  ]

 bluetooth                                                         [  started  ]

 cupsd                                                             [  started  ]

 fcron                                                             [  started  ]

 lighttpd                                                          [  started  ]

 pure-ftpd                                                         [  started  ]

 udev-postmount                                                    [  started  ]

 local                                                             [  started  ]

Dynamic Runlevel: hotplugged

 bluetooth                                                         [  started  ]

 net.eth0                                                          [  stopped  ]

Dynamic Runlevel: needed

 sysfs                                                             [  started  ]

 xdm-setup                                                         [  started  ]

 dbus                                                              [  started  ]

Dynamic Runlevel: manual

```

 cpufreq-set -c 0 -g powersave brings CPU freq to 800MHz but does not alter battery life I thought lowering the cpu frequency would bring some benefits in terms of battery life, but it has no effect on it (even when using this together with the powersave governor).

 (Just a curiosity) I thought Fn+F9 would stop the touchpad, but it has no effect. As anyone figured out how to temporally disable the touchpad?

Thanks in advance for your help.

----------

## DirtyHairy

 *arhenius wrote:*   

> 
> 
>  /proc/acpi is almost empty 
> 
> ```
> ...

 

I think there is a compatibility option somewhere, but from the looks of it, you already have it activated. I don't think it is possible to get back the rest.

 *Quote:*   

> 
> 
>  OpenRC tries to start net.eth0 on every boot. Since most of the time my laptop is not connected, this greatly increases boot time. I'm using wicd for managing this, and in the old init net.eth0 was deleted from the default level after installing wicd. 
> 
> 

 

Have you doublechecked that the script isn't still present in /etc/init.d and perhaps activated in boot?

 *Quote:*   

> 
> 
>  cpufreq-set -c 0 -g powersave brings CPU freq to 800MHz but does not alter battery life I thought lowering the cpu frequency would bring some benefits in terms of battery life, but it has no effect on it (even when using this together with the powersave governor).
> 
> 

 

That's weird, the impact of frequency scaling on battery life is quite dramatic. You should check in /sys/devices/system/cpu[n]/cpufreq whether command actually changes the governor, and if it doesn't, you should try to control it directly with the sysfs files in there.

 *Quote:*   

> 
> 
> (Just a curiosity) I thought Fn+F9 would stop the touchpad, but it has no effect. As anyone figured out how to temporally disable the touchpad?
> 
> 

 

That depends on how this is handled; on some machines, the key is intercepted by an embedded controller and the touchpad is switched of hard, but on most systems, that is just a keystroke like all others. You can switch of the touchpad manually using synclient, and if you like, you can probably create a script for toggling and bind the key to it in your favorite desktop environment.

----------

## arhenius

Hi DirtyHairy, Thanks for the reply.

 *Quote:*   

> Have you doublechecked that the script isn't still present in /etc/init.d and perhaps activated in boot? 

 

net.eth0 was not present at any runlevel. I manage to do a workaround by deleting the net.eth0 file from /etc/init.d.

 *Quote:*   

> 
> 
> That's weird, the impact of frequency scaling on battery life is quite dramatic. You should check in /sys/devices/system/cpu[n]/cpufreq whether command actually changes the governor, and if it doesn't, you should try to control it directly with the sysfs files in there. 

 

I tried to change the frequency on /sys:

```

cpufreq-info 

cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009

Report errors and bugs to cpufreq@vger.kernel.org, please.

analyzing CPU 0:

  driver: acpi-cpufreq

  CPUs which run at the same hardware frequency: 0

  CPUs which need to have their frequency coordinated by software: 0

  maximum transition latency: 10.0 us.

  hardware limits: 800 MHz - 1.30 GHz

  available frequency steps: 1.30 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 1.30 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 1.30 GHz (asserted by call to hardware).

analyzing CPU 1:

  driver: acpi-cpufreq

  CPUs which run at the same hardware frequency: 1

  CPUs which need to have their frequency coordinated by software: 1

  maximum transition latency: 10.0 us.

  hardware limits: 800 MHz - 1.30 GHz

  available frequency steps: 1.30 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 1.30 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 1.30 GHz (asserted by call to hardware).

dirac ~ # cpufreq-set -c 0 -f 8000000

dirac ~ # cpufreq-set -c 1 -f 8000000

dirac ~ # cpufreq-info 

cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009

Report errors and bugs to cpufreq@vger.kernel.org, please.

analyzing CPU 0:

  driver: acpi-cpufreq

  CPUs which run at the same hardware frequency: 0

  CPUs which need to have their frequency coordinated by software: 0

  maximum transition latency: 10.0 us.

  hardware limits: 800 MHz - 1.30 GHz

  available frequency steps: 1.30 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 1.30 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 1.30 GHz (asserted by call to hardware).

analyzing CPU 1:

  driver: acpi-cpufreq

  CPUs which run at the same hardware frequency: 1

  CPUs which need to have their frequency coordinated by software: 1

  maximum transition latency: 10.0 us.

  hardware limits: 800 MHz - 1.30 GHz

  available frequency steps: 1.30 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 1.30 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 1.30 GHz (asserted by call to hardware).

cd /sys/devices/system/cpu/cpu0/cpufreq/

dirac cpufreq # cat cpuinfo_min_freq > cpuinfo_cur_freq 

bash: cpuinfo_cur_freq: Permission denied

dirac cpufreq # cat scaling_max_freq > scaling_setspeed 

(did the same for cpu1)

dirac cpufreq # cat scaling_cur_freq 

1300000

dirac cpufreq # cat scaling_min_freq > scaling_setspeed 

(repeated on cpu1)

dirac cpufreq # cat scaling_cur_freq 

800000

```

Still have the same expected battery life on xfce4-power-manager. cpu-info now shows both processors running at 800MHz.

Conky still doesn't know how many battery time I have left.

 *Quote:*   

> You can switch of the touchpad manually using synclient...

 

No I can't: 

```
filipe@dirac ~ $ synclient 

Couldn't find synaptics properties. No synaptics driver loaded?

```

My touchpad is probably linked to /dev/input/mice and after some exploration of /sys, I found out that during this boot it was identified as mouse1 (mouse0 being my usb mouse).

```

dirac device # pwd

/sys/devices/virtual/input/mice/subsystem/mouse0/device

dirac device # cat uevent 

PRODUCT=3/192f/416/111

NAME="USB Optical Mouse"

PHYS="usb-0000:00:1d.0-2/input0"

UNIQ=""

PROP=0

EV=17

KEY=70000 0 0 0 0

REL=143

MSC=10

MODALIAS=input:b0003v192Fp0416e0111-e0,1,2,4,k110,111,112,r0,1,6,8,am4,lsfw

dirac device #  cd /sys/devices/virtual/input/mice/subsystem/mouse1/device

dirac device # cat uevent

PRODUCT=11/2/5/63

NAME="ImPS/2 Logitech Wheel Mouse"

PHYS="isa0060/serio4/input0"

PROP=0

EV=7

KEY=70000 0 0 0 0

REL=103

MODALIAS=input:b0011v0002p0005e0063-e0,1,2,k110,111,112,r0,1,8,amlsfw

```

Now, I am able to make a script that searches for the rigth mouse and turns it on/off. The problem is that on both devices all power directories were empty, so I don't know how to send the instruction to turn the device on or off. 

Best regards

Filipe

----------

## smartass

Hi Filipe,

here are a few thoughts, they may or may not be helpful in your situation:

1) cpufreq scaling is not the only way to increase the battery life, I've heard of cpus for which power consumption does not vary that much with freq scaling

I believe using something like laptop-mode-tools or/with pm-powersave and maybe hdparm can be also rewarding

2)I'd be interested in the output of 

```
lsmod|grep freq
```

even if you have loaded acpi_cpufreq, just make sure that it's not a module from the older kernel if you used to load it automatically before

3)ever heard of the the ASPM bug?

http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=3

if the output of 

```
cat /sys/module/pcie_aspm/parameters/policy
```

 is something like

```
[default] performance powersave
```

you should not be affected

----------

## s4e8

for the net.eth0 delay, the easiest way is "emerge ifplugd".

----------

## VoidMage

 *s4e8 wrote:*   

> for the net.eth0 delay, the easiest way is "emerge ifplugd".

 

...or sys-apps/netplug.

----------

