Bug 461369

Same here after a "zypper dup" from 11.0. I also removed some bluez config files and reinstalled bluez to be on the safe side.

lsusb:
Bus 001 Device 002: ID 0a5c:200a Broadcom Corp. Bluetooth dongle

/var/log/messages:
kernel: usb 1-1: new full speed USB device using uhci_hcd and address 4
kernel: usb 1-1: configuration #1 chosen from 1 choice
kernel: usb 1-1: New USB device found, idVendor=0a5c, idProduct=200a
kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 1-1: Product: Bluetooth USB Dongle
kernel: usb 1-1: Manufacturer: Broadcom
kernel: usb 1-1: SerialNumber: 2035B0000001
bluetoothd[10951]: HCI dev 0 registered
bluetoothd[10951]: HCI dev 0 up
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
bluetoothd[10951]: Failed to listen on control channel
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
bluetoothd[10951]: Registered interface org.bluez.NetworkPeer on path /org/bluez/10951/hci0
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
bluetoothd[10951]: Registered interface org.bluez.NetworkHub on path /org/bluez/10951/hci0
kernel: hci_cmd_task: hci0 command tx timeout
bluetoothd[10951]: Can't write class of device: Connection timed out (110)
bluetoothd[10951]: Registered interface org.bluez.NetworkRouter on path /org/bluez/10951/hci0
bluetoothd[10951]: Registered interface org.bluez.SerialProxyManager on path /org/bluez/10951/hci0
bluetoothd[10951]: Registered interface org.bluez.Service on path /org/bluez/10951/hci0
bluetoothd[10951]: Adapter /org/bluez/10951/hci0 has been enabled
bluetoothd[10951]: Starting security manager 0
kernel: hci_cmd_task: hci0 command tx timeout

hciconfig:
hci0:   Type: USB
        BD Address: 00:10:60:AF:3C:07 ACL MTU: 377:10 SCO MTU: 64:8
        UP RUNNING 
        RX bytes:675 acl:0 sco:0 events:20 errors:0
        TX bytes:608 acl:0 sco:0 commands:28 errors:0

hcitool scan:
Scanning ...
Inquiry failed: Connection timed out


This dongle worked without any problem since I have it, starting with OS 10.1, 10.0 or even earlier versions.

Roman, that looks very similar to what I was seeing.

I added some info to the wiki:
http://en.opensuse.org/Bluetooth

That fix worked for me, but I think that I need to restart the bluetooth hardware/services manually each time I reboot.

I don't really think it's a problem in bluez, but I can be wrong. The command tx timeout is issued inside the kernel's net/bluetooth/hci_core.c, starting the bluetooth daemon with -nd does not report any problems connecting to d-bus. The d=bus monitor shows the device coming up. In the meantime I tried bluez 4.22 and 4.24, I tried reset=1 when loading btusb, and your advices to use the gnome libs and applet. Still no success.

Please check the web, esp. the (K)Ubuntu bug reports, they report similar problems when switching the kernel version. I'm currently in the process compiling 2.6.28 (2x500MHz, takes some time), and I'll try to check the differences between the kernel used by OS 11.0 and the current one.

Ported bluez 3 to OS 11.1. used the OS build service just in case somebody is interested.

Now it works for me.

Same problem on ThinkPad T43p (oSuSE 11.0 works fine). Problem is on low level.
Message from syslog after "hciconfig hci0 reset" :
-----
Dec 29 21:32:51 rknb bluetoothd[3838]: HCI dev 0 down
Dec 29 21:32:51 rknb bluetoothd[3838]: Adapter /org/bluez/3838/hci0 has been
disabled
Dec 29 21:32:51 rknb bluetoothd[3838]: Stopping security manager 0
Dec 29 21:32:51 rknb bluetoothd[3838]: HCI dev 0 up
Dec 29 21:32:56 rknb bluetoothd[3838]: Can't write inquiry mode for
/org/bluez/3838/hci0: Connection timed out (110)
Dec 29 21:32:56 rknb bluetoothd[3838]: Failed to listen on interrupt channel
Dec 29 21:32:56 rknb bluetoothd[3838]: D-Bus failed to register
org.bluez.Service interface
Dec 29 21:32:56 rknb bluetoothd[3838]: Unable to allocate new io channel
Dec 29 21:32:56 rknb bluetoothd[3838]: Adapter /org/bluez/3838/hci0 has been
enabled
Dec 29 21:32:56 rknb bluetoothd[3838]: Starting security manager 0
Dec 29 21:32:56 rknb kernel: hci_cmd_task: hci0 command tx timeout
----
bluez 4.19-1.5, KDE3 .. all from oSuSE 11.1 final.

Beat my head against this until I figured out that my problem was not bluez...  I had to learn bluez to find that out.

I have now discovered that the gnome bluetooth applet and browser work fine for me with 4.19 (I should have tried it first but the wiki seemed to say I needed to upgrade bluez and I use KDE anyway so I'd like it to work).  This is the case on my D830 notebook and on my desktop with a Broadcom USB dongle.

Works with 4.19, 4.22 and 4.25...

kbluetooth won't do anyting, however.  With any of those three versions.  On a right-click, all menu entries are gray and a left-click gets "The process for the bluetooth protocol died unexpectedly.".

This is the error message from kbluetooth after a left click:

Launched ok, pid = 6280
process 6283: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074.
This is normally a bug in some application using the D-Bus library.
  D-Bus not built with -rdynamic so unable to print a backtrace
kioslave: ####### CRASH ###### protocol = kio_bluetooth pid = 6283 signal = 6
akode: Guessed format: xiph
KNotify::playTimeout

Anyway, is there a way to get kbluetooth to work?  Or to make the gnome applet from KDE? (I tried it, it runs but browsing doesn't work).  Or to get the functionality from something else?

BTW, the symptom in the original post about not getting on the D-bus happens if one does bluetooth -nd while it is already running in the background.  Voice of experience here...

So maybe this is a different problem than the one originally reported.

I spend some days about this problem and that is what I get

1) KDE 4 don't support yet those protocols:
          - obex://
          - sdp://
          - bluetooth://

that is why clicking on bluetooth icon in systray causing error konqueror not recognize it that was also on openSUSE 11.0

2) KDE 3.5 on openSUSE 11.1 bluetooth not working at all 
those protocols (point 1) show an error message about "The process for
the bluetooth protocol died unexpectedly."

in 11.0 everything was ok

3) kbluetooth4 not working (exactly working but it have some problems with appear on systray and etc...) and there is no way to pair devices 

4) kbluetooth from 3.x work correctly on 11.0
on openSUSE 11.1 kbluetooth show that there is no device. One time kbluetooth from 3.5 work for me almost correctly as on KDE 4 and openSUSE 11.0 without PIN window I couldn't pair my devices

5) bluetooth-applet Work almost correctly on KDE 4 but also when you want to browse device it try to open location obex://[MAC address of device] without  success look at point 1) but what is most important for me it allow Pair devices 

6) obexftp -b <addr> -l / work correctly when you pair devices and also obexvf

7) sdptool, hcitool work almost correctly (they cannot make connection but when you make connection using fe. obexftp everything work correctly)

8) c, c++ programs writen with <bluetooth.h> also work correctly send receive data search devices get devices services etc...

9) passkey-agent: on this version of bluez there is no way to store PIN on computer config files, there is no /etc/bluetooth/hcid.conf, I found that i should use passkey-agent but I didn't find rpm to opensuse 11.1 the bluez-utils didn't contain passkey-agent and what more this package has unresolved dependices so I cannot pair my devise using only console 

and last thin is anyone know how to pair devices on C++

For temporary fix this bug you may install packages bluez-libs and bluez-utils from opensuse 11 repository.

rpm -U --force bluez-libs-3.32-3.1.i586.rpm bluez-utils-3.32-8.1.i586.rpm

This bug is very confusing (and probably several issues are garbled together here).

What exactly is the problem with bluez-4.19?
(not with KDE or GNOME or anything, please open separate bugs for that).

The issue I have is certainly outside of KDE and Gnome. I guess that I had not made it clear that this bug was not intended to cover issues with the KDE or Gnome tools, but something with bluez or from the looks of it the driver.

I'm not sure anymore that the problem was with bluez 4.19, but rather the btusb kernel module. Since upgrading bluez, I have still had issues with getting hci0 up, and the fix has been to modprobe hci_usb (the legacy driver). Once I do that, things work fairly well. Initially, after I upgraded to bluez 4.22, bluetooth seemed like it was working, but that may have been becuase the hci_usb driver was loading. Since it stopped loading automatically, I've had to load it before starting hci0 and bluetoothd. 

If someone wants more clarification than that, please ask me to preform specific tasks with whichever modules enabled or disabled, and which outputs you'd like to see. I ran across this several weeks ago and have been using my temporary fix since then. 

Ok. Thanks for clearing the clouds ;-)

Could you please try if loading the btusb module with the parameter "reset=1" (after unloading the hci_usb of course, and if you have blacklisted btusb, you might need to un-blacklist it) does help?

modprobe btusb reset=1

is the commandline for that.

Hmm, that seems to work just fine, I'm not sure why I didn't try that before. 

I will add the option btusb reset=1 to my modprobe files and report back. Thanks for the help!

Ok. I'll explain the issue:

The reset=1 flag is a workaround for some (broken? non-spec? ...) adapters.
Unfortunately, you cannot use it on all adapters, since some of them (older ones, I think) will not work with it, maybe because the low-level reset command changed semantics some time ago, i don't remember exactly anymore.

The old hci_usb driver had a pretty large list of quirks for different devices, for example listing all devices that need "reset=1". The new btusb driver was created, and the workaround list was missing first. This is why you need to give "reset=1" to the module.

The solution for the future is, that the btusb module will use "reset=1" always, _except_ for devices that are in a "blacklist". This is done because all new devices should have no problems with "reset=1", but might have problems without.
The old devices (a potentially much lower number than all the new ones) will get blacklisted and everything will be fine.

Unfortunately, the driver in 11.1 does not yet have this mechanism, so this is why you need to configure this manually for now.

I'll close the bug as "fixed in FACTORY" for now.
(I'm actually not sure if the current FACTORY kernel already has the fixed driver, but we will get it for 11.2 for sure).

Another wrinkle, I edited my modprobe files to use btusb instead of hci_usb, I tried a couple different configurations, but currently in /etc/modprobe.conf.local I have:

install btusb /bin/true
options btusb reset=1

Also, hci_usb is blacklisted. After I boot up with these options in my config file, an lsmod does not show btusb as being loaded. I try to 'modprobe btusb reset=1' or 'modprobe btusb' and lsmod still does not show it loaded. I am stil able to load hci_usb, and that shows up properly in lsmod. What am I doing wrong here?

Remove this line:

install btusb /bin/true

It tells modprobe to run "/bin/true" to load btusb ;-)

Worked. Thanks!

=)

It's don't work for me. In /etc/modprobe.conf.local I have:

options btusb reset=1

but, when i insert bluetooth device, in /var/log/masseges i see:

Jan  9 13:10:57 linux-jdbp kernel: usb 3-2: new full speed USB device using uhci_hcd and address 2
Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: configuration #1 chosen from 1 choice
Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: New USB device found, idVendor=0a12, idProduct=0001
Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: Product: BT2.0
Jan  9 13:10:58 linux-jdbp bluetoothd[2911]: HCI dev 0 registered
Jan  9 13:10:58 linux-jdbp kernel: Bluetooth: Generic Bluetooth USB driver ver 0.3
Jan  9 13:10:58 linux-jdbp kernel: usbcore: registered new interface driver btusb
Jan  9 13:10:58 linux-jdbp kernel: Bluetooth: HCI USB driver ver 2.10
Jan  9 13:10:58 linux-jdbp kernel: usbcore: registered new interface driver hci_usb
Jan  9 13:10:58 linux-jdbp bluetoothd[2911]: HCI dev 0 up
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.NetworkPeer on path /org/bluez/2911/hci0
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.NetworkHub on path /org/bluez/2911/hci0
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.NetworkRouter on path /org/bluez/2911/hci0
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Service on path /org/bluez/2911/hci0
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.SerialProxyManager on path /org/bluez/2911/hci0
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Control on path /org/bluez/2911/hci0/dev_00_1B_AF_FC_DC_4E
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Serial on path /org/bluez/2911/hci0/dev_00_1B_AF_FC_DC_4E
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: probe failed with driver input-headset for device /org/bluez/2911/hci0/dev_00_1B_AF_FC_DC_4E
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Network on path /org/bluez/2911/hci0/dev_00_1D_E9_7E_A2_15
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Control on path /org/bluez/2911/hci0/dev_00_1D_E9_7E_A2_15
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Registered interface org.bluez.Serial on path /org/bluez/2911/hci0/dev_00_1D_E9_7E_A2_15
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: probe failed with driver input-headset for device /org/bluez/2911/hci0/dev_00_1D_E9_7E_A2_15
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Adapter /org/bluez/2911/hci0 has been enabled
Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Starting security manager 0

And more, all as described in Comment #7 From Szymon Kowalczyk
What am I doing wrong here?

(In reply to comment #18 from karapuz karapuz)
> It's don't work for me. In /etc/modprobe.conf.local I have:
> 
> options btusb reset=1
> 
> but, when i insert bluetooth device, in /var/log/masseges i see:
> 
> Jan  9 13:10:57 linux-jdbp kernel: usb 3-2: new full speed USB device using
> uhci_hcd and address 2
> Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: configuration #1 chosen from 1
> choice
> Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: New USB device found,
> idVendor=0a12, idProduct=0001
> Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: New USB device strings: Mfr=0,
> Product=2, SerialNumber=0
> Jan  9 13:10:58 linux-jdbp kernel: usb 3-2: Product: BT2.0
> Jan  9 13:10:58 linux-jdbp bluetoothd[2911]: HCI dev 0 registered
> Jan  9 13:10:58 linux-jdbp kernel: Bluetooth: Generic Bluetooth USB driver ver
> 0.3
> Jan  9 13:10:58 linux-jdbp kernel: usbcore: registered new interface driver
> btusb
> Jan  9 13:10:58 linux-jdbp kernel: Bluetooth: HCI USB driver ver 2.10
> Jan  9 13:10:58 linux-jdbp kernel: usbcore: registered new interface driver
> hci_usb
> Jan  9 13:10:58 linux-jdbp bluetoothd[2911]: HCI dev 0 up

...

> Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Adapter /org/bluez/2911/hci0 has
> been enabled
> Jan  9 13:10:59 linux-jdbp bluetoothd[2911]: Starting security manager 0

So the Hardware is initialized and Bluez 4.19 is working perfectly fine. The bug described by John is fixed.

> And more, all as described in Comment #7 From Szymon Kowalczyk
> What am I doing wrong here?

You are mixing up bug reports. Comment #7 is a different bug. Comment #7 is in fact at least two different bugs, one for KDE4 and one for KDE3, probably a few more.

This is an autogenerated message for OBS integration:
This bug (461369) was mentioned in
https://build.opensuse.org/request/show/4851 Factory / bluez