Bugzilla – Bug 278715
Dell 350 Bluetooth device (usb id 413c:8103) not found
Last modified: 2008-04-25 12:34:05 UTC
there is a problem with the dell bluetooth adapter 350. usb id 413c:8103. this adapter is installed on some dell notebooks. normally it works without a problem. but if vista is installed also on the notebook, then linux can't find any bluetooth adapter. and another strange thing is, that the usb id changes to 413c:8105. maybe because of that linux can't find and detect it as bluetooth-adapter. but when booting vista, then rebooting to linux, everything is ok. usb id is 413c:8103 and linux finds it. but this is gone if notebook is switched off. then changes are lost, and usb id is wrong again. this seems to be exactly the same problem found here: http://ubuntuforums.org/showthread.php?p=2464779 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/37288 so it seems, that vista brings some new firmware for this adapter and loads some code when starting, so that things are as they should be, as long as not turned off. it's annoying to have to boot vista once the notebook is switched on.
i found the following workaround, which makes it at least possible to have bluetooth working under linux, regardless if notebook is switched on, or rebootet after running it under win vista: http://sourceforge.net/mailarchive/message.php?msg_id=463EEAA8.3080706%40a1.net the only disadvantage is, that under vista i can't use the latest drivers from dell anymore, but i have to use some generic drivers from toshiba, which have a 30-day-trial-period and don't work as good as the dell-drivers...
This bug report should really be filed upstream at bugzilla.kernel.org. I did a quick search and didn't see anything there. Open a bug there, and include the output of 'hwinfo'. Once it's resolved upstream, please let us know and we'll include the fix in openSUSE 10.3.
Yep. There seem to be a generic problem for bluetooth devices. The other bugreport is against a ThinkPad, this one is a Dell. I am marking those as duplicates now and also add some people into CC that already are in the other report, just to make sure they read this and realize this one is not about a ThinkPad *** This bug has been marked as a duplicate of bug 290615 ***
i don't think this bug is a dublicate of bug 290615. because it is very special to the used hardware, because it (the hardware) shows itself under the wrong hardware-id. however i have found a solution now! on the dell support homepage, there is a tool to downgrade the firmware of the dell bluetooth adapter 350, so that linux correctly detects it, and under vista you can use the default vista bluetooth drivers, so that the adapter is seen (and can be used) on both systems. dell made this firmware-downgrade-tool because under windows-xp the same problems occures. if a customer of this notebook replaced the preinstalled vista with win-xp, he also will not see the bluetooth adapter any more. and dell cares abut their windows-xp-customers..... ;-) (and not about their linux-customers) you can download the firmware-downgrade under: http://support.euro.dell.com/support/downloads/download.aspx?c=at&l=de&s=gen&releaseid=R157674&SystemID=LATITUDE%20PRECISION%20M90&servicetag=&os=WW1&osl=ge&deviceid=7388&devlib=0&typecnt=0&vercnt=1&catid=-1&impid=-1&formatcnt=1&libid=5&fileid=210380 after installing this, and rebooting, bluetooth works on both systems.
Adding Dell contact. Drew: Can you find out, whether we simply have to add another PCI-ID to the driver and which one or whatever compatibility issue is needed. Some input from Dell would be appreciated here. I still do not assign this to anyone. I still try to find out who has more knowledge in bluetooth kernel things, AFAIK Franks Seidel has, but he is on vacation. I also reopen the bug -> see last comment.
Can you provide a bit more info Rainer, pls. E.g. dmesg, cat /proc/bus/usb/devices (hmm, does not exist here, Olaf/Oliver might be able to explain this, maybe you have such a file...). Hopefully this could be resolved by simily adding the additional USB id. Assigning to Olaf for now, adding Oliver to CC, I don't know much about this... Great would be if you could try out the other firmware again at some later point and verify a fix working if Olaf or Oliver come up with one.
mount -t usbfs usbfs /proc/bus/usb cat /proc/bus/usb/devices we need the output from the case where it fails and also when it works.
i have already opened a bug at bugzilla.kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=8786 in this bug, i suppplied some info you requested. (e.g. /proc/bus/usb/devices) Marcel Holtmann took care about that bug on bugzilla.kernel.org. but he said, he needs that/more info in the case/situation where the usb-id is the wrong one. dmesg output, when adapter is detected correctly (and usb-id is 413c:8103): usb 5-1.4: new full speed USB device using ehci_hcd and address 6 usb 5-1.4: new device found, idVendor=413c, idProduct=8103 usb 5-1.4: new device strings: Mfr=0, Product=0, SerialNumber=0 usb 5-1.4: configuration #1 chosen from 1 choice i think, i could reinstall the software which is responsible for this shit. ("vista profile pack") because, now i know a solution, to switch back to working setup. ;-) so i will try to get /proc/bus/usb/devices in the case, where it doesn't work. but i will need some time for this.... the contents of /proc/bus/usb/devices in working situation you can see in http://bugzilla.kernel.org/show_bug.cgi?id=8786
I suggest to track the problem on kernel.org, not in our bugzilla.
ok, here is the relevant part of /proc/bus/usb/devices in the case, where it doesn't work and the id is wrong: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=413c ProdID=8105 Rev=35.38 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=1ms and here is the output in case where it is working: T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=413c ProdID=8103 Rev=24.22 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none) it seems, that in case where it doesn't work, the system thinks it is an bluetooth-mouse/keyboard (Driver=usbhid). this seems understandable for me coz of explanation in http://ubuntuforums.org/showthread.php?p=2464779#7
(In reply to comment #9 from Olaf Hering) > I suggest to track the problem on kernel.org, not in our bugzilla. > ok, i supplied the info also to bugzilla.kernel.org.
Marcel Holtmann (mailto:marcel@holtmann.org) who is an author of the bluez-utils-package, wrote in http://bugzilla.kernel.org/show_bug.cgi?id=8786#c14 "I think you need to modify the hid2hci tool to include the VID:PID 413c:8105 to make it switch between HID and HCI mode." i checked in yast, but there is no bluez-utils-src-package, so i am not able to do these changes myself. so, who can do this changes?
Are you on x86_64 or i386? I need to know that so I can make a binary for you to test.
we (my colleague and me) both use x86_64. on my machine, the firmware downgrade has been done as i wrote in Comment #4 my colleague's machine has installed the newer vista-firmware. it would be interesting to test a newly built hid2hci.
Created attachment 183140 [details] added device to list of devices to switch to hci mode
Please test the rpm from #15
ok, we installed the new rpm. but after reboot the result of lsusb was the same. ... 413c:8105 Dell Computer Corp. ... even after reconfiguring and restart of /etc/init.d/bluetooth there was no change. running hid2hci said: no devices in HCI mode found running hid2hci -1 said: no devices in HID mode found shit! so it was not that simple to just add the id 413c:8105 to the list of supported devices.... maybe we should ask dell about that?
Created attachment 183166 [details] rpm with stupid typo fixed Please test this new RPM
Hello, any opportunity to test? Any other problem?
yes, we also tried this new rpm, but with no success. even after reboot, the chip didn't get recognized as bluetooth-chip: 413c:8105 Dell Computer Corp. on my machine with downgraded firmware: 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth :-(
Could you make an strace of hid2hci with the newest rpm?
Created attachment 187602 [details] output of strace -f hid2hci (In reply to comment #21 from Oliver Neukum) > Could you make an strace of hid2hci with the newest rpm? > do you mean: strace -f hid2hci i have attached this to this post.
Odd. Can you attach the output of "lsusb -v" before and after running hid2hci?
Closing NOREPSONSE, due to missing information for more than 21 days. Please feel free to reopen and provide the requested information.