All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 213839] XHCI 7 port usb hub does not work correctly
Date: Sat, 01 Jan 2022 01:49:42 +0000	[thread overview]
Message-ID: <bug-213839-208809-ZAzRDmozII@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-213839-208809@https.bugzilla.kernel.org/>

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

--- Comment #10 from Alan Stern (stern@rowland.harvard.edu) ---
So far I have only looked at the Linux trace.  It shows two unusual things I
don't understand.

One is that some process (I don't know which) re-reads the hub's device and
configuration descriptors while the second device is being initialized, and
apparently as a result of this the process decides to reset the hub.  Why does
this happen?

The second is that when the descriptors are re-read, the hub's config
descriptor has changed!  The original bmAttributes value is 0xe0, as shown in
the lsusb output above.  But the bmAttributes value in the trace is 0xc0; the
changed bit is the flag for Wakeup support.  Most likely this is a bug in the
hub's firmware.

Perhaps additional debugging information will help.  You can enable dynamic
debugging and snooping for USB by doing:

  echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
  echo 1 >/sys/module/usbcore/parameters/usbfs_snoop

Clear the kernel log buffer by doing:

  dmesg -C

Then plug in the hub and and plug in a device to one of the non-working ports. 
Let's see what the dmesg log shows after that.

Another unusual thing shows up clearly in the trace: The autosuspend_delay_ms
time is set to a very low value; it looks like 20 ms.  You might get better
results leaving the delay set to its default value of 2 seconds.  Or turn USB
autosuspend off entirely by doing:

  echo -1 >/sys/module/usbcore/parameters/autosuspend

before plugging in the hub.

-- 
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:[~2022-01-01  1:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24 13:41 [Bug 213839] New: XHCI 7 port usb hub does not work correctly bugzilla-daemon
2021-07-24 14:30 ` [Bug 213839] " bugzilla-daemon
2021-07-24 14:45 ` bugzilla-daemon
2021-07-24 15:45 ` bugzilla-daemon
2021-09-15 22:46 ` bugzilla-daemon
2021-12-30 14:30 ` bugzilla-daemon
2021-12-31 16:32 ` bugzilla-daemon
2021-12-31 16:32 ` bugzilla-daemon
2021-12-31 16:35 ` bugzilla-daemon
2022-01-01  1:49 ` bugzilla-daemon [this message]
2022-01-01 10:36 ` bugzilla-daemon
2022-01-01 10:37 ` bugzilla-daemon
2022-01-01 10:38 ` bugzilla-daemon
2022-01-01 10:39 ` bugzilla-daemon
2022-01-01 16:26 ` bugzilla-daemon
2022-01-01 18:46 ` bugzilla-daemon
2022-01-01 18:51 ` bugzilla-daemon
2022-01-01 19:53 ` 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-213839-208809-ZAzRDmozII@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.