I have an AMD Framework Laptop 13 running BIOS version 3.05. I am using an Arch based distro.
Relatively recently, I have been getting acpi errors during boot that I have never noticed before. When I run journalctl and filter for acpi, I can see the following:
I happen to have a saved text file from journalctl from a week prior when I was trying to resolve an unrelated issue. These lines were not present then, so this is definitely something new.
The USB ports seem to be working fine as far as I have been able to tell otherwise.
Does anyone know what these errors are and how they can be resolved?
I am not sure if it’s expected that a USB-C to USB-A adapter will trigger the message, but I wouldn’t be surprised if it was: the adapter is not the same as a data cable…
Yes, you are right, I am getting them too. Specifically, the error 256 one. I am also seeing a “spurious native interrupt” as the cable is connected:
I’m seeing the same messages on my FW16, BIOS 3.03 (I think they may have started after the BIOS update), also running Arch. 2 USB-C cards in the back, 2 USB-A in the middle and MicroSD and audio cards in the front.
The messages normally occur three times:
Jun 02 10:29:40.283204 lotusdroid kernel: ucsi_acpi USBC000:00: unknown error 0
Jun 02 10:29:40.283459 lotusdroid kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
Jun 02 10:29:40.617206 lotusdroid kernel: ucsi_acpi USBC000:00: unknown error 256
Jun 02 10:29:40.617415 lotusdroid kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
Jun 02 10:29:40.842178 lotusdroid kernel: mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0
Jun 02 10:29:40.926180 lotusdroid kernel: ucsi_acpi USBC000:00: unknown error 256
Jun 02 10:29:40.926456 lotusdroid kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
When all non-USB-C expansion cards are removed, with a charger plugged in during boot, it only happens once:
Jun 02 17:54:32.852988 lotusdroid kernel: ucsi_acpi USBC000:00: unknown error 256
Jun 02 17:54:32.853169 lotusdroid kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
This also happens whenever I plug in the charger, regardless of whether the other expansion cards are inserted.
I’m also getting this issue on my brand new FW16 running standard Arch. I updated to the newest BIOS and some other error messages went away but I’m still getting these. It also pops up again if I unplug/replug the power cable (in port 1). All in all the laptop seems to be functioning OK but it would be nice to figure out how to fix these errors.
I can add more context here for my situation. I was running a brand new minimal arch installation with linux kernal 6.9.3 and bios 0.3.2 and was definitely getting this error and this is still occurring for me on the same kernal version on bios 0.3.3. I’m poking around and doing my own research and will post back here if I find anything.
I was in batch 17 so I only just got it a few days ago and it’s been coming up with this message out of the box. I’m running OpenSUSE Tumbleweed on kernel 6.9.3 and bios 3.03. I tried reflashing the bios before I realised it was already on the latest and unsurprisingly it didn’t change anything. At first I wasn’t too worried about it, but I just had something really worrying happen:
[48614.361055] [T16283] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[52218.691674] [T16886] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[54833.024165] [T17820] ucsi_acpi USBC000:00: unknown error 256
[54833.024211] [T17820] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[55826.270440] [ T5659] BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
[56970.279447] [ T7969] ucsi_acpi USBC000:00: unknown error 256
[56970.279454] [ T7969] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
[56983.365308] [ T260] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
[56983.365322] [ T260] nvme nvme0: Does your device have a faulty power saving mode enabled?
[56983.365326] [ T260] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
[56983.465295] [ T7969] nvme 0000:06:00.0: enabling device (0000 -> 0002)
[56983.465639] [ T7969] nvme nvme0: Disabling device after reset failure: -19
[56983.502005] [ T8812] BTRFS error (device dm-0): bdev /dev/mapper/system-root errs: wr 0, rd 0, flush 1, corrupt 0, gen 0
[56983.502037] [ T8812] BTRFS warning (device dm-0): chunk 13631488 missing 1 devices, max tolerance is 0 for writable mount
[56983.502042] [ T8812] BTRFS: error (device dm-0) in write_all_supers:4056: errno=-5 IO failure (errors while submitting device barriers.)
[56983.502051] [ T8812] BTRFS info (device dm-0 state E): forced readonly
[56983.502057] [ T8812] BTRFS error (device dm-0 state EA): Transaction aborted (error -5)
[56983.502077] [ T8812] BTRFS: error (device dm-0 state EA) in btrfs_sync_log:3164: errno=-5 IO failure
[56983.502542] [ T811] BTRFS warning (device dm-0 state EA): Skipping commit of aborted transaction.
[56983.502549] [ T811] BTRFS: error (device dm-0 state EA) in cleanup_transaction:2005: errno=-5 IO failure
Correlation isn’t causation and all that, but that’s a little too close for comfort. I’m wondering if this is actually causing real hardware issues.
Can’t say for sure, but I really doubt it. The ucsi_acpi messages seem to have been added in Linux 6.9 as a part of USB-C capabilities detection and surfacing through sysfs. Prior to that, if I understand it correctly, the related data points were not exposed through sysfs at all. I don’t see any way how failure to detect those capabilities would be related to either nvme, or the filesystem.
In any case, it appears that the USB-C cable capability detection added in 6.9 doesn’t work at all on FW AMD. Would be interesting to know the reason.
Yeah, that’s fair. I doubt it’s doing any harm to the hardware too, and I was a little imprecise. I meant to include things like driver issues in when I said “hardware issues”
To me the messages are issues with the EC or PD controller. It’s more likely PD controller, because I believe EC just passes the messages from OSPM back and forth in this case.
I also have this message @Fedora40.
In addition to that, I observed the following problem:
USB-C Card in slot 1 has no display output. I attached a USB-docking (Anker) and this works except the video output. Then I tested around and it is not possible to get video out of this port, even with direct USB-C to HDMI cables… The USB-C card in port 3 works fine with dock and cable. Any suggestions?
FWIW, I have the same error on the latest Linux kernel AND with that kernel, I can’t get both of my external monitors to work at the same time, only one. They somehow get detected but no display signal is sent to 2nd one. Both monitors are connected via a Lenovo Thunderbolt 3 Dock.
Downgrading to the 6.6 LTS kernel fixes that issue.