Bug 682173

Hi Michael,

I used to bumped to this issue before.

Do you see any output from "acpi_listen" while plug/unplug AC adapter? If no it was due to problematic BIOS implementation indeed. If yes, check with the "lshal -m" again, it should log messages to reflect the change of AC adapter status as well.

Thanks.

Also have a try for :

 $ watch -n 1 cat /sys/firmware/acpi/interrupts/gpe??

At lease a counter should increase for AC plug/unplug. This indicates that BIOS delivered SCI event to notice OSPM about certain status changed.

Thanks.

(In reply to comment #1 and #2)
Neither "acpi_listen" nor "watch -n 1 cat /sys/firmware/acpi/interrupts/gpe??" shows any reaction to plugging/unplugging AC adapter or to changes of the battery charge level.

The commands "watch -n 1 /sys/class/power_supply/ADP0/online" or "watch -n 1 cat /proc/acpi/ac_adapter/ADP0/state" can only be used to catch plugging/unplugging.

(In reply to comment #3)
> (In reply to comment #1 and #2)
> Neither "acpi_listen" nor "watch -n 1 cat /sys/firmware/acpi/interrupts/gpe??"
> shows any reaction to plugging/unplugging AC adapter or to changes of the
> battery charge level.

I would conclude this as BIOS problem for now. HAL monitors on ACPI event, which never be triggered in this case, to refresh the state . In general, BIOS/EC accounts for generating such events. 

Some buggy BIOS implementation will emit scan code rather than ACPI event to notify OS. You can try to observe this in console by .

   $ showkey -s 

And see is there any scancode emitted when plug/unplug AC adapter. In this case You can try binding your script to this keycode to process the event . It may be helpful to avoid polling ...

IMHO HAL has nothing to do with this problem but a victim for it. The BIOS has to be fixed first to solve this problem.

> 
> The commands "watch -n 1 /sys/class/power_supply/ADP0/online" or "watch -n 1
> cat /proc/acpi/ac_adapter/ADP0/state" can only be used to catch
> plugging/unplugging.

I think your script is ideal to get around this problem by way of this fact. :)

Maybe something is wrong with acpid or with the kernel acpi support? Is it possible to check this?

(In reply to comment #5)
> Maybe something is wrong with acpid or with the kernel acpi support? Is it
> possible to check this?

If you didn't see acpi gpe, that means BIOS didn't trigger any interrupt to acpi when your unplug ac adapter.

Could you please attached dmesg:
   dmseg > dmesg.log

and DSDT?
  acpidump > acpidump.dat

Please attached dmesg.log and acpidump.dat on this bug.

Created attachment 426235 [details]
dmesg dump

Created attachment 426236 [details]
acpi dump

Hi Michael, 

Your dmesg have too many information by S4 resume, I need a dmesg after you:
 + reboot system

 + please run the following statement by root:
echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer; echo 0xF >/sys/module/acpi/parameters/debug_level 

 + manually plug, unplug ac-adapter

Please attached dmesg again.

On the other hand:
After traced your DSDT, EC must emit _Q13 or _Q19 event to OSPM when you unplug ac adapter, and those _Q method must notify ADP0 device.

Please help to follow the above 3 steps, then attached dmesg.

Thank's

Created attachment 435204 [details]
dmesg dump

Here is the dmesg dump after the steps you asked to perform.

Per your dmesg, EC didn't emit Q event on your machine, so OSPM didn't execute _Q13 or _Q19 for notify ADP0 device (AC adapter):

    Method (_Q13, 0, NotSerialized)     /* AC unplug? */
    {  
        Notify (ADP0, Zero)             /* ACPI_NOTIFY_BUS_CHECK 0x00 */
        Notify (BAT0, 0x80)
        Notify (BAT0, 0x81)             /* ACPI_BATTERY_NOTIFY_INFO 0x81 */
    }

    Method (_Q14, 0, NotSerialized)
    {  
        Notify (LID, 0x80)
    }

    Method (_Q19, 0, NotSerialized)     /* AC unplug? */
    {
        Notify (ADP0, Zero)             /* ACPI_NOTIFY_BUS_CHECK 0x00 */
        Notify (BAT0, 0x80)
        Notify (BAT0, 0x81)             /* ACPI_BATTERY_NOTIFY_INFO 0x81 */
    }

I have no idea why EC firmware didn't emit Q event.
Did you remember the ac-adapter unplug/plug event on your machine works on Windows or any other Linux platform?

Long time no response,so closed.Feel free to reopen it.Thanks.

(In reply to comment #11)
> Per your dmesg, EC didn't emit Q event on your machine, so OSPM didn't execute
> Did you remember the ac-adapter unplug/plug event on your machine works on
> Windows or any other Linux platform?
It seems to me that it worked on OpenSUSE 10.2 before some update of HAL.

(In reply to comment #13)
> (In reply to comment #11)
> > Per your dmesg, EC didn't emit Q event on your machine, so OSPM didn't execute
> > Did you remember the ac-adapter unplug/plug event on your machine works on
> > Windows or any other Linux platform?
> It seems to me that it worked on OpenSUSE 10.2 before some update of HAL.

That's strange, per your dmesg message, BIOS didn't emit notify event to OSPM, there will not have any event to drive userland update AC adapter status.

It must be have some polling mechanism to query the AC status like your script.

I know maybe it's not easy...
Does it possible you help to use openSUSE 10.2 to confirm? Follow the Comment #9, dump the dmesg log on openSUSE 10.2?

I will also try to check the HAL changed in RPM log.

Did not see openSUSE 10.2 and 10.3 HAL packages on OBS, where can I find them?

Long time no response,so closed.Feel free to reopen it.Thanks.