Bug 156171

Summary: Missing /sys/class/power_supply/AC/
Product: ACPI Reporter: Dario Zanotto (d.zanotto)
Component: Power-BatteryAssignee: Zhang Rui (rui.zhang)
Status: CLOSED DOCUMENTED    
Severity: normal CC: rui.zhang
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.4.0 Subsystem:
Regression: No Bisected commit-id:
Attachments: acpidump output when booted on AC
acpidump output when booted on battery
grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/*
grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/* when booted on AC
grep . /sys/bus/acpi/drivers/*/* when booted on AC
grep . /sys/bus/acpi/drivers/*/* when booted on battery
dmesg - boot on battery with initcall_debug

Description Dario Zanotto 2016-09-05 22:56:56 UTC
Dell XPS 15 (9550)
Ubuntu 16.04
Kernel 4.4.0-37-generic

Boot system WITHOUT the power adapter plugged in: the path /sys/class/power_supply/AC/ does not exist.

Boot system WITH the power adapter plugged in: the path /sys/class/power_supply/AC/ exists.

Any application that requires /sys/class/power_supply/AC/ to verify the AC status won't work in the first case.
Comment 1 Zhang Rui 2016-09-07 00:45:24 UTC
please attach the output of acpidump, both with and without AC plugged.
Comment 2 Dario Zanotto 2016-09-07 07:10:58 UTC
Created attachment 232381 [details]
acpidump output when booted on AC
Comment 3 Dario Zanotto 2016-09-07 07:11:22 UTC
Created attachment 232391 [details]
acpidump output when booted on battery
Comment 4 Zhang Rui 2016-09-07 07:52:42 UTC
weird, I don't see why AC sysfs I/F is missing.

please attach the ouput of "grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/*" when the ac sysfs is missing
Comment 5 Dario Zanotto 2016-09-07 08:59:58 UTC
Created attachment 232411 [details]
grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/*
Comment 6 Zhang Rui 2016-09-07 09:25:16 UTC
and also the same information when AC sysfs I/F is available.
Comment 7 Zhang Rui 2016-09-07 09:27:29 UTC
$ grep . /sys/bus/acpi/devices/ACPI0003\:00/*
grep: /sys/bus/acpi/devices/ACPI0003:00/driver: Is a directory
/sys/bus/acpi/devices/ACPI0003:00/hid:ACPI0003
/sys/bus/acpi/devices/ACPI0003:00/modalias:acpi:ACPI0003:
/sys/bus/acpi/devices/ACPI0003:00/path:\_SB_.PCI0.LPCB.EC0_.ADP1
grep: /sys/bus/acpi/devices/ACPI0003:00/physical_node: Is a directory
grep: /sys/bus/acpi/devices/ACPI0003:00/power: Is a directory
grep: /sys/bus/acpi/devices/ACPI0003:00/power_supply: Is a directory
/sys/bus/acpi/devices/ACPI0003:00/status:15
grep: /sys/bus/acpi/devices/ACPI0003:00/subsystem: Is a directory
/sys/bus/acpi/devices/ACPI0003:00/uevent:DRIVER=ac
/sys/bus/acpi/devices/ACPI0003:00/uevent:MODALIAS=acpi:ACPI0003:

This is what I got from my computer.
It seems that this line is missing
grep: /sys/bus/acpi/devices/ACPI0003:00/driver: Is a directory
which suggests that the AC driver is not loaded.

Can you please check if the driver is loaded? Can you please manually load it and check if the sysfs I/F is created?
Comment 8 Dario Zanotto 2016-09-07 09:42:23 UTC
Created attachment 232421 [details]
grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/* when booted on AC
Comment 9 Dario Zanotto 2016-09-07 09:46:05 UTC
If I understand correctly, you are talking about the loaded modules, but lsmod reports the same list in both conditions.
Comment 10 Zhang Rui 2016-09-07 09:51:32 UTC
then please attach the lsmod output in both cases
Comment 11 Zhang Rui 2016-09-07 09:52:15 UTC

(In reply to Dario Zanotto from comment #8)
> Created attachment 232421 [details]
> grep . /sys/bus/acpi/devices/ACPI0003\:00/* /sys/class/power_supply/*/* when
> booted on AC

we got an extra line here
grep: /sys/bus/acpi/devices/ACPI0003:00/driver: Is a directory

which means that the AC driver is loaded.
Comment 12 Zhang Rui 2016-09-07 09:54:12 UTC
please also attach the output of 
grep . /sys/bus/acpi/drivers/*/*
in both cases.

Maybe the AC driver is always loaded but fails to probe the AC device when booting on battery.
Comment 13 Dario Zanotto 2016-09-07 10:03:50 UTC
Created attachment 232461 [details]
grep . /sys/bus/acpi/drivers/*/* when booted on AC
Comment 14 Dario Zanotto 2016-09-07 10:04:12 UTC
Created attachment 232471 [details]
grep . /sys/bus/acpi/drivers/*/* when booted on battery
Comment 15 Zhang Rui 2016-09-07 12:41:12 UTC
(In reply to Dario Zanotto from comment #14)
> Created attachment 232471 [details]
> grep . /sys/bus/acpi/drivers/*/* when booted on battery

Hah, I can see that the AC driver is loaded, but it fails to bind the AC device, which looks weird to me...
I need to dig into the code for more information.
Comment 16 Zhang Rui 2016-09-07 12:43:14 UTC
please boot on battery with boot option initcall_debug
and attach the full dmesg output after boot.
Comment 17 Zhang Rui 2016-09-07 12:45:40 UTC
please make sure your kernel is built with CONFIG_ACPI_PROCFS_POWER cleared
Comment 18 Dario Zanotto 2016-09-07 12:55:52 UTC
Created attachment 232481 [details]
dmesg - boot on battery with initcall_debug
Comment 19 Dario Zanotto 2016-09-07 12:59:50 UTC
In /boot/ I've got a config-4.4.0-37-generic file that I assume is the configuration used by Canonical to build the correspondent kernel image.
It contains th following line:

# CONFIG_ACPI_PROCFS_POWER is not set

Does this answer your question?
Comment 20 Zhang Rui 2016-09-07 13:08:46 UTC
[    0.905704] ACPI Error: [\_SB_.PCI0.LPCB.H_EC.CHRG] Namespace lookup failure, AE_NOT_FOUND (20150930/psargs-359)
[    0.905709] ACPI Error: Method parse/execution failed [\PNOT] (Node ffff8804ad0de8e8), AE_NOT_FOUND (20150930/psparse-542)
[    0.905713] ACPI Error: Method parse/execution failed [\_SB.AC._PSR] (Node ffff8804ad0f16e0), AE_NOT_FOUND (20150930/psparse-542)
[    0.905719] ACPI Exception: AE_NOT_FOUND, Error reading AC Adapter state (20150930/ac-128)
[    0.905735] initcall acpi_ac_init+0x0/0x2b returned 0 after 3216 usecs

This seems to be a BIOS problem to me.

                Method (_PSR, 0, NotSerialized)  // _PSR: Power Source
                {
                    Local0 = ECG5 ()
                    Local0 &= One
                    If ((Local0 != PWRS))
                    {
                        PWRS = Local0
                        PNOT ()
                    }

                    Return (Local0)
                }

when on battery, _PSR runs a different code path because PWRS does not equal Local0, and only in this case, PNOT is invoked which triggers the BIOS bug, because it refers to an undefined ACPI object CHRG.
Comment 21 Zhang Rui 2016-09-07 13:10:41 UTC
so IMO, you should raise the problem to Dell instead to get the BIOS fixed.
The BIOS solution would be removing those two lines in DSDT table
dsdt.dsl:90:    External (_SB_.PCI0.LPCB.H_EC.CHRG, UnknownObj)
dsdt.dsl:17402:                Notify (\_SB.PCI0.LPCB.H_EC.CHRG, 0x80) // Status Change

Bug closed.