linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonas Karlsson <jonas.karlsson@actia.se>
To: Peter Chen <peter.chen@nxp.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Oliver Neukum <oneukum@suse.com>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: RE: USB transaction errors causing RCU stalls and kernel panics
Date: Mon, 9 Mar 2020 14:21:56 +0000	[thread overview]
Message-ID: <699a49f2f69e494ea6558b99fad23cc4@actia.se> (raw)
In-Reply-To: <VI1PR04MB532785057FD52DFE3A21ACA88BE30@VI1PR04MB5327.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

> 
> If autosuspend is suspicious, Jonas, could you please try to disable autosuspend
> for all USB devices (including the roothub and controller) to see what happens?
> 
> Peter

I have run some tests with autosuspend turned off by doing this:
for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done;

To make our modem misbehave we need to cool it down in a temp chamber which I haven't had
access to the past days. However we have found two other ways to reproduce the event storm causing
event ring full messages spamming the logs. The pattern in the attached file repeats itself until I
unbind the driver.

1. If we power up the modem and wait until the modem is enumerated and then turn off the 
VUSB supply to modem which supplies the USB port on the modem we see a continuous flow 
of Unknown event type 37.

Or

2. If we power up the modem and wait until the modem is enumerated and then pull the reset
pin of the USB hub that sits between the modem and the SoC we also see a continuous flow of 
Unknown event type 37.

According to the USB hub datasheet this happens when the reset pin is pulled:
"The PHYs are disabled, and the differential pairs will be in a high-impedance state."

Having autosuspend enabled or disabled does not seem to make a difference in this case. 

BR,
Jonas

[-- Attachment #2: usb_transaction_errors.txt --]
[-- Type: text/plain, Size: 3863 bytes --]

[  674.915892] cdc_acm 1-1.1:1.5: acm_read_bulk_callback - nonzero urb status received: -71
[  674.915902]  xhci-cdns3: Ignoring reset ep completion code of 1
[  674.915912]  xhci-cdns3: Successful Set TR Deq Ptr cmd, deq = @960d4570
[  674.915968]  xhci-cdns3: Transfer error for slot 2 ep 10 on endpoint
[  674.915979]  xhci-cdns3: Cleaning up stalled endpoint ring
[  674.915983]  xhci-cdns3: Finding endpoint context
[  674.915988]  xhci-cdns3: Cycle state = 0x1
[  674.915993]  xhci-cdns3: New dequeue segment = 00000000641e49ab (virtual)
[  674.915998]  xhci-cdns3: New dequeue pointer = 0x960d4580 (DMA)
[  674.916002]  xhci-cdns3: Queueing new dequeue state
[  674.916009]  xhci-cdns3: Set TR Deq Ptr cmd, new deq seg = 00000000641e49ab (0x960d4000 dma), new deq ptr = 00000000dae0365c (0x960d4580 dma), new cycle = 1
[  674.916014]  xhci-cdns3: // Ding dong!
[  674.916020]  xhci-cdns3: Giveback URB 0000000007a5ed65, len = 0, expected = 1024, status = -71
[  674.916028] cdc_acm 1-1.1:1.5: acm_read_bulk_callback - nonzero urb status received: -71
[  674.916035]  xhci-cdns3: Ignoring reset ep completion code of 1
[  674.916044]  xhci-cdns3: Successful Set TR Deq Ptr cmd, deq = @960d4580
[  674.916064]  xhci-cdns3: Transfer error for slot 2 ep 10 on endpoint
[  674.916073]  xhci-cdns3: Cleaning up stalled endpoint ring
[  674.916077]  xhci-cdns3: Finding endpoint context
[  674.916081]  xhci-cdns3: Cycle state = 0x1
[  674.916086]  xhci-cdns3: New dequeue segment = 00000000641e49ab (virtual)
[  674.916091]  xhci-cdns3: New dequeue pointer = 0x960d4590 (DMA)
[  674.916094]  xhci-cdns3: Queueing new dequeue state
[  674.916102]  xhci-cdns3: Set TR Deq Ptr cmd, new deq seg = 00000000641e49ab (0x960d4000 dma), new deq ptr = 00000000d9f5f1c1 (0x960d4590 dma), new cycle = 1
[  674.916106]  xhci-cdns3: // Ding dong!
[  674.916113]  xhci-cdns3: Giveback URB 000000008a0a9417, len = 0, expected = 1024, status = -71
[  674.916119] cdc_acm 1-1.1:1.5: acm_read_bulk_callback - nonzero urb status received: -71
[  674.916126]  xhci-cdns3: Ignoring reset ep completion code of 1
[  674.916135]  xhci-cdns3: Successful Set TR Deq Ptr cmd, deq = @960d4590
[  674.916149]  xhci-cdns3: Transfer error for slot 2 ep 10 on endpoint
[  674.916157]  xhci-cdns3: Cleaning up stalled endpoint ring
[  674.916161]  xhci-cdns3: Finding endpoint context
[  674.916166]  xhci-cdns3: Cycle state = 0x1
[  674.916170]  xhci-cdns3: New dequeue segment = 00000000641e49ab (virtual)
[  674.916175]  xhci-cdns3: New dequeue pointer = 0x960d45a0 (DMA)
[  674.916178]  xhci-cdns3: Queueing new dequeue state
[  674.916186]  xhci-cdns3: Set TR Deq Ptr cmd, new deq seg = 00000000641e49ab (0x960d4000 dma), new deq ptr = 0000000094b88dce (0x960d45a0 dma), new cycle = 1
[  674.916190]  xhci-cdns3: // Ding dong!
[  674.916197]  xhci-cdns3: Giveback URB 000000003dad7325, len = 0, expected = 1024, status = -71
[  674.916204] cdc_acm 1-1.1:1.5: acm_read_bulk_callback - nonzero urb status received: -71
[  674.916211]  xhci-cdns3: Ignoring reset ep completion code of 1
[  674.916219]  xhci-cdns3: Successful Set TR Deq Ptr cmd, deq = @960d45a0
[  674.916251]  xhci-cdns3: Transfer error for slot 2 ep 10 on endpoint
[  674.916261]  xhci-cdns3: Cleaning up stalled endpoint ring
[  674.916265]  xhci-cdns3: Finding endpoint context
[  674.916270]  xhci-cdns3: Cycle state = 0x1
[  674.916274]  xhci-cdns3: New dequeue segment = 00000000641e49ab (virtual)
[  674.916279]  xhci-cdns3: New dequeue pointer = 0x960d45b0 (DMA)
[  674.916282]  xhci-cdns3: Queueing new dequeue state
[  674.916290]  xhci-cdns3: Set TR Deq Ptr cmd, new deq seg = 00000000641e49ab (0x960d4000 dma), new deq ptr = 0000000000ad0b83 (0x960d45b0 dma), new cycle = 1
[  674.916294]  xhci-cdns3: // Ding dong!
[  674.916301]  xhci-cdns3: Giveback URB 0000000077103065, len = 0, expected = 1024, status = -71

  reply	other threads:[~2020-03-09 14:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 15:05 USB transaction errors causing RCU stalls and kernel panics Jonas Karlsson
2020-03-03 16:39 ` Greg KH
2020-03-03 20:08   ` Jonas Karlsson
2020-03-04  6:37     ` Greg KH
2020-03-04 10:29     ` Oliver Neukum
2020-03-04 12:11     ` Mathias Nyman
2020-03-04 14:12       ` Oliver Neukum
2020-03-04 16:21         ` Mathias Nyman
2020-03-06  1:31           ` Peter Chen
2020-03-09 14:21             ` Jonas Karlsson [this message]
2020-03-10  8:14               ` Peter Chen
2020-03-10 10:04                 ` Jonas Karlsson
2020-03-10 11:04                   ` Oliver Neukum
2020-03-10 11:21                     ` Oliver Neukum
2020-03-10 12:26                       ` Jonas Karlsson
2020-03-10 16:04                         ` Jonas Karlsson
2020-03-10 16:11                           ` Fabio Estevam
2020-03-11  6:25                             ` Jonas Karlsson
2020-03-11 10:28                               ` Oliver Neukum
2020-03-11 14:59                                 ` Jonas Karlsson
2020-03-12 13:45                                   ` Oliver Neukum
2020-03-12 15:37                                     ` Jonas Karlsson
2020-03-13  9:27                                       ` Oliver Neukum
2020-03-16  7:07                                     ` Jonas Karlsson
2020-03-23 11:37                                       ` Jonas Karlsson

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=699a49f2f69e494ea6558b99fad23cc4@actia.se \
    --to=jonas.karlsson@actia.se \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=oneukum@suse.com \
    --cc=peter.chen@nxp.com \
    --cc=stern@rowland.harvard.edu \
    /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).