Comment 152 for bug 1283589
Revision history for this message
|
|
#152 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hello! I'm Juan Manuel Cabo
I just registered here to reply to the last post:
> A note on deleting the events:
> I unplugged/plugged the cable and opened/closed the lid while suspended.
> Even > though those events are now deleted instead of processed, the status
> icons in > gnome-shell and files in /proc/acpi/ were correct pretty much
> instantaneous.
The reason that they AC plugged in/unplugged status is reported correctly on resume, is that the OS calls the _WAK method of the DSDT on resume, which checks to see if there were any changes in LID/AC/Battery status and generates the corresponding events through Notify(). This is independant of the EC.
Also the EC events were discarded anyways on resume, since the GPE's are disabled during that critical stage of resuming.
Now let me try to summarize the bug here, which I already explained in
https:/
(posts #100 and #102).
The embedded controller accumulates events during sleep. If the events are too many (16 according to my "binary search" by hand), as in too many times plugging/unplugging the PSU, or battery change percentage decreasing or increasing 16 times, or LID open/close, a combination of them, during sleep, then the EC decides to not interrupt the OS with any more events (GPE 0x17) until they are queried.
This situation remains even after rebooting or shutting down, and there are only three ways to unstuck the EC:
1) Force Query the events (which my little C program does, attached in the launchpad issue). The OS will never query the events by itself because the EC's GPE 0x17 is never produced again.
2) Or remove the battery (these laptops don't have removable battery), which leaves us with hitting the reset button through the small hole in the back of the ultrabook.
3) Or flash any bios, which seems to reset the EC.
What my little program does is the following:
do {
status = inb(EC_
data = inb(EC_DATA_PORT);
} while (data != 0 && ++count < 10000);
The eventy type comes back in 'data'. When data==0, no more events are left in the EC. And the EC starts to produce them again, comming back to normal immediately.
("normal" meaning that the laptop starts to produce LID close events and AC and battery change events again).
So far, from the feedback in this and the other thread, the models which have the same problem, that can be fixed by this fix are:
Samsung Series 5 (models NP530U3C, NP535U3C, NP530U3B, NP550P5C)
Samsung Series 9 (models NP900X3F, NP900X4B, NP900X4C, NP900X4D, NP900X3C)
I personally have a series 5 NP530U3C. My DSDT is posted in the launchpad issue, in post #101.
My workaround fix is attached in post #103. It is a simple C program which reads the events from the EC until there are no more, so that the EC can start producing GPE 0x17 again.
https:/
--
Juan Manuel Cabo