From: <tie...@gm...> - 2002-04-04 13:27:27
|
On 3 Apr, Diefenbaugh, Paul S wrote: >> Button events can be read with 'cat /proc/acpi/event'. This is=20 >> the first release, that fixes that problem. There are again two=20 >> entries in '/proc/acpi/button/power'. 'ls /proc/acpi/button/power'=20 >> gives only one entry named 'PWRB', while pressing the power-button=20 >> creates an event like 'button/power PWRF 00000080 00000001'. But=20 >> it works. >=20 > Hmmm ... looks like a bug. The name of the directory (PRWB) should > obviously match the name in the event file (PWRF). I'm sorry, but I've made a typing mistake in my posting: I mean, that there are two entries in '/proc/acpi/button'. Both are named 'power', so it's impossible to get the listing of the second. The one, that can be listed, has the entry 'PWRB'. Cause both buttons, 'PWRF' and 'PWRB' are recognized at boot time, this=20 behaviour seems to be a result of a new directory structure. >> No more sudden poweroffs when using cdparanoia. Sounds strange, but >> using my scsi-cdrom with data cd's works ok, while trying to rip any >> audio cd crashes the system or suddenly turns it off. >=20 > Does this also occur w/out ACPI? Definitely not. I tested this a few times with the ACPI-patched kernel and with a standard Kernel not patched and not with ACPI compiled in. >> processor C1 state is recognized but not used unlike in earlier >> releases, it stopped working since 20020208 or 20020214. >=20 > The kernel still uses C1 (the default idle handler versus > acpi_processor_idle). Note that we don't install our own handler (and = thus > don't track C1 usage) unless the platform supports C2 and/or C3. C2/C3 isn't supported with SMP-Systems? --=20 R=FCdiger -------------------------------------------------- pgp/gpg public-key available from keyservers or at http://home.htp-tel.de/ruedigerotte/key.html |