public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 220491] usb_storage connected SD card disconnects/reconnects on resume from suspend
Date: Tue, 09 Sep 2025 22:25:58 +0000	[thread overview]
Message-ID: <bug-220491-208809-tqtW83BEoO@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-220491-208809@https.bugzilla.kernel.org/>

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

--- Comment #54 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
I'm not sure if the kdb stall is helpful, or if it just adds one more moving
part to this whole issue, possibly even causing usb link issues.
The USB SD device, and xHCI controller are probably still running, expecting
cpu/device drivers to handle certain things in time.

Anyways, your dmesg does reveal another issue in recovering links in
ss.inactive error state. port_event() in hub.c ends up resetting just the port,
even if a usb device is present and the whole device should be reset. After a
successful reset port_event() calls  hub_port_connect_change(..., portstatus,
portchange) with old, stale, pre-reset portstatus value.   

Details:
Link goes to ss.Inactive error state "0x2c0", this is common on disconnect
before link goes to rx.detect. Driver gives it some time before reset:

[62691.183508] xhci_hcd 0000:00:14.0: Transfer error for slot 6 ep 3 on
endpoint
[62691.204674] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2c0, return
0x2c0
[62691.204720] usb usb3-port4: Wait for inactive link disconnect detect
[62691.228672] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2c0, return
0x2c0
[62691.228722] usb usb3-port4: Wait for inactive link disconnect detect
[62691.252648] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2c0, return
0x2c0
[62691.252692] usb usb3-port4: Wait for inactive link disconnect detect
[62691.276646] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2c0, return
0x2c0
[62691.276695] usb usb3-port4: Wait for inactive link disconnect detect
[62691.300652] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2c0, return
0x2c0
[62691.300697] usb usb3-port4: Wait for inactive link disconnect detect

Here we only reset the port when we should reset the whole device.
Looks like this is because USB3 portstatus doesn't show "connected" when link
is in ss.Inactive error, and the following check in hub.c port_event() is true:

else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
                                || udev->state == USB_STATE_NOTATTACHED) {


[62691.300704] usb usb3-port4: do warm reset, port only
[62691.316596] xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping usb3 port
polling
[62691.356676] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2d0, return
0x2d0
[62691.356722] usb usb3-port4: not warm reset yet, waiting 50ms
[62691.408710] xhci_hcd 0000:00:14.0: Port change event, 3-4, id 15, portsc:
0x2a1203
[62691.408729] xhci_hcd 0000:00:14.0: handle_port_status: starting usb3 port
polling.
[62691.412657] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x2a1203,
return 0x310203
[62691.412787] usb usb3-port4: Connection change during reset, retrying
[62691.412812] xhci_hcd 0000:00:14.0: clear port4 connect change, portsc:
0x281203
[62691.412832] hub 3-0:1.0: port_wait_reset: err = -11
[62691.412837] usb usb3-port4: not enabled, trying warm reset again...
[62691.616651] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x281203,
return 0x300203
[62691.616709] xhci_hcd 0000:00:14.0: clear port4 reset change, portsc: 0x81203
[62691.616732] xhci_hcd 0000:00:14.0: clear port4 warm(BH) reset change,
portsc: 0x1203
[62691.616752] xhci_hcd 0000:00:14.0: clear port4 link state change, portsc:
0x1203
[62691.616768] xhci_hcd 0000:00:14.0: Get port status 3-4 read: 0x1203, return
0x203

port is now properly reset and ready in enabled u0 "0x1203" state. hub driver
does however call  hub_port_connect_change() with stale portstatus value still
showing link in ss.Inactive "0x2c0":

[62691.672631] usb usb3-port4: status 02c0, change 0041, 5.0 Gb/s
[62741.591943] xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping usb3 port
polling
[62741.593180] usb 3-4: USB disconnect, device number 3

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

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

  parent reply	other threads:[~2025-09-09 22:25 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26  3:34 [Bug 220491] New: usb_storage connected SD card disconnects/reconnects on resume from suspend bugzilla-daemon
2025-08-26  3:38 ` [Bug 220491] " bugzilla-daemon
2025-08-26 10:41 ` bugzilla-daemon
2025-08-26 15:05 ` bugzilla-daemon
2025-08-26 16:18 ` bugzilla-daemon
2025-08-26 17:24 ` bugzilla-daemon
2025-08-27  1:55 ` bugzilla-daemon
2025-08-27  3:49 ` bugzilla-daemon
2025-08-27  8:28 ` bugzilla-daemon
2025-08-27 16:26 ` bugzilla-daemon
2025-08-27 16:34 ` bugzilla-daemon
2025-08-27 17:01 ` bugzilla-daemon
2025-08-28  2:47 ` bugzilla-daemon
2025-08-28 17:33 ` bugzilla-daemon
2025-08-28 18:11 ` bugzilla-daemon
2025-08-29 17:37 ` bugzilla-daemon
2025-08-29 18:31 ` bugzilla-daemon
2025-09-02 21:23 ` bugzilla-daemon
2025-09-02 21:24 ` bugzilla-daemon
2025-09-02 21:45 ` bugzilla-daemon
2025-09-03  2:26 ` bugzilla-daemon
2025-09-03  5:39 ` bugzilla-daemon
2025-09-03  6:12 ` bugzilla-daemon
2025-09-03 12:58 ` bugzilla-daemon
2025-09-03 14:09 ` bugzilla-daemon
2025-09-03 15:29 ` bugzilla-daemon
2025-09-03 16:36 ` bugzilla-daemon
2025-09-03 16:43 ` bugzilla-daemon
2025-09-03 17:12 ` bugzilla-daemon
2025-09-03 19:00 ` bugzilla-daemon
2025-09-03 21:04 ` bugzilla-daemon
2025-09-03 21:08 ` bugzilla-daemon
2025-09-03 21:13 ` bugzilla-daemon
2025-09-03 21:22 ` bugzilla-daemon
2025-09-04  0:59 ` bugzilla-daemon
2025-09-04  1:00 ` bugzilla-daemon
2025-09-04  1:29 ` bugzilla-daemon
2025-09-04  2:49 ` bugzilla-daemon
2025-09-04  5:11 ` bugzilla-daemon
2025-09-04  6:05 ` bugzilla-daemon
2025-09-04 15:17 ` bugzilla-daemon
2025-09-04 23:03 ` bugzilla-daemon
2025-09-05  1:35 ` bugzilla-daemon
2025-09-05 11:53 ` bugzilla-daemon
2025-09-05 18:30 ` bugzilla-daemon
2025-09-05 21:44 ` bugzilla-daemon
2025-09-08 13:39 ` bugzilla-daemon
2025-09-08 22:41 ` bugzilla-daemon
2025-09-08 23:01 ` bugzilla-daemon
2025-09-08 23:04 ` bugzilla-daemon
2025-09-09  4:38 ` bugzilla-daemon
2025-09-09 16:03 ` bugzilla-daemon
2025-09-09 21:05 ` bugzilla-daemon
2025-09-09 21:16 ` bugzilla-daemon
2025-09-09 22:25 ` bugzilla-daemon [this message]
2025-09-23  8:49 ` bugzilla-daemon
2025-09-29 22:19 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-220491-208809-tqtW83BEoO@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox