As my setup works better and better, I’m about to clean up my kernel errors.
Right now the following entries are written on boot:
cros-usbpd-charger cros-usbpd-charger.5.auto: No USB PD charging ports found
cros-usbpd-charger cros-usbpd-charger.5.auto: Unexpected number of charge port count
cros-usbpd-charger cros-usbpd-charger.5.auto: Failing probe (err:0xffffffb9)
cros-usbpd-charger: probe of cros-usbpd-charger.5.auto failed with error -71
This doesn’t limit or change my working in any way.
However, I’d love for it to be resolved.
This is from this code.
It seems to be a known issue.
- 12th gen 1240P cpu
- 32GB RAM
- Void Linux (rolling-release, uptodate)
Is this a firmware or linux kernel issue?
I have this since Ubuntu 22.10 (5.19) ~ 22.04 (5.15) was fine.
I wrote the above when using WIN 11 so I thought I’d reboot to Ubuntu as there were other notifications ~ and for the fist time ~ ever I had no notifications and it went straight to the desktop.
Even in 22.04 there were messages.
So now not even the one mentioned in this topic
You probably still have them on dmesg.
Can you take a look?
Neither; if it must be either, it’s a Linux issue only because the verbosity of the message is too low (which leads to it being displayed when you want it to not be displayed.)
The embedded controller is ChromeOS-compatible but does not implement its own USB C port management. The message is just informing you of that fact. It is harmless.
(2023-01-11T12:50:54,079214+00:00) cros-usbpd-charger cros-usbpd-charger.2.auto:
No USB PD charging ports found
(2023-01-11T12:50:54,080026+00:00) cros-usbpd-charger cros-usbpd-charger.2.auto:
Unexpected number of charge port count
(2023-01-11T12:50:54,080053+00:00) cros-usbpd-charger cros-usbpd-charger.2.auto:
Failing probe (err:0xffffffb9)
probe of cros-usbpd-charger.2.auto failed with error -71
But I was so happy that nothing came up on boot
I’m having the same issue and Ubuntu doesn’t show the “charging battery” indicator anymore on the toolbar:
OTOH the USB charger cable is connected and the light is orange, all cores are at 100% because I’m processing something heavy…
EDIT: Interesting, I think that when I set it to performance mode, the wall charger doesn’t have enough juice to charge the battery and have all CPUs on, therefore it discharges the battery if all CPUs are at 100%, unexpected and disappointing
The EC on my amdfw13 gets confused about AC present relatively frequently.
Most often if it’s plugged on boot (seldom if I boot on battery then plug).
I’ve had similar upower -d reports when unplugged/replugged around it thinking it’s either not plugged in (when it is) etc. The EC controls the battery charge limits but the PD is controlled indirectly by ACPI IIRC. So the above dmesg messages can be ignored safely.
The gnome applet is just polling upower via dbus - and I’ve had oddity with plasma doing the same - I wouldn’t worry about it.
I don’t have the same Mainboard/CPU as you - but the USB-PD supplied with the amdfw13 is a GAN USB PD and when running full blat with GPU and CPU pinned at 100% there is still plenty of headroom on the 7840U
Not quite your experience, so a similar data point, confirming that under heavy load, the battery will discharge.
11th Gen Batch 1 FW13, charged to 85% limit.
Connected to a 45W charger.
In Windows, started playing Flight Simulator, after about two hours, started getting messages to charge the battery. Fortunately the flight landed before the battery died, as I didn’t have a higher wattage charger handy.
Hey guys, just clarifying, are you seeing the same message as that of the OP?
I do when I am using a kernel with the cros_ec_lpc patch applied yes.
ah, you’ve pinpointed exactly one issue i’ve been having! If I have my amd fw13 plugged on boot, then unplug it,
/sys/class/power_supply/ucsi-source-psy-USBC000:004/online still reports being online, even though
/sys/class/power_supply/ACAD/online is not. This in turn confuses elogind (but probably also systemd), because it thinks the computer is on AC and will thus not go to sleep when I close the lid, as that’s what I’ve configured. After replugging it seems the proper behavior is restored.
I am on 6.7-rc7, with the v12 preferred cores and v2 cros_ec_lpc patches.
EDIT: FWIW, I also see the same message as OP.
That sysfs node is probably provided by the
ucsi_acpi module, which requires working UCSI. UCSI has proven somewhat problematic since 11th gen.
You can try adding that module to the disallow list.