[Bug 1980991] Re: /usr/sbin/on_ac_power incorrectly reporting ac power status
Ghadi Rahme
1980991 at bugs.launchpad.net
Fri Sep 6 08:49:31 UTC 2024
Hello Robie,
Thank you for reviewing this!
I will update the test plan methodology to cover unattended upgrades
and/or any other application that makes use of the script.
1. > There are spurious development artifacts being added
I have looked through the debdiffs and couldn't find such, are you
referring to the "Maintainer" and "XSBC-Original-Maintainer" section
maybe?
2. > This does a glob expansion right here...
Yes this is intended behavior as USBC is not the only USB power type, it
is also the same value used before my changes.
3. > Wouldn't that incorrectly identify the system as being on AC
power?
Yes you are correct! however this bug also exists in systemd. Systemd
also checks if any of the ports are sink first before looking at all the
USB power sources. The reason this works is because a USB-C port that is
in source more should NOT show up as online under
/sys/class/power_supply/* because only ports in sink more are supposed
to show their online status here (ports in source mode will show up in
the directory but will have their "online" state as 0 even if a device
is plugged in to them). The reason I wrote this patch is because some of
these source ports are mirroring their connection state inside the
"online" sysfs. Discrete GPUs are the biggest culprits where those with
USB-C ports are having their connection status mirrored inside
"/sys/class/power_supply/ucsi-*/online" although they are labeled as a
source device. Here is an upstream issue from systemd discussing such a
case: https://github.com/systemd/systemd/issues/21988
Also here is proof from my system that systemd does indeed only require
one port in sink mode to make USBC a valid power delivery option (my
system has 4 thunderbolt ports that can all be used for charging):
ghadi at XPS-17-9720 ~ » cat /sys/class/typec/*/power_role
[source] sink
[source] sink
source [sink]
source [sink]
ghadi at XPS-17-9720 ~ » cat /sys/class/power_supply/ucsi-*/online
0
0
0
1
ghadi at XPS-17-9720 ~ » SYSTEMD_LOG_LEVEL=debug systemd-ac-power
BAT0: The battery status is 'Charging', assuming the battery is not used as a power source of this machine.
hidpp_battery_1: The power supply is a device battery, ignoring device.
AC: The power supply is currently online.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:001: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:001: The power supply is currently offline.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:002: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:002: The power supply is currently offline.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:003: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:003: The power supply is currently offline.
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
ucsi-source-psy-USBC000:004: The USB type-C device has at least one port in power sink mode.
ucsi-source-psy-USBC000:004: The power supply is currently online.
Found at least one online non-battery power supply, system is running on AC.
You can see how all the ucsi devices are being labeled as having at
least one power sink device:
"ucsi-source-psy-USBC000:00*: The USB type-C device has at least one
port in power sink mode."
Although I only have two ports in power sink mode. Systemd is also
clearly able to identify which ports are in source mode and which are in
sink mode:
```
port0: The USB type-C port is in power source mode.
port1: The USB type-C port is in power source mode.
port2: The USB type-C port is in power sink mode.
port3: The USB type-C port is in power sink mode.
```
The only difference between my script and how systemd checks for the ports that are in sink mode, is that I check this behavior by accessing "/sys/class/typec/*" once and apply this rule for all ucsi devices, while systemd accesses"/sys/class/power_supply/ucsi-source-psy-USBC000:00*/device/typec/*" for each ucsi device.
However from my testing on two machines I noticed that these two directories are the same (minus port partner ports being in /sys/class/typec/*) and so I took the shortcut of only checking the status once.
I can revert this change and have it behave exactly as systemd does, in
case there might be scenarios where the two directories are not the
same.
Let me know what you think of the above proposition.
** Bug watch added: github.com/systemd/systemd/issues #21988
https://github.com/systemd/systemd/issues/21988
--
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1980991
Title:
/usr/sbin/on_ac_power incorrectly reporting ac power status
Status in powermgmt-base package in Ubuntu:
Fix Released
Status in powermgmt-base source package in Focal:
Incomplete
Status in powermgmt-base source package in Jammy:
Incomplete
Status in powermgmt-base source package in Kinetic:
Won't Fix
Status in powermgmt-base source package in Lunar:
Won't Fix
Status in powermgmt-base source package in Mantic:
Won't Fix
Status in powermgmt-base source package in Noble:
Incomplete
Status in powermgmt-base source package in Oracular:
Fix Released
Status in powermgmt-base package in Debian:
New
Bug description:
Thank you @kevintate for the original bug report.
[Impact]
Currently there is an issue with the ac_on_power script where it thinks that USB-c ports with devices plugged in to them are plugged in to power. This is because the script does not check first if these usb-c ports are in sink or source mode first.
The solution is to check /sys/class/typec/* for the mode these usb ports are in, and ignore them if none of them are running in source mode.
[Test Plan]
On a device with a USB-c port (it does not matter if the port can be
used for powering the device or not) run the following test:
1. Install the patched version of on_ac_power
2. run: $ on_ac_power
3. check the return value: $ echo $?
compare the return value with the actual state of the machine. If the
machine is not plugged in to power, you should expect 0 as the return
code.
If the machine is plugged in then the return code should be 1.
If you receive 255 as an return code then the script was unable to
determine the power profile of the machine and is related to the
kernel not exposing enough information to user space. Consumers of
on_ac_power generally consider such a return code as the machine being
plugged in to power.
[Where problems could occur]
* the script could still incorrectly return the state of power of the
machine, specially if the kernel incorrectly advertises a usbc port to
be in a different mode then it is in.
[Original Description]
Good afternoon, folks.
I believe I discovered a bug in the /usr/sbin/on_ac_power script. I
have a Dell OptiPlex 5090 host that has an entry in
/sys/class/power_supply for "ucsi-source-psy-USBC000:001". I believe
this is the USB-C power delivery port on the front of the chassis. The
issue I'm encountering is that /usr/sbin/on_ac_power is exiting with
code 1 which states: (1 (false) if not on AC power) when that isn't
the case.
This looks to be because of the ucsi-source-psy-USBC000:001 entry
reporting the "online" status as 0, presumably because nothing is
currently connected to that USB-C port.
This causes /usr/sbin/on_ac_power to incorrectly report that the
machine isn't connected to AC power and causes other utilities like
unattended-upgrades to quit when using the default configuration since
it believes the machine isn't connected to AC power.
There is a workaround with unattended-upgrades where you can specify
it to run regardless of if AC power is connected, but as more and more
chassis implement power-delivery USB-C ports I foresee this becoming
more of an issue.
I'm not sure if it's anything to look into, but I figured I would
share my findings. Please let me know if you have any questions or if
I can provide any additional information, troubleshooting, or testing.
Thanks!
-Kevin
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/powermgmt-base/+bug/1980991/+subscriptions
More information about the Ubuntu-sponsors
mailing list