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.
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.
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.
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.
Karol, is this bug still present in 2.6.20-rc7?
Please reopen this bug if it's still present with kernel 2.6.20.