In the Gentoo forums there are some reports of problems when running the bluetooth initialization script, resulting in error messages like "Can't open HCI socket.: Address family not supported by protocol". The third post of this thread gave me the clue about what is wrong: http://forums.gentoo.org/viewtopic-t-247173.html Basically, if the ohci_hcd module is not loaded when the script runs, USB dongles are not found. This can happen if one has no other USB devices that forced the autoload of the module: on my home computer with a USB mouse this problem does not happen, but it happens on my work machine (with a PS/2 mouse and no other USB device). Workaround: place ohci_hcd in /etc/modules.autoload.d/kernel-2.6, or possibly compile into kernel. Solution: modify the init script to load the module, check for dongles and unload if none are found.
Not all motherboards support ohci - in fact, I have uhci here, and no problems with my usb bluetooth dongle (granted, I don't have any bt devices to connect to, yet) however, modprobing the module should be handled elsewhere
How do we know that your USB is OHCI, and not UHCI or EHCI? And what if the driver is compiled into kernel instead of being a module? Sorry, too much hassle for too small benefit. Also, this is hotplug's/coldplug's job, my USB BT gets even coldplugged unless I disable the coldplug thing. Guessing module names is not something an init script should do.
Severity is not trivial: it is a bug and it should be fixed. Whether the fix is to be implemented in the bluetooth or in the hotplug scripts can be debated, but this problem has been blocking several people from using USB dongles, it cannot be ignored just because it works on some systems.
(In reply to comment #3) > Severity is not trivial: it is a bug and it should be fixed. > Whether the fix is to be implemented in the bluetooth or in the hotplug scripts > can be debated, but this problem has been blocking several people from using > USB dongles, it cannot be ignored just because it works on some systems. For this to be fixed, you need to provide some information, like relevant parts of dmesg output and your kernel .config. That will be much more useful than messing w/ severity of this bug.
Jakub, if you are not interested in this bug go somewhere else. People are trying to get things to work here. _You_ have been messing with the severity: "trivial" means "cosmetic problem like misspelled words or misaligned text", and this bug is more serious than that since because of it a device does not function at all, and resulting error messages are not helpful. "Normal" is the appropriate severity. The Way It Is Supposed To Work is that I plug the dongle and it works. As long as it does not behave like that on all platforms, we have a bug. I reported that, for me and others, modprobing ohci_hdc is the solution. Steev made the point that OHCI is not necessary for all dongles, and that the solution can/should come from elsewhere. So if you think it is "too much hassle for too small benefit", nobody said _you_ had to fix it.
OK, doesn't go anywhere. - kernel version - udev version - relevant dmesg snip - relevant part of your kernel .config (if the output is huge, use attachments instead). Reopen once you've provided the requested information needed to diagnose the problem. Your ranting won't fix this bug, and we can't guess.
Closing since devs are not interested in fixing.
(In reply to comment #7) > Closing since devs are not interested in fixing. What are you talking about here? I've asked you for information (twice even), you didn't provide any, so we can't fix something if we don't have any information to diagnose the underlying problem... Calm down, really.
