Bluetooth oddity
Hi list,
Out of curiosity, has anyone else noticed something odd with Bluetooth in 2.6.x kernels? On my Thinkpad X31 I can switch it on/off with Fn+F5. Switching it on is no problem, but switching it off causes solid hang of the Thinkpad. Only SysRq+b works.
It is not the whole world, but a little irritating. Also, I use Bluetooth to hot-sync my Tungsten T|3. Same problem occurs on the 4th - 6th sync, solid hang of the Thinkpad. No debug output yet, if any Bluetooth developers are interested to have this fixed, I am game to help debug this.
Regards,
Signature · 2 lines
Anders Karlsson <[email protected]> Trudheim Technology Limited
Hi Anders,
Quoted 4 lines
Out of curiosity, has anyone else noticed something odd with Bluetooth in 2.6.x kernels? On my Thinkpad X31 I can switch it on/off with Fn+F5. Switching it on is no problem, but switching it off causes solid hang of the Thinkpad. Only SysRq+b works.
I assume that you have enabled the SCO support of the HCI USB driver. The unlink of ISOC URB's fails on UHCI host controllers and actually I don't know why. So disable the SCO support of the HCI USB driver and you can switch on and off your Bluetooth device as often as you like.
What is your USB host controller chipset? Do you see an oops?
Quoted 5 lines
It is not the whole world, but a little irritating. Also, I use Bluetooth to hot-sync my Tungsten T|3. Same problem occurs on the 4th - 6th sync, solid hang of the Thinkpad. No debug output yet, if any Bluetooth developers are interested to have this fixed, I am game to help debug this.
This was a bug in the RFCOMM layer that has been already fixed. Why don't you say what 2.6 kernel do you use? Try the latest 2.6.2-rc2 or 2.6.1-mh3 and this will go away.
Regards
Marcel
Quoted 1 line · Marcel Holtmann
Hi Anders,
Hello Marcel,
Quoted 4 lines
I assume that you have enabled the SCO support of the HCI USB driver. The unlink of ISOC URB's fails on UHCI host controllers and actually I don't know why. So disable the SCO support of the HCI USB driver and you can switch on and off your Bluetooth device as often as you like.
I just checked, and I did have the SCO support switched on. Shows that the name can not be trusted... ;-)
Quoted 1 line
What is your USB host controller chipset? Do you see an oops?
No oops, rebuilding the kernel with serial support built in so I can attach serial console. After that I should be able to capture any information required.
Quoted 3 lines
This was a bug in the RFCOMM layer that has been already fixed. Why don't you say what 2.6 kernel do you use? Try the latest 2.6.2-rc2 or 2.6.1-mh3 and this will go away.
I am currently using 2.6.1 proper, but saw it in 2.6.0 and a couple of half-way houses between 2.6.0 and 2.6.1.
I will give 2.6.2-rc2 a try over the weekend.
Regards,
Signature · 2 lines
Anders Karlsson <[email protected]> Trudheim Technology Limited
Hi Anders,
Quoted 7 lines
Quoted 4 lines
I assume that you have enabled the SCO support of the HCI USB driver. The unlink of ISOC URB's fails on UHCI host controllers and actually I don't know why. So disable the SCO support of the HCI USB driver and you can switch on and off your Bluetooth device as often as you like.
I just checked, and I did have the SCO support switched on. Shows that the name can not be trusted... ;-)
the CONFIG_BT_SCO option is not problematic, you can leave this on. But for now you must disable CONFIG_BT_HCIUSB_SCO if you have an UHCI host controller.
Quoted 5 lines
Quoted 1 line
What is your USB host controller chipset? Do you see an oops?
No oops, rebuilding the kernel with serial support built in so I can attach serial console. After that I should be able to capture any information required.
Apply patch-2.6.1-mh3 and rebuild your kernel. This patch only updates your Bluetooth subsystem. To not run into problems with your modules undiff the change to the Makefile EXTRAVERSION before calling make.
Quoted 6 lines
Quoted 3 lines
This was a bug in the RFCOMM layer that has been already fixed. Why don't you say what 2.6 kernel do you use? Try the latest 2.6.2-rc2 or 2.6.1-mh3 and this will go away.
I am currently using 2.6.1 proper, but saw it in 2.6.0 and a couple of half-way houses between 2.6.0 and 2.6.1.
I know, but our big resync with 2.6 was first in 2.6.2-rc1. And this bug only occurred on incoming RFCOMM connections.
Regards
Marcel