Bluetooth USB crashses
I'm playing with a Bluetooth USB dongle (D-LINK DBT 120) and it works quite
well, but when I unplug the dongle the system freeezes immediately. I've
tried to unplug other USB devices as scanner or printer but without crashes.
System: PIV 2.8 Abit IC7-G MB;
2.6.0-test9 #3 SMP
Relevant Modules:
bnep
l2cap
bluetooth
uhci_hcd
ehci_hcd
hci_usb
rfcomm
I'm not using devfs but udev/sysfs.
I get no informations/messages in logs.
I'm using the same dogle and usb devices on a 2.4.21 kernel (on a different
HW) and I can remove the dongle without any problem.
If more informations or tries are needed just let me know.
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
Hi Fabio,
> Bluetooth USB crashses
>
> I'm playing with a Bluetooth USB dongle (D-LINK DBT 120) and it works quite
> well, but when I unplug the dongle the system freeezes immediately. I've
> tried to unplug other USB devices as scanner or printer but without crashes.
>
> System: PIV 2.8 Abit IC7-G MB;
> 2.6.0-test9 #3 SMP
> Relevant Modules:
> bnep
> l2cap
> bluetooth
> uhci_hcd
> ehci_hcd
> hci_usb
> rfcomm
>
> I'm not using devfs but udev/sysfs.
>
> I get no informations/messages in logs.
> I'm using the same dogle and usb devices on a 2.4.21 kernel (on a different
> HW) and I can remove the dongle without any problem.
>
> If more informations or tries are needed just let me know.
please try this with a non SMP kernel and/or a non preempt kernel. Do
you have enabled the Bluetooth SCO support for the HCI USB driver?
Regards
Marcel
Alle 12:31, mercoled? 05 novembre 2003, Marcel Holtmann ha scritto:
> > I get no informations/messages in logs.
> > I'm using the same dogle and usb devices on a 2.4.21 kernel (on a
> > different HW) and I can remove the dongle without any problem.
> >
> > If more informations or tries are needed just let me know.
>
> please try this with a non SMP kernel and/or a non preempt kernel. Do
> you have enabled the Bluetooth SCO support for the HCI USB driver?
I've tried with UP kernel (test9 straight, no bk-wathever), preempt, and it
freezes in the very same way. Tomorrow I'll try with UP and SMP no preempt.
the SCO module was compiled but not loaded.
I've noticed several Oopses during system shutdown, but I can't say if this is
related to the bluetooth issue. Tomorrow I'll try again and I'll post also
the oopses.
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
Alle 12:31, mercoled? 05 novembre 2003, Marcel Holtmann ha scritto:
>
> please try this with a non SMP kernel and/or a non preempt kernel. Do
> you have enabled the Bluetooth SCO support for the HCI USB driver?
As said I've tried 2.6.0-test9 [UP, SMP] preemp and SMP non preempt, all with
the same behaviour, that means immediate machine freeze whenever the usb
bluetooth dongle is removed from USB port.
I've also got crashes whenever I've turned off the machine, with bluetooth and
hci_usb modules loaded.
I've wrote down the message (by hand, so errors are possible) , hoping that
this can help. If it's possible to get the full message, please let me know,
a part of it has scrolled out of the screen (i can use a serial port
terminal, if needed).
here is the trace:
uhci_irq+0x67/0x16c [uhci_hcd]
do_IRQ+0xC1/0x141
usb_hcd_irq+0x36/0x5f
handle_IRQ_event+0x3a/0x64
do_IRQ+0x95/0x141
common_interrupt+0x18/0x20
poll_freewait+0x2/0x40
sys_poll+0x252/0x288
--pollwait+0x0/0xc7
syscall_call+0x7/0xb
Code: 89 79 34 89 47 04 89 02 89 50 04 C6 85 14 02 00 00 01 53 9d
<0> Kernel panic: Fatal exception in interrupt
Interrupt handler - not syncing
Hope this help,
Regards
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
Em Thu, Nov 06, 2003 at 10:40:38PM +0100, Fabio Coatti escreveu:
> Alle 12:31, mercoled? 05 novembre 2003, Marcel Holtmann ha scritto:
>
> >
> > please try this with a non SMP kernel and/or a non preempt kernel. Do
> > you have enabled the Bluetooth SCO support for the HCI USB driver?
>
> As said I've tried 2.6.0-test9 [UP, SMP] preemp and SMP non preempt, all with
> the same behaviour, that means immediate machine freeze whenever the usb
> bluetooth dongle is removed from USB port.
> I've also got crashes whenever I've turned off the machine, with bluetooth and
> hci_usb modules loaded.
> I've wrote down the message (by hand, so errors are possible) , hoping that
> this can help. If it's possible to get the full message, please let me know,
> a part of it has scrolled out of the screen (i can use a serial port
> terminal, if needed).
That would be good indeed.
> here is the trace:
What about the last routine that caused the oops? I.e. the one that appears
above the registers?
> uhci_irq+0x67/0x16c [uhci_hcd]
> do_IRQ+0xC1/0x141
> usb_hcd_irq+0x36/0x5f
> handle_IRQ_event+0x3a/0x64
- Arnaldo
Alle 00:15, venerd? 07 novembre 2003, Arnaldo Carvalho de Melo ha scritto:
> > I've wrote down the message (by hand, so errors are possible) , hoping
> > that this can help. If it's possible to get the full message, please let
> > me know, a part of it has scrolled out of the screen (i can use a serial
> > port terminal, if needed).
>
> That would be good indeed.
I've captured the kernel messages via serial console; I get them whenever I
unplug USB bluetooth dongle. The system is a:
2.6.0-test9 #9 SMP, P4 HT
Unable to handle kernel paging request at virtual address 80000234
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<f897c3ed>] Tainted: P
EFLAGS: 00010046
EIP is at uhci_remove_pending_qhs+0x95/0xfa [uhci_hcd]
eax: 80000234 ebx: 00000093 ecx: 80000200 edx: f488a4fc
esi: f7c25e0c edi: c03fe000 ebp: f7c25e18 esp: c03fff00
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c03fe000 task=c03818e0)
Stack: 00000286 f7c25e0c f7c25c00 00000000 f7c25c00 0000c000 c03fff9c f897c4b9
f7c25c00 c03818e0 c18d2c80 f7c25c00 00000001 00000000 c03fff9c c02b87b2
f7c25c00 c03fff9c f7c55620 04000001 c010b627 00000013 f7c25c00 c03fff9c
Call Trace:
[<f897c4b9>] uhci_irq+0x67/0x1ca [uhci_hcd]
[<c02b87b2>] usb_hcd_irq+0x36/0x5f
[<c010b627>] handle_IRQ_event+0x3a/0x64
[<c010b9e8>] do_IRQ+0xb8/0x196
[<c0105000>] rest_init+0x0/0x64
[<c0109d30>] common_interrupt+0x18/0x20
[<c0106ebe>] default_idle+0x0/0x2c
[<c0105000>] rest_init+0x0/0x64
[<c0106ee7>] default_idle+0x29/0x2c
[<c0106f4b>] cpu_idle+0x2e/0x3c
[<c040088e>] start_kernel+0x179/0x197
[<c0400449>] unknown_bootoption+0x0/0x10d
Code: 89 69 34 89 45 04 89 02 89 50 04 8b 54 24 08 c6 82 14 02 00
<0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing
I've got a kernel oops at shutdown also, here is the trace of one of them, the
process is often different, anyway..:
Unable to handle kernel paging request at virtual address 2cc44002
printing eip:
c018e380
*pde = 00000000
Oops: 0000 [#1]
CPU: 1
EIP: 0060:[<c018e380>] Tainted: P
EFLAGS: 00010246
EIP is at proc_match+0x10/0x42
eax: 00000000 ebx: f7511ab0 ecx: 0000000c edx: 2cc44000
esi: 0000000c edi: 2cc44000 ebp: f5154000 esp: f5155e94
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 28665, threadinfo=f5154000 task=ec227310)
Stack: 0000000c 2cc44000 c018f249 0000000c f7df40b0 2cc44000 f7df4000 f7df40b0
0000000c f6ef4c00 f7df4000 f897ca5d f7df40b0 f7511a80 f6c6c000 36c6c000
f6ef4c00 f7df4054 c02b519f f6ef4c00 f897d5cc f7df40b0 00000001 00000000
Call Trace:
[<c018f249>] remove_proc_entry+0x55/0x144
[<f897ca5d>] release_uhci+0xdf/0x121 [uhci_hcd]
[<c02b519f>] usb_hcd_pci_remove+0xbc/0x1a0
[<c0213851>] pci_device_remove+0x35/0x37
[<c0257117>] device_release_driver+0x64/0x66
[<c0257139>] driver_detach+0x20/0x2e
[<c0257371>] bus_remove_driver+0x3e/0x77
[<c0257711>] driver_unregister+0x10/0x24
[<c0213a05>] pci_unregister_driver+0x13/0x20
[<f897d4d6>] uhci_hcd_cleanup+0xf/0x76 [uhci_hcd]
[<c0137d76>] sys_delete_module+0x13a/0x15d
[<c014e000>] do_munmap+0xa8/0x1ed
[<c014e18a>] sys_munmap+0x45/0x66
[<c01093c3>] syscall_call+0x7/0xb
Code: 0f b7 4a 02 3b 4c 24 0c 74 0b 8b 34 24 8b 7c 24 04 83 c4 08
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
I've made some other test for USB bluetooth issue, with 2.6.0-test9-bk29
(processor: PIV 2.4 ht - SMP kernel preempt, but UP and not preempt seems to
do no difference at all).
All tests made with usb_hci and bluetooth modules loaded.
I've verified that removing USB bluetooth dongle I get the Oops (shown below).
Then, I've made up some tests:
I've tried to plug in and remove usb dongle without hcid and sdpd loaded and
all goes fine, without lockups.
If I remove the dongle after boot and after firing up hcid and sdpd, the crash
is granted. (dongle inserted before powering on the machine)
Finally, I've tried this: no dongle plugged, booted the machine, fired up hcid
and sdpd, inserted the dongle, (seen by the system), removed it (also seen by
the system, no harm), inserted again, removed - BOOM.
When the dongle is inserted, I can see this on syslog:
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb f75dd814 err -90
..or this:
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb f71f7c14 err -22
Hope this can shed some light; I can made any test needed to narrow down this
issue, just let me know.
Below I've reported one of Oops (obtained via serial interface).
I've got several of them, they differs in EIP and process, but the first item
in call trace is always [<f897c4b9>] uhci_irq+0x67/0x1ca [uhci_hcd]
Hope This Helps..
Best regards.
Unable to handle kernel paging request at virtual address 80000234
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<f897c3ed>] Tainted: P
EFLAGS: 00010046
EIP is at uhci_remove_pending_qhs+0x95/0xfa [uhci_hcd]
eax: 80000234 ebx: 00000093 ecx: 80000200 edx: f55aca24
esi: f74d4e0c edi: f6024000 ebp: f74d4e18 esp: f6025e5c
ds: 007b es: 007b ss: 0068
Process hcid (pid: 2434, threadinfo=f6024000 task=f4c25310)
Stack: 00000296 f74d4e0c f74d4c00 00000000 f74d4c00 0000c000 f6025ef8 f897c4b9
f74d4c00 00000000 f6921780 f74d4c00 00000001 00000000 f6025ef8 c02b9b4e
f74d4c00 f6025ef8 f7d53c80 04000001 c010b617 00000013 f74d4c00 f6025ef8
Call Trace:
[<f897c4b9>] uhci_irq+0x67/0x1ca [uhci_hcd]
[<c02b9b4e>] usb_hcd_irq+0x36/0x5f
[<c010b617>] handle_IRQ_event+0x3a/0x64
[<c010b9d8>] do_IRQ+0xb8/0x196
[<c0109d20>] common_interrupt+0x18/0x20
[<f8a0e7e1>] hci_sock_release+0x126/0x23e [bluetooth]
[<c02cd132>] sock_close+0x0/0x4d
[<c02cc7c4>] sock_release+0x9d/0xfc
[<c02cd132>] sock_close+0x0/0x4d
[<c02cd165>] sock_close+0x33/0x4d
[<c015c957>] __fput+0x12c/0x165
[<c015ad89>] filp_close+0x59/0x96
[<c015ae45>] sys_close+0x7f/0xdd
[<c01093b3>] syscall_call+0x7/0xb
Code: 89 69 34 89 45 04 89 02 89 50 04 8b 54 24 08 c6 82 14 02 00
<0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
Hi Fabio,
> When the dongle is inserted, I can see this on syslog:
> hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb f75dd814 err -90
>
> ..or this:
> hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb f71f7c14 err -22
>
>
> Hope this can shed some light; I can made any test needed to narrow down this
> issue, just let me know.
another thing to try is to disable the SCO support of the HCI USB driver
and in this case it don't uses ISOC transfers.
Regards
Marcel
Alle 11:50, mercoled? 19 novembre 2003, Marcel Holtmann ha scritto:
> >
> > Hope this can shed some light; I can made any test needed to narrow down
> > this issue, just let me know.
>
> another thing to try is to disable the SCO support of the HCI USB driver
> and in this case it don't uses ISOC transfers.
Tried it, and it worked. I've plugged and unplugged the usb dongle several
times in a row without any crash.
It seems that you have got the issue.
I'll keep SCO support disabled for now; I can test whatever you want if you
need me to.
Tnx!
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
Hi Fabio,
> > another thing to try is to disable the SCO support of the HCI USB driver
> > and in this case it don't uses ISOC transfers.
>
> Tried it, and it worked. I've plugged and unplugged the usb dongle several
> times in a row without any crash.
> It seems that you have got the issue.
>
> I'll keep SCO support disabled for now; I can test whatever you want if you
> need me to.
I don't wrote the SCO part of the HCI USB driver and I never worked with
USB ISOC transfers. At the moment we don't know if the problem is part
of the USB subsystem or if it is the driver itself, but I suspect it is
the driver. However I am the wrong person to ask for a fix :(
Regards
Marcel
Alle 23:27, mercoled? 19 novembre 2003, Marcel Holtmann ha scritto:
>
> I don't wrote the SCO part of the HCI USB driver and I never worked with
> USB ISOC transfers. At the moment we don't know if the problem is part
> of the USB subsystem or if it is the driver itself, but I suspect it is
> the driver. However I am the wrong person to ask for a fix :(
Thanks anyway; I've spent some time digging in logs with BT_DEBUG defined, and
I've seen something curious, so I'm posting here and cc'ing the hci_usb
module maintainer as seen on .c file; if someone else is in charge to follow
this code please let me know. I've tried the following without loading hcid
or sdpd, if I do it the crash when usb BT dongle is removed is granted :)
The first thing that I've noticed when a usb BT dongle is plugged is this
error: (test9-bk24)
Nov 25 21:16:02 kefk kernel: hci_usb_intr_rx_submit: hci0
Nov 25 21:16:02 kefk kernel: hci_usb_bulk_rx_submit: hci0 urb f28f1614
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: len 490 mtu 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 0 offset 0 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 1 offset 49 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 2 offset 98 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 3 offset 147 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 4 offset 196 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 5 offset 245 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 6 offset 294 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 7 offset 343 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 8 offset 392 len 49
Nov 25 21:16:02 kefk kernel: __fill_isoc_desc: desc 9 offset 441 len 49
Nov 25 21:16:02 kefk kernel: hci_usb_isoc_rx_submit: hci0 urb f567e414
Nov 25 21:16:02 kefk kernel: hci_usb_isoc_rx_submit: hci0 isoc rx submit
failed urb f567e414 err -22
Nov 25 21:16:02 kefk kernel: __hci_request: hci0 start
i've checked and it seems that usb_submit_urb: fails here (line 340):
switch (temp) {
case PIPE_ISOCHRONOUS:
case PIPE_INTERRUPT:
/* too small? */
if (urb->interval <= 0)
return -EINVAL;
maybe urb->interval is not set from calling code:
static int hci_usb_isoc_rx_submit(struct hci_usb *husb)
(line 236 of ./drivers/bluetooth/hci_usb.c)
but i don't know if this can cause harm.
I've also noticed that when the sub dongle is unplugged, every 10 seconds I
get this:
Nov 25 23:49:38 kefk kernel: drivers/usb/host/uhci-hcd.c: c000: suspend_hc
Nov 25 23:49:47 kefk kernel: hci_sock_create: sock d9f14980
Nov 25 23:49:47 kefk kernel: hci_sock_bind: sock d9f14980 sk dae8f500
Nov 25 23:49:47 kefk kernel: hci_dev_get: 0
Nov 25 23:49:57 kefk kernel: hci_sock_create: sock d9f14780
Nov 25 23:49:57 kefk kernel: hci_sock_bind: sock d9f14780 sk dae8f980
Nov 25 23:49:57 kefk kernel: hci_dev_get: 0
Nov 25 23:50:07 kefk kernel: hci_sock_create: sock d9f14580
Nov 25 23:50:07 kefk kernel: hci_sock_bind: sock d9f14580 sk dae8f680
Nov 25 23:50:07 kefk kernel: hci_dev_get: 0
and the use count of bluetooth module get a +2 increment each time. (hci_usb
is not loaded)
I can see the same behaviour with 2.6.0-test10-bk1
Module Size Used by
bnep 11648 0
l2cap 26368 1 bnep
bluetooth 47972 36 bnep,l2cap
The same holds even if I unload bnep and l2cap modules.
I'll be happy to add any needed information or make other tests, just let me
know.
--
Fabio Coatti http://www.ferrara.linux.it/members/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.