Bug 6131

Summary: serial_core oops (panic) in uart_write after device removal
Product: Drivers Reporter: Karol Kozimor (sziwan)
Component: OtherAssignee: drivers_other
Status: REJECTED INSUFFICIENT_DATA    
Severity: high CC: akpm, bunk, marcel
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16-rc4 Subsystem:
Regression: --- Bisected commit-id:

Description Karol Kozimor 2006-02-25 17:06:38 UTC
Device: 3Com Bluetooth PC Card (serial_cs, hci_uart) 
Steps to reproduce: 
1. Insert the card: 
ttyS1: detected caps 00000700 should be 00000100 [*] 
1.0: ttyS1 at I/O 0xa100 (irq = 4) is a 16C950/954 
1.0: ttyS2 at I/O 0xa108 (irq = 4) is a 8250 
 
2. Run hciattach: 
# hciattach /dev/ttyS1 csr 
 
3. Remove the card: 
pccard: card ejected from slot 1 
 
4. Run hciconfig 
# hciconfig -a 
hci0:   Type: UART 
        BD Address: xx:xx:xx:xx:xx:xx ACL MTU: 192:8 SCO MTU: 64:8 
[...] 
        Link mode: SLAVE ACCEPT 
hci_uart_send_frame: hci0: type 1 len 3 
hci_uart_tx_wakeup: 
Unable to handle kernel NULL pointer dereference at virtual address 00000004 
[...] 
EIP is at uart_write+0x23/0xa8 [serial_core] 
[...] 
Kernel panic - not syncing: Fatal exception in interrupt 
 
Full dump at http://hell.org.pl/~sziwan/serial_dump1.jpg [1,3 MB] 
Sorry for the quality, apparently it's not so easy to get a good flash shot on 
those screens and I don't have a serial console ready. 
 
This is fully reproducible, but I also had a different, regular oops in a 
similar situation (in uart_flush_buffer(), after cli) -- it seems the 
(&state->info->xmit)->head or tail references are bogus at that point. 
 
[*] This was the actual problem I tried to debug using the 
http://hell.org.pl/~sziwan/serial_16C950_flags.patch I found a while ago, but 
that's for another bug report.
Comment 1 Russell King 2006-02-26 01:17:57 UTC
hci_uart does not deal with the port being hung up, which is what happens when
you eject the card.

You need to report this to the bluetooth folk; they're not part of this bugzilla.
Comment 2 Karol Kozimor 2006-02-26 06:17:54 UTC
So I suspected, thanks for the clarification. The reason I'm reporting this 
here, however, is that the panic occurs in serial_core -- it might be 
legitimate to oops here, but I think a BUG_ON *before* the spinlock is taken 
and interrupts are masked would be much more user-friendly. 
Comment 3 Russell King 2006-02-26 10:32:22 UTC
I've made this suggestion on lkml.  It seems that Andrew Morton doesn't agree.

Anyway, I'll reassign this to Drivers/Other since we don't have a bluetooth
category - and this terminates my involvement with processing this bug.

Should folk require further advice on talking to serial_core, please don't
hesitate to contact me.

Thanks.
Comment 4 Andrew Morton 2007-01-31 00:37:46 UTC
Karol, is this bug still present in 2.6.20-rc7?
Comment 5 Adrian Bunk 2007-03-07 15:17:33 UTC
Please reopen this bug if it's still present with kernel 2.6.20.