[RESOLVED] AMD F39 USB-C hiccups with external display directly connected via USB-C

I see occasional errors ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110) in journalctl. This occurs at the same time my external monitor randomly disconnects and reconnects. As best I can tell, this is something related to the usb-c connection to the monitor. I am directly connected, connected to power (stock framework brick). This does not occur on another laptop running F39 using the same monitor via USB-C via the back-right usb-c expansion card. I have the 3.03 BIOS update and still see this. The monitor is an Arzopa A1C.

To be fair, the monitor is just using USB-C for power and display. I’m kind of leaning towards the display as I approached troubleshooting, however, I have a similarly spec’d machine that doesn’t have this problem.

Hi @Tim_Bosse

I want to make sure I have this right. This is USB-C direct to display from a USB-C expansion card, no hubs or docks or other adapters, correct?

That is correct.

Just caught this. So you are using the USB-C connection to push video and for powering the display, this is likely where things are experiencing challenges. Does the display have the option of separate power to connect to? Would be worth testing against this if this is available.

I’ll test it again with an external power source. The only reason it wasn’t a concern was the fact that I connect the display to antother laptop directly via USB-C only with no problems. It aslo runs a 60W PD charger.

1 Like

Hello @Matt_Hartley

I get the same message:

ucsi_handle_connector_change: ACK failed (-110)

This happens when I connect a yubikey 5C Nano with power plugged and unplugged.
The Yubikey is working as I’m able to use it to while logging on to different systems but the key is not detected by the yubikey-manager but I’m not 100% sure if this is the reason why.

My system is a Framework 13 AMD 7840U with Fedora 39

Please do. It’s difficult to drill down on this as I lack the same display, but if we see a difference here it will at least give us and idea that it’s power delivery related.

Welcome to the community, @adrian.alanis!

Appreciate this. Are you seeing this on other devices as well or just with this device?

Both of you, please:

  • Test this on all available expansion bay again. Note the results from each expansion bay.
  • Test this with both AC power connected and disconnected, looking for ucsi_handle_connector_change: ACK failed (-110)

If we have something that is duplicatable, something I can gather logs for and send up to engineering, we’d be in good shape for a path forward.

@Matt_Hartley thanks for the warm welcome :smile:

My fedora installation was initially done on the fedora 39 beta release with the bios that the laptop was shipped. Afterwards I did a couple of things:

  • upgraded the bios to 3.03 ( I believe this is the latest version)
  • upgraded the system to the recently official release of fedora 39 (via updates)

With this setup I was getting the previous message with the ucsi_handle_connector_change

After your previous message I decided to to a clean install with the official release of Fedora 39 because I wanted to also encrypt my drive, after doing a clean install I no longer see any message:

ucsi_handle_connector_change: ACK failed (-110)

I now see:

[  284.147373] i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration
[  327.524928] i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration
[  413.835122] i2c_hid_acpi i2c-FRMW0005:00: i2c_hid_get_input: incomplete report (7/65535)
[  582.940891] i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration

But I see there are other threads discussing this so, for now I think my participation in this thread is done :slight_smile:

Thanks for the support :metal:

1 Like

Okay, awesome. Yeah, that error (the latter) is a known thing and something we are actively investigating.

@Tim_Bosse following the above approach, have you also seen the issue resolve itself with a clean install of the official release, fully updated?

I haven’t had time yet. I daily drive for work. I’d be happy to give it a go, but I need to clear some time.

I actually have a bunch of todo’s on my list that I need to report to you for other issues. I’ll see if I can make some time this week to test/respond to them all.

Appreciate it.

Sounds good, please update their existing threads to keep everything in line with the topic (assuming they may be in other threads).

1 Like

I am getting these persistently irrespective of kernel; and sans external monitor - just with normal plug/unplug of Power and sometimes from suspend/hibernate

1 Like

I tested on a stock reinstall with latest updates as of today. I still see the a lot of the following whenever any USB device is connected. That includes the stock framework power supply.

[37656.330612] ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
[37764.113823] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5)
[37769.485559] ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110)
[37851.425274] i2c_hid_acpi i2c-FRMW0005:00: i2c_hid_get_input: incomplete report (7/65535)
[38160.446478] i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration

What makes this more confusing is it doesn’t address the problem with the display resetting on me. Those errors don’t correlate with the actual screen resetting…It started happening the second I opened 1password’s site and persisted until I turned the brightness on the display down below 100%.

I just don’t know what to make of it. I’m really not sure I want to pursue it for now. I’ve worked around the issue by setting the display to 85% brightness and all is stable. So most-likely bad display.

As for USB disconnect errors, I don’t see any adverse affects otherwise, everything else behaves, works as expected and is responsive despite the errors showing up occasionally.

As far as I am concerned, it’s been noted and I am satisfied with how everything behaves that I don’t consider it a “Framework support” issue anymore. I’ll leave it up to you and whoever else on the thread wants to drive this, as for me, I am not going to pursue this any further for now.

Thanks jwp. We have added this to our AMD tracker.

Appreciate that. We’re working with our partners to better drill down on this. We have active issues filed (with our partners) and this process continues on.

1 Like

Somewhere along the line I did some more testing. The external display hiccup has gone away. The original work-around was to keep the external monitor at 85% brightness. If I got to 100% brightness, instability was introduced. Now I am able to go to 100% brightness. There is no firmware for the monitor. The only thing is keeping F39 updated. There have been a number of firmware releases and kernel releases since I last visted. I am curious if anybody else is seeing improvement? @jwp?

As I don’t have access to a USB C display (using HDMI and DP via the expansion cards here), it would be worth filing a bug report with Fedora.

I personally consider this issue resolved. As for others, I would agree at this point, it may be worth looking down the Fedora community route…Actually, there has been no response, I see no reason not to consider this solved. Not sure if I should upate the title, or leave it to framework to update.

Marking as resolved. Thanks @Tim_Bosse

I’m getting this error with the built in display all the time. Any known way to fix it that way? I keep booting to the emergency terminal