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,
--
Anders Karlsson <[email protected]>
Trudheim Technology Limited
Hi Anders,
> 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?
> 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
On Fri, 2004-01-30 at 13:33, Marcel Holtmann wrote:
> Hi Anders,
Hello Marcel,
> 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... ;-)
> 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.
> 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,
--
Anders Karlsson <[email protected]>
Trudheim Technology Limited
Hi Anders,
> > 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.
> > 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.
> > 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