Comment 21 for bug 254668

Somehow there is something related to the BAT0 device. The things that are clear:
BAT0 has a _STA (dynamic status) method which gets called when adding the object. This status method accesses one bit in the embedded controller which will (that is my assumption since the address space handler for the EC has been installed) call the space handler.

That would first enable burst mode, read from the embedded controller address and then disables the burst mode. Enabling the burst mode should generate the first GPE interrupt that turns on GPE mode.
Here is the first part I don't understand. Between the two messages the pause is supposed to be is one function call that does nothing. It would make a little bit more sense if the pause would be one message later.

Also, with or without GPE mode, whole code uses either msleep and compares jiffie values or uses wait_event_timeout which also should abort after some time. Which does not happen. That again would somehow make a bit of sense with your observation that the timestamps did not seem to be advanced after the pause. In that case maybe the first msleep while still in polling mode is stuck and things advance after pressing the power button or toggling AC because that causes an interruption which advances the timers again. I will try to prepare a kernel that looks ahead that road. Maybe in the meantime, what happens when playing with hpet=disable or highres=off?