/usr/sbin/on_ac_power incorrectly reporting ac power status
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
powermgmt-base (Debian) |
New
|
Unknown
|
||||
powermgmt-base (Ubuntu) | Status tracked in Oracular | |||||
Focal |
Confirmed
|
Undecided
|
Ghadi Rahme | |||
Jammy |
Confirmed
|
Undecided
|
Ghadi Rahme | |||
Kinetic |
Won't Fix
|
High
|
Unassigned | |||
Lunar |
Won't Fix
|
High
|
Unassigned | |||
Mantic |
Won't Fix
|
High
|
Ghadi Rahme | |||
Noble |
Confirmed
|
High
|
Ghadi Rahme | |||
Oracular |
Fix Released
|
High
|
Ghadi Rahme |
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/
This looks to be because of the ucsi-source-
This causes /usr/sbin/
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
Related branches
- Vladimir Petko (community): Approve
- Simon Chopin (community): Needs Fixing
- git-ubuntu import: Pending requested
-
Diff: 62 lines (+36/-1)2 files modifieddebian/changelog (+7/-0)
on_ac_power (+29/-1)
Changed in powermgmt-base (Ubuntu): | |
importance: | Undecided → High |
tags: | added: fr-2548 |
tags: | removed: rls-kk-incoming |
Changed in powermgmt-base (Ubuntu Kinetic): | |
status: | Confirmed → Triaged |
tags: | added: rls-mm-incoming |
tags: |
added: foundations-todo removed: rls-mm-incoming |
Changed in powermgmt-base (Ubuntu Oracular): | |
assignee: | nobody → Ghadi Rahme (ghadi-rahme) |
Changed in powermgmt-base (Ubuntu Noble): | |
assignee: | nobody → Ghadi Rahme (ghadi-rahme) |
Changed in powermgmt-base (Ubuntu Mantic): | |
assignee: | nobody → Ghadi Rahme (ghadi-rahme) |
Changed in powermgmt-base (Ubuntu Jammy): | |
assignee: | nobody → Ghadi Rahme (ghadi-rahme) |
Changed in powermgmt-base (Ubuntu Focal): | |
assignee: | nobody → Ghadi Rahme (ghadi-rahme) |
Changed in powermgmt-base (Ubuntu Noble): | |
importance: | Undecided → High |
Changed in powermgmt-base (Ubuntu Mantic): | |
importance: | Undecided → High |
Changed in powermgmt-base (Debian): | |
status: | Unknown → New |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.