Multiple connections with kernel 2.4 make HCI die
Hello,
I know that kernel 2.4 is no longer supported, but I hope that somebody can give me a clue here...
I'm attempting to create a multi-threaded, multi-dongle OBEX client appliance. When I run it on a kernel 2.6 based machine (either a x86 or on a NSLU2, which is a big-endian ARM box), everything runs very smooth.
The same code compiled for a little endian MIPS machine running kernel 2.4.30 has problems. I cannot change the kernel version, because the on-board Broadcom wireless chipset of the router doesn't really work yet
under kernel 2.6 (damn closed source drivers) :(
When one bt interface does device discovery and another interface does service discovery and the RFCOMM transfers, everything is fine. As soon as data is sent/received over two connections simultaneously, the HCIs begin to "die" - they don't respond to hciconfig reset/up/down commands and all data transmissions time out, as do SDP connects. If I 'hciconfig down' the interfaces, they don't come up again afterwards. The only thing that helps is re-plugging the dongles. Re-loading hci-usb or the uhci drivers is not enough, although all interfaces show as "up" again afterwards. They still time out, though.
This hang might come after a few kb's of simultenous data was sent, or after up to two megabyte have been transferred. It comes quicker when two dongles transmit data simultaneously, but also happens when I have two active RFCOMM connections on one dongle.
I have applied the changes in the 2.4.32 patch by Marcel, but I think they only refer to module unloading. Bluez installed is version 2.32. I already stressed the USB bus with wireless and a hard disk, to rule out that the usb driver has some funkiness, but everything went smooth.
It would be great if somebody could help me here, I'm totally stuck. I can give out shell access to the router, if that is of any help with this problem.
Best regards,
Kevin
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann
maintainerHi Kevin,
Quoted 11 lines
I know that kernel 2.4 is no longer supported, but I hope that somebody can give me a clue here...
I'm attempting to create a multi-threaded, multi-dongle OBEX client appliance. When I run it on a kernel 2.6 based machine (either a x86 or on a NSLU2, which is a big-endian ARM box), everything runs very smooth.
The same code compiled for a little endian MIPS machine running kernel 2.4.30 has problems. I cannot change the kernel version, because the on-board Broadcom wireless chipset of the router doesn't really work yet
under kernel 2.6 (damn closed source drivers) :(
I am not buying this argument, because the bcm43xx open source driver exists. Otherwise simply swap the mini-PCI card for an Intel one.
Quoted 15 lines
When one bt interface does device discovery and another interface does service discovery and the RFCOMM transfers, everything is fine. As soon as data is sent/received over two connections simultaneously, the HCIs begin to "die" - they don't respond to hciconfig reset/up/down commands and all data transmissions time out, as do SDP connects. If I 'hciconfig down' the interfaces, they don't come up again afterwards. The only thing that helps is re-plugging the dongles. Re-loading hci-usb or the uhci drivers is not enough, although all interfaces show as "up" again afterwards. They still time out, though.
This hang might come after a few kb's of simultenous data was sent, or after up to two megabyte have been transferred. It comes quicker when two dongles transmit data simultaneously, but also happens when I have two active RFCOMM connections on one dongle.
Quoted 4 lines
I have applied the changes in the 2.4.32 patch by Marcel, but I think they only refer to module unloading. Bluez installed is version 2.32. I already stressed the USB bus with wireless and a hard disk, to rule out that the usb driver has some funkiness, but everything went smooth.
You can try to make sure that the hci_usb driver doesn't use any ISOC transfers for SCO. The 2.4 USB subsystem was kinda picky about it. Other than that you don't really have a choice except re-writing the hci_usb driver.
Regards
Marcel
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
Hi Marcel,
thanks for the quick answer.
Quoted 7 lines
Quoted 7 lines
I know that kernel 2.4 is no longer supported, but I hope that somebody can give me a clue here...
I'm attempting to create a multi-threaded, multi-dongle OBEX client appliance. When I run it on a kernel 2.6 based machine (either a x86 or on a NSLU2, which is a big-endian ARM box), everything runs very smooth.
Quoted 7 lines
Quoted 4 lines
The same code compiled for a little endian MIPS machine running kernel 2.4.30 has problems. I cannot change the kernel version, because the on-board Broadcom wireless chipset of the router doesn't really work yet
under kernel 2.6 (damn closed source drivers) :(I am not buying this argument, because the bcm43xx open source driver exists. Otherwise simply swap the mini-PCI card for an Intel one.
This is slightly OT but I hope it might be of interest to some:
I have already tried to compile the bcm43xx driver in OpenWRT kamikaze. Master mode will only work with the devicescape-branch of bcm43xx. Some OpenWRT co-users patched the Kamikaze kernel up to the latest code from the wireless-dev git repository. Unfortunately there was no joy there. Master mode does not yet run correctly, although the outlook is pretty good, as patches integrating bcm43xx and Hostap where sent to the bcm43xx devs and will hopefully get integrated soon.
Unfortunately for me, I need WDS and this has not yet been coded. And Kamikaze kernel 2.6 USB is broken at the moment, so I couldn't test bluetooth operation on the 2.6 :(
I'll look into swapping the mini-PCI card, thanks for the pointer. That might become a great alternative once the USB problems get sorted out.
<snip>
Quoted 10 lines
Quoted 5 lines
I have applied the changes in the 2.4.32 patch by Marcel, but I think they only refer to module unloading. Bluez installed is version 2.32. I already stressed the USB bus with wireless and a hard disk, to rule out that the usb driver has some funkiness, but everything went smooth.
You can try to make sure that the
hci_usbdriver doesn't use any ISOC transfers for SCO. The 2.4 USB subsystem was kinda picky about it. Other than that you don't really have a choice except re-writing thehci_usbdriver.
Ok, I'll rebuild a kernel with SCO support right away. Will that suffice, or should I comment out the ISOC stuff in hci_usb.c?
I don't think I'll manage a re-write of hci_usb :/ Waiting for solid 2.6 usb and bcm43xx support will definitely be faster than that ;)
Regards and thanks,
Kevin
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann
maintainerHi Kevin,
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I have applied the changes in the 2.4.32 patch by Marcel, but I think they only refer to module unloading. Bluez installed is version 2.32. I already stressed the USB bus with wireless and a hard disk, to rule out that the usb driver has some funkiness, but everything went smooth.
Quoted 7 lines
Quoted 4 lines
You can try to make sure that the
hci_usbdriver doesn't use any ISOC transfers for SCO. The 2.4 USB subsystem was kinda picky about it. Other than that you don't really have a choice except re-writing thehci_usbdriver.Ok, I'll rebuild a kernel with SCO support right away. Will that suffice, or should I comment out the ISOC stuff in
hci_usb.c?
no. Disable the SCO support of the hci_usb driver. With a 2.6 kernel you can do this with a module paramter, but I am not sure if this made it ever into the 2.4 kernel.
Regards
Marcel
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Kevin,
Quoted 3 lines
no. Disable the SCO support of the
hci_usbdriver. With a 2.6 kernel you can do this with a module paramter, but I am not sure if this made it ever into the 2.4 kernel.
Just to avoid you wasting your time, I'm seeing what sounds like exactly the same thing with a UART connection rather than USB. This is with a 2.4.18 kernel and 2.25 bluez-libs. Fortunately in my system I can easily power-cycle the dongle, which seems to be the only way to bring it back to life.
Hopefully it goes without saying that I'm very interested to hear about anything you find that helps :-)
Chris
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users