You are not logged in.
Hi, I'm trying to get s2ram and cpu frequency scaling working on a Dell M1330.
Frequency scaling is working after a fresh reboot and even after suspending to disk (checked with cpufreq-info). But after doing a s2ram I get (german output):
> cpufreq-info:
analysiere CPU 0:
Treiber: acpi-cpufreq
...
analysiere CPU 1:
kein oder nicht bestimmbarer cpufreq-Treiber aktiv
, which means: no or not determinable cpufreq driver active.
In the Gentoo-Forums, I discovered a solution for a similar problem. Basically it should be fixed if I remove the acpi_cpufreq module before suspending and reinserting it afterwards. However, trying to unload the acpi_cpufreq module results in:
> rmmod acpi_cpufreq
ERROR: Module acpi_cpufreq is in use
> rmmod -f acpi_cpufreq
ERROR: Removing 'acpi_cpufreq': Resource temporarily unavailable
I'd be glad to hear if someone knows a solution to this problem
Update: When the scaling is broken and I suspend to disk, scaling works after resuming. I think this occurs because the acpi_cpufreq module is correctly reinserted when the saved RAM-Image is being loaded from the disk. But I'm still unable to reproduce something similar without rebooting or resuming from s2disk
Last edited by jchtt (2008-03-09 11:09:11)
Offline
Has really no one an idea how to unload acpi_cpufreq ?
Offline
hello!
i also have a m1330 and the same problem.
i tried to unload acpi_cpufreq while suspending (i'm using pm-utils), but it does not work.
sorry for my bad english
Offline
Investigating my system, I fount out that indeed acpi_cpufreq seems to be used by something.
> lsmod
Module Size Used by
...
acpi_cpufreq 12464 2 <---
freq_table 4640 1 acpi_cpufreq
processor 33688 3 acpi_cpufreq
pata_acpi 6784 0
libata 153392 4 pata_acpi,ata_piix,ahci,ata_generic
However, there is no indication of by what module or process it is being used. Does anyone know how to figure this out?
Offline
I'll be glad to hear from that too... My Dell Latitude D830 has the same problem (suspending with the hibernate-scripts though)
Offline
Hi big_gie, thanks for your reply.
My Dell Latitude D830 has the same problem...
That's weird tough, because the workaround by unloading acpi_cpufreq was made up for a Latitude 630. If unloading doesn't work there either, it's probably a problem with the acpi_cpufreq module?
Last edited by jchtt (2008-03-03 15:44:16)
Offline
yeah probably...
I cannot unload that module too because it seems in use. I'm using my own compiled kernel though (with tuxonice) so that might be the problem but I've never been able to figure this one
I think it could have something to do with the CPU hotplug...
Offline
Try the following command after suspending to set the driver manually: (Replace ondemand by whatever driver you want to use)
echo "ondemand" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
Offline
I had tried playing with /sys files without results. The second core is just dead at resume... there is no /sys/devices/system/cpu/cpu1 directory, only /sys/devices/system/cpu/cpu0. I'll try to post more info from a suspend/resume cycle.
Offline
I had tried playing with /sys files without results. The second core is just dead at resume... there is no /sys/devices/system/cpu/cpu1 directory, only /sys/devices/system/cpu/cpu0. I'll try to post more info from a suspend/resume cycle.
Offline
Happens on my vostro 1500 as well (nearly identical to the 1330, so it's not really a surprise).
There are some interesting dmesg errors that come up, unfortunately I'm not on my laptop now so I can't share them. But typing
dmesg |grep -i err
should show them.
Cthulhu For President!
Offline
Ok, I suspended to ram and here is my dmesg: http://paste.uni.cc/18450
Interesting parts:
[...]
[boot]
[ 19.456718] rtc_cmos: probe of 00:03 failed with error -16
[...]
[do suspend]
[do resume]
[...]
[ 0.466147] ACPI Error (psloop-0136): Found unknown opcode FE at AML address ffffc2000003e3ca offset 3, ignoring [20070126]
[ 0.466162] ACPI Error (psloop-0136): Found unknown opcode 1F at AML address ffffc2000003e3cd offset 6, ignoring [20070126]
[ 0.466178] ACPI Error (psloop-0136): Found unknown opcode 2 at AML address ffffc2000003e3d4 offset D, ignoring [20070126]
[ 0.466194] ACPI Error (psloop-0136): Found unknown opcode C2 at AML address ffffc2000003e3d6 offset F, ignoring [20070126]
[ 0.466217] ACPI Error (psargs-0355): [E] Namespace lookup failure, AE_NOT_FOUND
[ 0.466230] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff81007e7e4180), AE_NOT_FOUND
[ 0.466350] ACPI Exception (processor_perflib-0170): AE_NOT_FOUND, Evaluating _PCT [20070126]
Now cpufreq-info reports problem:
> LANG=C cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 800 MHz - 2.00 GHz
available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance
current policy: frequency should be within 800 MHz and 800 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
analyzing CPU 1:
no or unknown cpufreq driver is active on this CPU
> ls /sys/devices/system/cpu/cpu1/
total 0
drwxr-xr-x 5 0 mar 3 14:51 cache
drwxr-xr-x 5 0 mar 3 09:37 cpuidle
drwxr-xr-x 2 0 mar 3 14:58 thermal_throttle
drwxr-xr-x 2 0 mar 3 14:58 topology
-r-------- 1 4,0K mar 3 14:58 crash_notes
-rw-r--r-- 1 4,0K mar 3 14:58 online
Offline
Hm, I get the same pre-suspend error, along with an additional one:
ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[...]
rtc_cmos: probe of 00:03 failed with error -16
But there are no ACPI errors afterwards, just some ACPI-Interrupts:
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
...
ACPI: PCI Interrupt 0000:03:01.1[b] -> GSI 18 (level, low) -> IRQ 18
Offline
Hm, I get the same pre-suspend error, along with an additional one:
ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found. [...] rtc_cmos: probe of 00:03 failed with error -16
I just made some investigation. For the RTC cmos error, see: https://bugs.launchpad.net/ubuntu/+sour … bug/186297
It seems it is because of 2 RTC implementation are compiled... I building a new kernel to verify.
The DSDT error is not a real error. It just means that the initrmfs is looking for a dsdt and cannot find it and will use what the bios returns. If you bios is not (too much) broken, you can ignore this.
Offline
Ok, the RTC thing worked:
[ 22.376406] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[ 22.376480] rtc0: alarms up to one month, y3k
Suspend/resume still not corrected though.
Offline
What is the version of the kernel that is causing this problem? I'm using 2.6.23.14-1 and my M1330 have no suspend/resume problem at all, both CPUs still scale correctly. I haven't upgraded to 2.6.24 because sound stops working after an upgrade.
Offline
Hm, I'm using the recent Arch stock kernel, so it's 2.6.24. That's a very interesting point, because I remember scaling worked a few days after I installed Arch but soon stopped after a reinstall (and probably the kernel update). I'll try to install an 2.6.23 kernel somehow and see what happens
Slightly off-topic: Is there a way to use an older kernel module with a newer kernel?
Edit: I compiled a 2.6.23.14 Kernel and it doesn't work either Now there are some ACPI Errors (I don't know if I just didn't find them the last time):
ACPI Error (dswload-0664): [ DB] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node ffff810002f34e80), AE_NOT_FOUND
Last edited by jchtt (2008-03-08 17:12:16)
Offline
Ok, I'm feeling stupid now But some of the programmers out there might think about more meaningful error messages
Browsing the kernel options, I stumbled upon a very interesting one of which I just didn't think it could be unchecked:
[*] Enable loadable module support --->
[*] Module unloading
[ ] Forced module unloading
Somehow, one should not wonder that the quick and ugly workaround described in my first post didn't work. In order to force the unloading of a module, the corresponding option should be activated.
Long story short: Compile your own kernel with the option "Forced module unloading" activated and do a
rmmod -f acpi_cpufreq
on every suspend to ram. Then load it again on resuming and voilà, frequency scaling is working again!
Edit: I wonder if it was possible that this options is activated in the stock kernel by default... Are there any issues if it is enabled?
Last edited by jchtt (2008-03-09 15:54:25)
Offline
compiled it - works - thanks! you are my knight in shining armour!
mfg iggy
sorry for my bad english
Offline
Still no real solution to this?
2.6.25 didnt fix it...
Offline
but in 2.6.25-arch-package "force_unload_modules" is activated by default... so no need to recompile the kernel.
sorry for my bad english
Offline
Can this be used together with pm-suspend in some way?
SUSPEND_MODULES="acpi_cpufreq" dont work...
Edit:
I think this did the trick
/etc/pm/sleep.d/66dummy
#!/bin/bash
case $1 in
suspend)
rmmod -f acpi_cpufreq
;;
resume)
modprobe acpi_cpufreq
;;
*) echo "somebody is calling me totally wrong."
;;
esac
Last edited by JaQoB (2008-04-27 10:48:25)
Offline
I know this is kind of old, but wiki leads to this thread.
I've made a fresh Arch install couple days ago on my brand new m1330 and I don't have to reload acpi_cpufreq after suspending/hibernating - frequency scaling works without reloading it.
Last edited by rumil (2008-06-25 21:27:34)
Offline