Update on this bug:
David Tombs reported it to the gnome-power-manager author [1]. It would be best to coordinate fixing of the bug at gnome's bugzilla site. Can someone check out what sounds like a similar bug in Red Hat? They have moved that bug to the kernel (fixed in stock kernel 2.6.32):
"kynde 2009-12-08 04:12:25 EST
This originates to kernel acpi drivers.
The button.c uses what it gets from acpi_device_bid for the
directory name aswell as for the Lid Switch [%s] printk.
The acpi_device_bid is, if I understood correcrly, filled with
what it gets from drivers/acpi/scan.c:
static void acpi_device_get_busid(struct acpi_device *device)
which in turn defaults to calling acpi_get_name from acpica/nsxfname.c.
Now, why that returns C1D0 rather than LID is beyond me.
And about missing events, I think it has to do with
acpi_lid_send_state
-> acpi_evaluate_integer
-> acpi_evaluate_object
and all the "magic" it does there with names
Someone with more knowledge of kernel acpi internals might want to take a look
at this. I'm willing try any patches or produce debugs etc.
I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access
to said laptop again (it's my wife's, you see) and check if that shows anything
relevant.
Comment 6 kynde 2009-12-09 17:09:55 EST
I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and
the problem persist, _but_ I compiled the stock 2.6.32 with the config from
said fedora kernel and low and behold, the lid acpi signaling works.
acpi_listen shows the lid events and system suspended when I configured it to
from power management.
This was about the HP mini 5101 and I have no idea what the situation is with
hp mini 2140 what this bug is about.
Hopefully those acpi changes make it to the fedora kernel soon. I glanced
briefly but didn't spot them in 2.6.31.y yet either."
Update on this bug:
David Tombs reported it to the gnome-power-manager author [1]. It would be best to coordinate fixing of the bug at gnome's bugzilla site. Can someone check out what sounds like a similar bug in Red Hat? They have moved that bug to the kernel (fixed in stock kernel 2.6.32):
"kynde 2009-12-08 04:12:25 EST
This originates to kernel acpi drivers.
The button.c uses what it gets from acpi_device_bid for the
directory name aswell as for the Lid Switch [%s] printk.
The acpi_device_bid is, if I understood correcrly, filled with acpi/scan. c: get_busid( struct acpi_device *device)
what it gets from drivers/
static void acpi_device_
which in turn defaults to calling acpi_get_name from acpica/nsxfname.c.
Now, why that returns C1D0 rather than LID is beyond me.
And about missing events, I think it has to do with integer object
acpi_lid_send_state
-> acpi_evaluate_
-> acpi_evaluate_
and all the "magic" it does there with names
Someone with more knowledge of kernel acpi internals might want to take a look
at this. I'm willing try any patches or produce debugs etc.
I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access
to said laptop again (it's my wife's, you see) and check if that shows anything
relevant.
Comment 6 kynde 2009-12-09 17:09:55 EST
I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and
the problem persist, _but_ I compiled the stock 2.6.32 with the config from
said fedora kernel and low and behold, the lid acpi signaling works.
acpi_listen shows the lid events and system suspended when I configured it to
from power management.
This was about the HP mini 5101 and I have no idea what the situation is with
hp mini 2140 what this bug is about.
Hopefully those acpi changes make it to the fedora kernel soon. I glanced
briefly but didn't spot them in 2.6.31.y yet either."
[1] https:/ /bugzilla. gnome.org/ show_bug. cgi?id= 607035 /bugzilla. redhat. com/show_ bug.cgi? id=512958
[2] https:/