Project

General

Profile

Bug #11049

XHCI runtime reset required in xhci

Added by Michal Nowak about 1 year ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2019-05-18
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

On OpenIndiana 2019.04 (illumos-87ca5dca67), when I executed sys-suspend on Lenovo X230, the system crashed:

System is being suspended
WARNING: Unable to suspend device pci17aa,21fa@14.
WARNING: Device is busy or does not support suspend/resume.
WARNING: xhci0: abort command timed out: resetting device

panic[cpu2]/thread=ffffff001e695c20:
XHCI runtime reset required

ffffff001e695b40 xhci:xhci_taskq+37d816aa ()
ffffff001e695c00 genunix:taskq_thread+2d0 ()
ffffff001e695c10 unix:thread_start+8 ()

dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
NOTICE: ahci1: ahci_tran_reset_dport port 0 reset port
stack pointer for thread ffffff001e695c20 (tq:xhci_taskq): ffffff001e695840
  ffffff001e695870 apix_setspl+0x17(fffffffffb888320)
  ffffff001e6958b0 0xffffff001e695c20()
  ffffff001e695c20 0x2e517893352()

Rest of the dump info attached.


Files

crash.2 (629 KB) crash.2 Michal Nowak, 2019-05-18 09:04 PM
prtconf-d.txt (4.01 KB) prtconf-d.txt Michal Nowak, 2019-05-19 07:30 AM
crash.3 (836 KB) crash.3 Michal Nowak, 2019-09-05 05:25 PM

Related issues

Related to illumos gate - Bug #10055: recursive mutex enter in ahciClosed2018-12-09

Actions

History

#1

Updated by Michal Nowak about 1 year ago

  • Related to Bug #10055: recursive mutex enter in ahci added
#2

Updated by Michal Nowak about 1 year ago

Attaching output of prtconf -d as requested by Randy.

#3

Updated by Michal Nowak 10 months ago

Got a similar kernel trace on panic after couple of plugg-in and -out of an USB hub with keyboad, unifying dongle for mouse, and (turned off) printer between two xHCI ports. Did not attempted to suspend the system this time.

#4

Updated by Alexander Pyhalov 7 months ago

Have similar report - system panics on 2019.10 live usb boot with the following stack

xhci:xhci_taskq+37abbd17()
genunix:takq_thread+2cd()
unix:thread_start+b()

After this keyboard becomes unresponsive (likely, USB keyboard/kmdb issue)

Also available in: Atom PDF