NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/53019: xhci-connected keyboard with LOCKDEBUG kernel causes panic



>Number:         53019
>Category:       kern
>Synopsis:       xhci-connected keyboard with LOCKDEBUG kernel causes panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 12 23:45:00 +0000 2018
>Originator:     Paul Goyette
>Release:        NetBSD 8.99.12
>Organization:
+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 8.99.12 NetBSD 8.99.12 (SPEEDY 2018-02-12 00:00:12 UTC) #3: Mon Feb 12 06:57:12 UTC 2018 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
With a LOCKDEBUG kernel and a USB keyboard attached via a xhci USB-3 port,
typing a character at the DDB(4) prompt causes a kernel panic.

It appears that the xhci_device_intr_start() code is trying to obtain
a spin mutex while another spin mutex is already held (perhaps in the
xhci_poll() routine?).

Here's the console output from the LOCKDEBUG panic - all transcribed by
hand, but hopefully without too many typos!

Mutex error: mutex_vector_enter,523: spin lock held
lock address: 0xffffe410e9d1d9a0   type: spin
initialized:  0xffffffff802bac06
shared holds:                  0   exclusive:                  1
shares wanted:                 0   exclusive:                  0
current CPU:                  11   last held:                 11
curlwp:       0xffffe41fc09ad2c0   last held: 0xffffe41fc09ad2c0
last locked*: 0xffffffff802b81de   unlocked:  0xffffffff80291179
owner field:  0x0000000000010600   wait/spin:                0/1
panic: LOCKDEBUG: Mutex error: mutex_vector_enter,523: spin lock held

And the backtrace is

vpanic+0x140
snprintf
lockdebug_more
mutex_enter+0x69d
xhci_device_intr_start+0x125
usbd_start_next+0x65
xhci_soft_intr+0x49b
xhci_poll+0x37
ukbd_cngetc+0x19
cngetc+0x34
db_readline+0x65
db_read_line+0x15
db_command_loop+0x84
db_trap+0xe3
kbd_trap+0xe2
trap (number 4)

(This is then followed by the original backtrace which caused ddb(4)
to be entered in the first place.)
	
>How-To-Repeat:
See above.  Boot a LOCKDEBUG kernel, and enter ddb(4) (via some
pre-existing bug - have not tried to enter via cnmagic key-combo).

Type a character and watch it go boom.
	
>Fix:
	

>Unformatted:
 	
 	


Home | Main Index | Thread Index | Old Index