Linux USB
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Jan Čermák" <sairon@sairon.cz>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Khazhy Kumykov <khazhy@google.com>,
	USB mailing list <linux-usb@vger.kernel.org>,
	regressions@lists.linux.dev
Subject: Re: [REGRESSION] Re: [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization
Date: Thu, 7 Mar 2024 14:34:17 -0500	[thread overview]
Message-ID: <60def275-5237-48df-b37b-ab886f4ee017@rowland.harvard.edu> (raw)
In-Reply-To: <00f0786b-a9f2-4f73-8d23-3b1fa4c8b77e@sairon.cz>

On Thu, Mar 07, 2024 at 05:17:20PM +0100, Jan Čermák wrote:
> Hi Alan,
> 
> On 06. 03. 24 22:08, Alan Stern wrote:
> > Can you provide two usbmon traces, one showing the problem with those
> > patches present and the other (on the same system but with the patches
> > reverted) showing the recovery?  Comparison of the two should indicate
> > what's happening differently.
> 
> I reproduced the issue on my old ThinkPad X220 with 6.6.20 kernel, you can
> find the usbmon captures below.

This is quite strange; the two traces are the same up to this point:

ffff9f9a29b3f300 298538675 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff9f9a29b3f300 298538893 C Co:1:002:0 0 0
ffff9f9a012cae40 298581342 C Ii:1:002:1 0:2048 1 = 04
ffff9f9a012cae40 298581372 S Ii:1:002:1 -115:2048 1 <
ffff9f9a29b3f300 298742112 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff9f9a29b3f300 298742459 C Ci:1:002:0 0 4 = 03011000

------------------------------------------------------------------

ffff8fc4ee367240 368298641 S Co:1:002:0 s 23 03 0004 0002 0000 0
ffff8fc4ee367240 368298823 C Co:1:002:0 0 0
ffff8fc4c0c5ac00 368343025 C Ii:1:002:1 0:2048 1 = 04
ffff8fc4c0c5ac00 368343056 S Ii:1:002:1 -115:2048 1 <
ffff8fc4ee367240 368502095 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
ffff8fc4ee367240 368502372 C Ci:1:002:0 0 4 = 01011100

The difference is in the last line: 03011000 vs. 01011100.  This means
that in the "working" scenario the device disconnected itself from
the USB bus for no apparent reason and then reconnected, whereas in
the "nonworking" scenario it didn't.  The computer did nothing
different before then, so I have no idea why the device's behavior
changed.  It's a mystery.

Another thing the traces showed is that the device doesn't like the
"new" initialization scheme; it wants the "old" one.  You can test
this by setting the old_scheme_first module parameter for usbcore
before plugging in the device:

	echo 1 >/sys/module/usbcore/parameters/old_scheme_first

Also, you can try the patch below (without the module parameter set).
I suspect it should be applied in any case, but it would be nice to
know if it makes any difference in your case.

Alan Stern



Index: usb-devel/drivers/usb/core/hub.c
===================================================================
--- usb-devel.orig/drivers/usb/core/hub.c
+++ usb-devel/drivers/usb/core/hub.c
@@ -5481,6 +5481,7 @@ loop:
 			msleep(2 * hub_power_on_good_delay(hub));
 			usb_hub_set_port_power(hdev, hub, port1, true);
 			msleep(hub_power_on_good_delay(hub));
+			hub_port_debounce_be_stable(hub, port1);
 		}
 	}
 	if (hub->hdev->parent ||

  reply	other threads:[~2024-03-07 19:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 19:09 [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization Alan Stern
2023-08-04 19:10 ` [PATCH 1/3] USB: core: Unite old scheme and new scheme descriptor reads Alan Stern
2023-08-04 19:12   ` [PATCH 2/3] USB: core: Change usb_get_device_descriptor() API Alan Stern
2023-08-04 19:14     ` [PATCH 3/3] USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Alan Stern
2023-12-11 10:40   ` [REGRESSION] Re: [PATCH 1/3] USB: core: Unite old scheme and new scheme descriptor reads Christian Eggers
2023-12-11 16:21     ` Alan Stern
2023-12-12  8:01       ` Christian Eggers
2023-08-08  8:47 ` [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization Greg KH
2023-08-10  0:28 ` Thinh Nguyen
2023-08-10  1:47   ` Alan Stern
2023-08-10 16:34     ` Alan Stern
2023-08-10 22:39       ` Thinh Nguyen
2023-08-11  1:52         ` Alan Stern
2023-08-11 17:05           ` Thinh Nguyen
2023-08-11 17:38             ` [PATCH] USB: core: Fix oversight in SuperSpeed initialization Alan Stern
2023-08-12  8:05               ` Greg KH
2023-08-12 15:28                 ` Alan Stern
2024-03-05  8:20 ` [REGRESSION] Re: [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization Jan Čermák
2024-03-06 21:08   ` Alan Stern
2024-03-07 16:17     ` Jan Čermák
2024-03-07 19:34       ` Alan Stern [this message]
2024-03-11  9:58         ` Jan Čermák
2024-03-11 14:43           ` Alan Stern
2024-03-12  8:57             ` Jan Čermák
2024-03-12 20:47               ` Alan Stern
2024-03-16 20:35               ` Alan Stern
2024-03-19 11:54                 ` Jan Čermák
2024-03-19 16:03                   ` Alan Stern
2024-03-27 13:24                     ` Jan Čermák
2024-03-27 14:21                       ` Alan Stern
2024-03-28 15:44                         ` Alexander Dahl
2024-03-28 16:16                           ` Alan Stern

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=60def275-5237-48df-b37b-ab886f4ee017@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=gregkh@linuxfoundation.org \
    --cc=khazhy@google.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=sairon@sairon.cz \
    /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