It appears that the btusb driver has never worked for at least the
following dongles:
1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
1131:1004 Integrated System Solution Corp. Bluetooth Device
2001:f111 D-Link Corp. [hex] DBT-122 Bluetooth adapter
0a5c:200a Broadcom Corp. Bluetooth dongle
And so when this became the default driver in 2.6.27, some users could
no longer use Bluetooth. They can generally scan for devices, but no
connections can be established in either direction.
See the bug report here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502
I have the KY-BT100 listed above, and was hoping this would be an
ordinary regression where I could just bisect and find the bad commit.
But I soon realized what made Bluetooth work or not work was whether
hci_usb or btusb was being used. One thing I noticed is that either way,
I got this in dmesg:
hci_cmd_task: hci0 command tx timeout
This seems to be common to everyone experiencing this issue. Since the
message is still produced with the hci_usb driver, even though that
driver works, a (perhaps naive) guess of mine is that the problem has
something to do with the two drivers handling this error differently.
I'm attaching the output of 'hciconfig -a' and logs of 'bluetoothd -nd'.
I got different results depending on whether I plugged in the dongle
before or after starting bluetoothd, so I'm supplying both log files. In
the hotplugging case, I got these two messages:
bluetoothd[6745]: Adapter /org/bluez/6745/hci0 without an address
bluetoothd[6745]: Can't read version info for /org/bluez/6745/hci0:
Unknown error 18446744073709551506 (-110)
after plugging in the device, and the applet didn't show a list of
paired devices to try to connect to, so I just unplugged the device.
In the other log file, I tried a couple times to browse my phone from my
computer, send a file, and I tried to browse my computer from my phone.
Then I hit ctrl-C. This is with BlueZ 4.28 and post-2.6.29-rc3.
What other information can I provide to track down this problem?
Brian
Hi,
> I have been working with PANU profile contained in BlueZ 4.30.
>
> Whenever I try to connect NAP,I see the following message,
> "
> pan1 connected
> pan1 disconnected."
the pan1 suppose to be the bridge interface bluetoothd tries to connect
all its bnepX interface too.
> As you may know, the first line message is located in bnep_connect_cb(). and
> the second message is in bnecp_watchdog_cb().
>
> As I inspect the condition value "GIOCondition cond" in bnep_watchdog_cb(),
> there is only "G_IO_ERR", and the others bits are all clean.
> And I try to analyze error packet, but I couldn't do that.
>
> I don't know why this problem happens.
>
> If you're already experienced this, it'll be very thankful to give me a
> piece of advice?
>
>
> And I would like to ask
> "Does BlueZ support both PANU and NAP officially?"
> As I see on the BlueZ wiki, it supports only PANU.
Yes, PANU and NAP are working. So does GN.
Regards
Marcel
Dear all
I have been working with PANU profile contained in BlueZ 4.30.
Whenever I try to connect NAP,I see the following message,
"
pan1 connected
pan1 disconnected."
As you may know, the first line message is located in bnep_connect_cb(). and
the second message is in bnecp_watchdog_cb().
As I inspect the condition value "GIOCondition cond" in bnep_watchdog_cb(),
there is only "G_IO_ERR", and the others bits are all clean.
And I try to analyze error packet, but I couldn't do that.
I don't know why this problem happens.
If you're already experienced this, it'll be very thankful to give me a
piece of advice?
And I would like to ask
"Does BlueZ support both PANU and NAP officially?"
As I see on the BlueZ wiki, it supports only PANU.
Have a nice day!
Regards
Chanyeol,Park
Hi Brian,
> >>> Also please run a kernel built from bluetooth-testing.git so I can
> >>> properly debug this. There is one change in it that affects the bulk
> >>> URBs and maybe these dongles just don't like it if we only submit them
> >>> when needed.
> >> I found bluetooth-testing.git last night after posting here, and merged
> >> it into my kernel. Today I just tested it, and the problem is solved
> >> here. So there's probably no reason to provide the dump anymore. Will
> >> this fix be backported to 2.6.27 and 2.6.28?
> >>
> >
> > not likely since it is not clear what is causing it. There can be some
> > other changes in the tree that could have broken and fixed it. Sometimes
> > this is not Bluetooth related.
> >
>
> Maybe this isn't the same as knowing what's causing it, but I'm pretty
> sure that 'Submit bulk URBs along with interrupt URBs' fixed it. I had
> done some bisecting in search of the problem and never found a point
> before it where btusb worked with the affected dongle. Rolling back to
> just before that commit reproduces the problem, and then stepping
> forward one fixes it again. I also tried starting with 2.6.27 and
> cherry-picking the changes that touch drivers/bluetooth/btusb.c. That
> also produced working Bluetooth as soon as that same commit was added.
>
> Anyway, if it does not get backported to the official stable branches, I
> think some distros will still want to add it to their kernels. I'll try
> to get this into Ubuntu Jaunty's 2.6.28 kernel. So for the sake of me
> saying "this is the fix applied upstream", do you have an ETA on when
> this stuff will be merged into the kernel mainline?
I will be sending them for net-next inclusion during this week. Just
have to apply one additional patch and verify that it is fixing a crash
we saw lately.
Regards
Marcel
Marcel Holtmann wrote:
>>> Also please run a kernel built from bluetooth-testing.git so I can
>>> properly debug this. There is one change in it that affects the bulk
>>> URBs and maybe these dongles just don't like it if we only submit them
>>> when needed.
>> I found bluetooth-testing.git last night after posting here, and merged
>> it into my kernel. Today I just tested it, and the problem is solved
>> here. So there's probably no reason to provide the dump anymore. Will
>> this fix be backported to 2.6.27 and 2.6.28?
>>
>
> not likely since it is not clear what is causing it. There can be some
> other changes in the tree that could have broken and fixed it. Sometimes
> this is not Bluetooth related.
>
Maybe this isn't the same as knowing what's causing it, but I'm pretty
sure that 'Submit bulk URBs along with interrupt URBs' fixed it. I had
done some bisecting in search of the problem and never found a point
before it where btusb worked with the affected dongle. Rolling back to
just before that commit reproduces the problem, and then stepping
forward one fixes it again. I also tried starting with 2.6.27 and
cherry-picking the changes that touch drivers/bluetooth/btusb.c. That
also produced working Bluetooth as soon as that same commit was added.
Anyway, if it does not get backported to the official stable branches, I
think some distros will still want to add it to their kernels. I'll try
to get this into Ubuntu Jaunty's 2.6.28 kernel. So for the sake of me
saying "this is the fix applied upstream", do you have an ETA on when
this stuff will be merged into the kernel mainline?
Hi Brian,
> > Don't try with bluetoothd at all. Make sure it is not running. Plug in
> > the dongle and start hcidump -X -V and then do hciconfig hci0 up. This
> > way I see what is going on.
> >
> And then start bluetoothd at this point, right? (Assuming no obvious
> errors have already occurred)
not starting bluetoothd is just for testing so I see all messages from
hcidump.
> > Also please run a kernel built from bluetooth-testing.git so I can
> > properly debug this. There is one change in it that affects the bulk
> > URBs and maybe these dongles just don't like it if we only submit them
> > when needed.
> >
> I found bluetooth-testing.git last night after posting here, and merged
> it into my kernel. Today I just tested it, and the problem is solved
> here. So there's probably no reason to provide the dump anymore. Will
> this fix be backported to 2.6.27 and 2.6.28?
not likely since it is not clear what is causing it. There can be some
other changes in the tree that could have broken and fixed it. Sometimes
this is not Bluetooth related.
> (BTW, there's now a compile error in bluetooth-testing.git as of today)
I re-based against 2.6.29-rc4 and then boarded and plane and merged a
bad patch into it. Should be fixed now. Feel free to re-test it.
> > Next step is to check on these devices ISOC interface. So I need the
> > content of /proc/bus/usb/devices for this dongle. And then you need to
> > try to mark them with BTUSB_BROKEN_ISOC.
> >
> This dongle now functions better than my laptop's internal Bluetooth
> device. I'll make sure to include this info and an hcidump log when I
> start a thread for the issue I'm having with that.
They should all work the same :)
Regards
Marcel
Marcel Holtmann wrote:
> Don't try with bluetoothd at all. Make sure it is not running. Plug in
> the dongle and start hcidump -X -V and then do hciconfig hci0 up. This
> way I see what is going on.
>
And then start bluetoothd at this point, right? (Assuming no obvious
errors have already occurred)
> Also please run a kernel built from bluetooth-testing.git so I can
> properly debug this. There is one change in it that affects the bulk
> URBs and maybe these dongles just don't like it if we only submit them
> when needed.
>
I found bluetooth-testing.git last night after posting here, and merged
it into my kernel. Today I just tested it, and the problem is solved
here. So there's probably no reason to provide the dump anymore. Will
this fix be backported to 2.6.27 and 2.6.28?
(BTW, there's now a compile error in bluetooth-testing.git as of today)
> Next step is to check on these devices ISOC interface. So I need the
> content of /proc/bus/usb/devices for this dongle. And then you need to
> try to mark them with BTUSB_BROKEN_ISOC.
>
This dongle now functions better than my laptop's internal Bluetooth
device. I'll make sure to include this info and an hcidump log when I
start a thread for the issue I'm having with that.
Thanks!
Hi Brian,
> It appears that the btusb driver has never worked for at least the
> following dongles:
>
> 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
> 1131:1004 Integrated System Solution Corp. Bluetooth Device
> 2001:f111 D-Link Corp. [hex] DBT-122 Bluetooth adapter
> 0a5c:200a Broadcom Corp. Bluetooth dongle
>
> And so when this became the default driver in 2.6.27, some users could
> no longer use Bluetooth. They can generally scan for devices, but no
> connections can be established in either direction.
>
> See the bug report here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502
just a warning here. Everything that is buried in Ubuntu bugs is nothing
I care about. The Ubuntu kernel maintainers have to learn to get these
things solved upstream.
> I have the KY-BT100 listed above, and was hoping this would be an
> ordinary regression where I could just bisect and find the bad commit.
> But I soon realized what made Bluetooth work or not work was whether
> hci_usb or btusb was being used. One thing I noticed is that either way,
> I got this in dmesg:
>
> hci_cmd_task: hci0 command tx timeout
>
> This seems to be common to everyone experiencing this issue. Since the
> message is still produced with the hci_usb driver, even though that
> driver works, a (perhaps naive) guess of mine is that the problem has
> something to do with the two drivers handling this error differently.
>
> I'm attaching the output of 'hciconfig -a' and logs of 'bluetoothd -nd'.
> I got different results depending on whether I plugged in the dongle
> before or after starting bluetoothd, so I'm supplying both log files. In
> the hotplugging case, I got these two messages:
>
> bluetoothd[6745]: Adapter /org/bluez/6745/hci0 without an address
> bluetoothd[6745]: Can't read version info for /org/bluez/6745/hci0:
> Unknown error 18446744073709551506 (-110)
>
> after plugging in the device, and the applet didn't show a list of
> paired devices to try to connect to, so I just unplugged the device.
Don't try with bluetoothd at all. Make sure it is not running. Plug in
the dongle and start hcidump -X -V and then do hciconfig hci0 up. This
way I see what is going on.
Also please run a kernel built from bluetooth-testing.git so I can
properly debug this. There is one change in it that affects the bulk
URBs and maybe these dongles just don't like it if we only submit them
when needed.
Next step is to check on these devices ISOC interface. So I need the
content of /proc/bus/usb/devices for this dongle. And then you need to
try to mark them with BTUSB_BROKEN_ISOC.
Regards
Marcel