[Bug 221073] xHCI host controller dies on resume from s2idle on AMD Strix Halo [1022:1587]

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221073

--- Comment #19 from Alexander F (superveridical@gmail.com) ---
Created attachment 309514
  --> https://bugzilla.kernel.org/attachment.cgi?id=309514&action=edit
Z13 dmesg with xhci_hcd.quirks=0x40

The xhci_hcd.quirks=0x40 quirk resolves the 10 second resume issue, the devices
on this bus also don't disappear and work nominally. Not sure if there are side
effects to this quirk. Since I don't know what to look for without "HC died", I
uploaded a dmesg with the number of resume/suspends that usually triggers the
issue.

Regarding the brokenness of my device -- it's highly likely. I thought that it
was the improper interaction with / "fragility" of the hardware/firmware that
causes the issues described below. I assumed I should just quietly wait for the
next AGESA, but it seems that it could just as well be some kind of latent
hardware failure mode (a common type of failure, or some QC issue?). It's just
strange to my inexperienced self that it manifests itself so similarly for a
number of people on different devices in the same way. The debug data reports
from others are definitely required before making a decision on this, since my
sample might not be representative. (I think it would be even better if the
reporter from Framework sent the device on which it could be repeatedly
reproduced to AMD)

Here is circumstantial evidence for my device/soc being broken, over a month+
of semi-active use, the issues are seemingly adjacent to
sleep/restart/hibernate actions and IRQs (I apologize for the non-technical
nature, and if it's inappropriate, but since I'm the only who provided debug
data so far, and I'm not a hardware person, that's all I could do to provide
the context. I'm prepared to supply any data requested):

- No mass complaints about 10 second resumes on Linux here
https://www.reddit.com/r/FlowZ13/ and there is a good number of Linux users.
- I primarily used this device with linux.
- The first issues I encountered were audible latency issues on battery on
pre-installed windows -- LatencyMon showed 30000 to 50000 (i.e. several full
frames) interprocess stutters for me, during a 3 minute test, while simply
playing a video in a browser at about 8-10w soc power.  But since I wasn't the
only one
https://www.reddit.com/r/FlowZ13/comments/1jcgfn9/2025_395_audio_cracking/
(note the screenshots, these are not mine) I thought it was "normal".
Interestingly, clean installation of 23h2 windows cleared this issue
completely. Upgrade to 25h2 returned the increase in latencies on battery power
from about 150 to 400, but the horrific 10k+ stutters didn't return. If it's a
hardware issue it could be that it was "fixed" just be due to the less bloat on
a clean install. 
- On Linux I only observed smaller stutters using
https://testufo.com/animation-time-graph#scale=20&measure=interval , I'm yet to
do it properly using a lightweight compositor that is not mutter + mangohud +
vkcube.  Several times on Linux liveusbs I encountered "hrtimer interrupt took
2million+ nanoseconds" messages in dmesg, but not on the up to date kernel and
firmware on Gentoo though, so far.
- The device could simply die(as in you have to power it on as if it was off)
on suspend / restart action. This is rare, but it's at least 1/100 - 1/200
chance. Detaching power / USB devices could  be a factor, not sure. 
- Two times it died while in use. One of those was shortly after hibernation
resumption on linux. The other one was on windows, but I don't remember the
context, probably also after hibernation, since ASUS software forces it. I'm
afraid to explore repeatability of this, since it's a tablet, and powercycling
through battery disconnection requires special tools.
- Haven't observed any instability outside of power related actions -- I
compiled an entire Gentoo on it(-j16), played heavy games for hour+, left it on
idle for days. So far my understanding is that if it survives a minute after a
power action it will be rock solid until the next power action.
- The device could accrue "brokenness" that is preserved between "soft" resets.
This is also rare. For example one time it was systematically doing very long
boots due to getting stuck on a btusb device, and it was cleared only by hard
reset. In this state it was similarly stuck on power on at the bios stage (logo
appeared with a significant delay) 

Feb 13 22:36:46 gentoo kernel: usb 3-3: device descriptor read/64, error -110
Feb 13 22:37:02 gentoo kernel: usb 3-3: device descriptor read/64, error -110
Feb 13 22:37:02 gentoo kernel: usb 3-3: new high-speed USB device number 3
using xhci_hcd
Feb 13 22:37:07 gentoo kernel: usb 3-3: device descriptor read/64, error -110
Feb 13 22:37:23 gentoo kernel: usb 3-3: device descriptor read/64, error -110
Feb 13 22:37:23 gentoo kernel: usb usb3-port3: attempt power cycle
Feb 13 22:37:24 gentoo kernel: usb 3-3: new high-speed USB device number 4
using xhci_hcd
Feb 13 22:37:29 gentoo kernel: xhci_hcd 0000:c6:00.0: Timeout while waiting for
setup device command
Feb 13 22:37:34 gentoo kernel: xhci_hcd 0000:c6:00.0: Timeout while waiting for
setup device command
Feb 13 22:37:34 gentoo kernel: usb 3-3: device not accepting address 4, error
-62
Feb 13 22:37:35 gentoo kernel: usb 3-3: new high-speed USB device number 5
using xhci_hcd
Feb 13 22:37:40 gentoo kernel: xhci_hcd 0000:c6:00.0: Timeout while waiting for
setup device command
Feb 13 22:37:42 gentoo systemd-udevd[595]: usb3: Worker [673] processing
SEQNUM=2836 is taking a long time.
Feb 13 22:37:45 gentoo kernel: xhci_hcd 0000:c6:00.0: Timeout while waiting for
setup device command
Feb 13 22:37:45 gentoo kernel: usb 3-3: device not accepting address 5, error
-62
Feb 13 22:37:45 gentoo kernel: usb usb3-port3: unable to enumerate USB device

- The other time it had caught a bout of systematically dying on restart. Was
also cleared by a hard reset (holding power button for some N>10 seconds).

While there are similar reports in /r/FlowZ13, if such state of the device was
prevalent it would be more notable. There is also a possibility that the stuff
above is independent of this particular bug.

Miscellaneous (likely unrelated):
- There is a back RGB backlight window usb hid device (3-5) and I observed it
in the 3 states: Right after a hard reset it's turned off both on DC and
battery, as it should be per ArmoryCrate settings. Power off / power on cycle
turns it on for some reason, until the next hard reset. But in that turned on
state it could be responsive to systemd and echo commands (systemd turns it off
after a short flare up on resume), but could become unresponsive, and in that
case I have to do the following to turn it off.

echo "3-5" > /sys/bus/usb/drivers/usb/unbind; sleep 0.5; echo "3-5" >
/sys/bus/usb/drivers/usb/bind; sleep 0.5; echo 0 >
/sys/class/leds/asus\:\:kbd_backlight_1/brightness

I managed to reproduce it repeatedly by having it ON after a power on/off
cycle, and then resuming once on battery, and after that on every resume you
have to unbind/bind it. Other devices on this bus don't have resume issues. 

Other likely-real bugs I won't be filing/reporting/commenting on since my
device is likely broken(just putting it out here on the internet):
- cat /sys/kernel/debug/dri/0/amdgpu_pm_info and amdgpu_top report the wrong
soc power wattage while on battery -- when I disconnect DC, on idle, soc power
instantly jumps from 3-something w to 6w. upower --dump and powerstat show 1w+
lower settled actual battery discharge rate, which should be impossible.
- encountered https://gitlab.freedesktop.org/drm/amd/-/issues/5000 over HDMI to
LG 27GR93U-B at 4k 120hz, wasn't able to reproduce it a second time after
trying for an hour

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.