Suggestion: don't read the battery status too often. Apparently it causes problems with some BIOSes.
The same can happen with temperature sensors. Conky for example has a hardcoded minimum interval for reading the /proc/acpi/* entries (for the battery it is around 30 seconds).
Interesting. I run these things at 10 second intervals, both battery and thermal info. When I get my laptop back, I will switch to 30 second intervals and see what happens.
]]>a) acpid: Is not needed. It allows the kernel to react to power events, which I'm not doing.
b) acpi: small app, about 500LOC. It just reads the values from /proc/acpi. It hangs as well.
This is a filesystem bug first and foremost. The /proc/acpi filesystem is an in kernel VFS. When you "read" a file, it calls something internally. It just so happens that this functionality blocks and never returns. I will investigate if I have time.
I did, however, notice a few things in dmesg, but my laptop is now in the shop.
@iphitus - cpuinfo is fine, No idea about /proc/acpi/info. I know for a fact battery and themal info take a crap.
Somewhere someone mentioned reading /proc/acpi/power_something/* instead of /proc/acpi/battery/*, but that's a work-around, not a fix.
Suggestion: don't read the battery status too often. Apparently it causes problems with some BIOSes.
The same can happen with temperature sensors. Conky for example has a hardcoded minimum interval for reading the /proc/acpi/* entries (for the battery it is around 30 seconds).
problem didnt occur before now, occurs now. fault in kernel, not bios, unless everyone has flashed buggy bios' in at the same time, or the kernel has been changed to be less tolerant in some form of these buggy bios.
another question to those with the problem, can you access /proc/acpi/info and /proc/cpuinfo ?
James
]]>The same can happen with temperature sensors. Conky for example has a hardcoded minimum interval for reading the /proc/acpi/* entries (for the battery it is around 30 seconds).
]]>(0)[wael@nasreddine ~]$ cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 6000 mAh
last full capacity: 3168 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 250 mAh
design capacity low: 150 mAh
capacity granularity 1: 10 mAh
capacity granularity 2: 25 mAh
model number: JM-6
serial number: 0138912637
battery type: LION
OEM info: Hewlett-Packard
(0)[wael@nasreddine ~]$ cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: discharging
present rate: 0 mA
remaining capacity: 3136 mAh
present voltage: 12471 mV
it never hanged... I have HP Pavilion dv1000 serires
]]>Any ideas on how to debug it? I'd love to do more investigative work on it, but I really don't know what to do about it.
See if the kernel burps, post a dmesg after it happens. Without that, its difficult to know.
I'll poke around on LKML and see if I can find anything. If it's a more spread problem it's bound to be reported already/soon.
edit: Does this happen after a suspend/resume cycle?
Does the process take 100% cpu?
What kernel? beyond, vanilla or both?
What mobo/chipset you guys using?
Gandalf, this is occurring when reading the values directly from proc. My instructions on ACPI were a workaround for phrak until we work out whats goin on.
]]>make sure acpid runs before hal in rc.conf.
then just use 'acpi' at the cli for details
iphitus@anna:~$ acpi
Battery 1: discharging, 70%, rate information unavailable.
has other parameters for other acpi proc values too.
as for why it's happening, I have no idea. I saw someone else with a procfs hang in another thread,so it may be a procfs thing rather than just acpi.
try doing it again, and if it does it again, hit dmesg and see if the kernel farts anything useful.
James
]]>Periodically, if I try
cat /proc/acpi/battery/BAT0/*
it will hang and just... never return.
I have no idea what causes this, but my case is not isolated. Any pointers/tips or even alternate ways to grab acpi information would be great.
]]>