linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ladislav Michl <oss-lists@triops.cz>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: xHCI host dies on device unplug
Date: Tue, 20 Dec 2022 08:58:58 +0100	[thread overview]
Message-ID: <Y6FrQm5mYrwAnbFt@lenoch> (raw)
In-Reply-To: <Y6Dbh1xJucfNvwXq@lenoch>

On Mon, Dec 19, 2022 at 10:45:43PM +0100, Ladislav Michl wrote:
> On Mon, Dec 19, 2022 at 07:31:02PM +0100, Ladislav Michl wrote:
> > On Mon, Dec 19, 2022 at 02:25:46PM +0200, Mathias Nyman wrote:
> > > Looks like controller didn't complete the stop endpoint command.
> > > 
> > > Event for last completed command (before cycle bit change "c" -> "C") was:
> > >   0x00000000028f55a0: TRB 00000000035e81a0 status 'Success' len 0 slot 1 ep 0 type 'Command Completion Event' flags e:c,
> > > 
> > > This was for command at 35e81a0, which in the command ring was:
> > >   0x00000000035e81a0: Reset Endpoint Command: ctx 0000000000000000 slot 1 ep 3 flags T:c
> > > 
> > > The stop endpoint command was the next command queued, at 35e81b0:
> > >   0x00000000035e81b0: Stop Ring Command: slot 1 sp 0 ep 3 flags c
> > > 
> > > There were a lot of URBs queued for this device, and they are cancelled one by one after disconnect.
> > > 
> > > Was this the only device connected? If so does connecting another usb device to another root port help?
> > > Just to test if the host for some reason partially stops a while after last device disconnect?
> > 
> > Device is connected directly into SoC. Once connected into HUB, host doesn't die
> > (as noted in other email, sorry for not replying to my own message, so it got lost)
> > It seems as intentional (power management?) optimization. If another device is
> > plugged in before 5 sec timeout expires, host completes stop endpoint command.
> > 
> > Unfortunately I cannot find anything describing this behavior in
> > documentation, so I'll ask manufacturer support.
> 
> As support is usually slow I asked search engine first and this sounds
> familiar:
> "Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
> with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
> xhci host controller from dying when device is disconnected."
> 
> usb: dwc3: Add quirk for Synopsis device disconnection errata
> https://patchwork.kernel.org/project/linux-omap/patch/1424151697-2084-5-git-send-email-Sneeker.Yeh@tw.fujitsu.com/
> 
> Any clue what happened with that? I haven't found any meaningfull traces...

Just for completeness, this turned into:
41135de1e7fd ("usb: xhci: add quirk flag for broken PED bits")
and it is enabled:
cc params 0x0220f065 hci version 0x100 quirks 0x0000000002010010

However I do not see original logic there, clearing PORT_CSC before
stopping endpoint.

> > Both solutions, do nothing or reset controller once last device is unpluged
> > works, but I doubt they are suitable for mainline kernel without further
> > investigation.
> > 
> > > Another thing is that the stop endpoint command fails after three soft reset tries,
> > > does disabling soft reset help?
> > 
> > No, this does not cause any change.
> > 
> > 	ladis

  reply	other threads:[~2022-12-20  7:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 21:27 xHCI host dies on device unplug Ladislav Michl
2022-12-06 13:17 ` Ladislav Michl
2022-12-15 16:12   ` Ladislav Michl
2022-12-16 10:13     ` Mathias Nyman
2022-12-16 21:32       ` Ladislav Michl
2022-12-19 12:25         ` Mathias Nyman
2022-12-19 18:31           ` Ladislav Michl
2022-12-19 21:45             ` Ladislav Michl
2022-12-20  7:58               ` Ladislav Michl [this message]
2022-12-21  9:46                 ` Mathias Nyman
2022-12-21  7:14               ` Ladislav Michl
2022-12-21  9:58                 ` Mathias Nyman
2022-12-21 10:11                   ` Ladislav Michl
2022-12-21 12:05                     ` Ladislav Michl
2022-12-21 12:12                     ` Mathias Nyman
2022-12-21 12:21                       ` Ladislav Michl
2022-12-19  7:11       ` Ladislav Michl

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=Y6FrQm5mYrwAnbFt@lenoch \
    --to=oss-lists@triops.cz \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).