IMHO, an in-memory ftrace ring buffer in overwrite mode is definitely
the way to go here. Waiting 18 days between failures is basically
tracking a comet :), so keeping it in RAM won't fry your NVMe with weeks
of idle USB traffic.
Just hooking a ~16MB buffer to mt76:* and xhci-hcd:* with tracing_on
tripped on the first -110 vendor request via a quick dmesg watchdog
should give you the exact sub-millisecond death spiral.
As for the underlying failure: 7.0 (26.04) keeps hammering the dead chip every
~3s because resolute is missing Sean Wang's 7.3 hardening series (161596f033e8
and e137e5fd245c).
That series stops register polling on timeout and escalates directly to
wfsys_reset to bring the device back online without a system reboot.
Devin Wittmayer actually posted a follow-up to linux-wireless yesterday
("wifi: mt76: usb: keep the tx worker parked through a reset or
teardown") that keeps the tx worker parked across that reset path to
eliminate the kthread_park warning.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167595
Title:
mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc,
blocks rtnl_lock and shutdown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167595/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
