[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 #40 from Alexander F (superveridical@gmail.com) ---
>echo on > /sys/bus/pci/devices/0000:c4:00.4/power/control

no effect.

>The warning is unimportant,

Yeah, I understand. I (likely mistakenly) assumed that whatever sets taint on
the kernel also flips the NonFatalError. If "DevSta:" can only be set by the
hardware internally, than of course it's a different matter.  

>was PCI DevSta: NonFatalErr+ ever set with the 'Forced MSI only' patch after
>resume?

Never. I did 300 cycles with MSI-only patch with no issues and it was never set
to +. The only concerning things in dmesg during these 300 cycles were multiple
(about 9) errors of this kind:

amdgpu 0000:c4:00.0: amdgpu: Register(1) [regVPEC_QUEUE_RESET_REQ_6_1_1] failed
to reach value 0x00000000 != 0x00000001n
amdgpu 0000:c4:00.0: amdgpu: VPE queue reset failed

>i.e. Does MSI-X usage on xHC trigger the DevSta: NonFatalErr+, causing xHC
>interrupt handler to hot be called
>is there something else causing PCI DevSta: NonFatalErr+ in resume which for
>some reason only affects/omits MSI-X handler while MSI work and handler is
>called as it should.

Unfortunately, I'm not equipped to find that out. I can imagine it's possible
to write a kernel module(or modify an existing one) that tests that, but that's
beyond me. My understanding ends at the system call boundary.

>I think all we got is just more evidence that it's a PCI or x86 architecture
>problem, not USB. I would mail linux-pci

I can probably do that, but I'm not really confident that my device is
functioning properly hardware-wise, and I wouldn't be wasting everyone's time.
If I had access to another sample of the device, that was not self-selected, I
would  at least be able to tell that it reproduces on a randomly sampled device
beside mine. Unfortunately the bugreport starter with access to multiple
samples is MIA for some reason.

...

Meanwhile I think I determined the source of instability I had during the
sleep/restart actions. I had a working hypothesis that it's static zaps, and I
happened to pretty severely zap something in the device through a (rather thin)
keyboard key recently, severely enough to force my desktop's monitor, that only
has common connection with the Z13 through mains, to shutdown momentarily,
likely due to power protection circuitry in its PSU. (There is also no
grounding wire in this house) The device functioned nominally, but the moment I
tried to suspend it after that zap it died, and I had to longpress the power
button. It means I did at least 5-7 similar level zaps, and it could have of
course damaged something. All of this could mean nothing, but that makes me
less confident that I have a properly functioning device.

There are 4-7 people complaining of this issue on Linux, so it means at least
100 users with their devices in the similar state. Not everyone reports issues
of course -- absolutely real bugs get 1-2 reporters on drm/amd for example, so
the number could be greater. Could it be that this number of people also zapped
their devices, and did the same kind of latent damage to the whatever machinery
responsible for the MSI-X interrupt? Sounds kind of implausible. So if it
doesn't manifest on all devices the only other reason I can think of is
something to do with manufacturing.

I think we need more people supplying debug data to be sure before bothering
the other subsystems. But I would do as you recommend. And the issue looks like
something hardware/firmware related, i.e. beyond the level of the kernel.

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

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