Re: USB.Bluetooth not recognized at boot-time

From: Enrique Perez-Terron (enrio_at_online.no)
Date: 10/30/05 

Date: Sun, 30 Oct 2005 19:31:06 +0100

On Sun, 30 Oct 2005 17:35:12 +0100, Martin Gerken <m_gerken@yahoo.com> wrote:

> On Sun, 30 Oct 2005 16:01:35 +0100, "Enrique Perez-Terron"
> <enrio@online.no> wrote:
>
>>>>>>> my new super-budged-made-in-china Bluetooth-Stick works fine - but it is
>>>>>>> only recognized when I plug it into USB when the system is running. It
>>>>>>> is not recognized when it is plugged in at boot-time.
>>>>>>> (Debian Sarge & Bluez used)
>
>>> I found some hint here:
>>> http://sourceforge.net/mailarchive/message.php?msg_id=9106268
>>> Frankly, I don't know how to apply the mentioned fix - and as the hint
>>> is pretty old and I have used apt-get to get the latest bluez-utils I'm
>>> not even shure if it helps.
>>
>> What kernel are you running? The patch in the link is already in my
>> kernel sources, both 2.6.12 and 2.6.13 have it.
>
> Debian 2.6.8-2-386
> (I'm about to compile the latest 2.6.14 but I'm quite afraid to break
> somethink)
>
>> But I don't know yet if this is what makes it work once you plug the
>> thing out and back in, versus not work at all. The context of the
>> patch is to add those three lines (with pluses in the margin) to a list
>> called "blacklist_ids". This list is treated especially in the probe
>> routine, but I have not yet digged into the details.
>
> Okay, I understand. I've just installed the latest bluez-libs and
> bluez-utils from bluez.org but still no progress.

What I have seen so far is that the file hci_usb.c defines two lists
of devices. One is used with a macro, MODULE_DEVICE_TABLE, which, as
I understand it, will help determine what modules to load when a device
is discovered on the bus, and the other list is this "blacklist_ids".

The two lists seem to have no common elements. This reinforces my
impression that for some reason the kernel hackers have deliberately
excluded the device from the list of devices that load the module.

However, once the module is loaded by other means (by the hotplug event
system) the module's probe routine is called with all driverless
devices, and then the probe routine looks it up in the blacklist_ids.

>> Something that looks confusing here is that you have the bluetooth
>> module loaded even when it does not work. Do you have any idea about
>> what ntriggers the loading of that module? Can you find something related
>> in dmesg? If you do, it would be nice to see some of what happens before
>> and after, to get an idea of the context that triggers the loading.

I have now seen that the "bluetooth" module is a network protocol stack
module, not a device driver. I don't know yet what are the mechanisms
that trigger loading this module, but it will not (or unlikely) be the
discovery of a device on a bus.

> my dmesg (relevant parts):
>
> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> USB Universal Host Controller Interface driver v2.2
> ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 3 (level, low) -> IRQ 3
> uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller
> uhci_hcd 0000:00:11.2: irq 3, io base 0000d400
> uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 3 (level, low) -> IRQ 3
> uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (#2)
> uhci_hcd 0000:00:11.3: irq 3, io base 0000d800
> uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> usb 1-2: new full speed USB device using address 2
> usb 1-2: device not accepting address 2, error -71

Arghh! I have seen this before. A few weeks ago I bought an mp3 player
with an USB interface. This player works wonderfully with Windows 2K,
but not at all with Linux. The driver goes in a loop where it offers
the device to have each possible address, and all fail. This is precisely
the real reason I am interested in this case too. I just go so tired of
reading kernel source and understanding nothing, that I put it aside for
two weeks. It is nice to attack again from a different angle, in the
meantime some of what I learned "matures" or something similar.

But I did find that there are quite a few USB firmwares out there that
do not work with Linux, and it seems one has to spy on the Windows
drivers to find out what exactly they do, and mimic it.
> usb 1-2: new full speed USB device using address 3
> usb 1-2: device not accepting address 3, error -71

> [...]
> Bluetooth: Core ver 2.6
> NET: Registered protocol family 31
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> Bluetooth: L2CAP ver 2.3
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: RFCOMM ver 1.3
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM TTY layer initialized
> ra0: no IPv6 routers present
> uhci_hcd 0000:00:11.2: remove, state 1
> usb usb1: USB disconnect, address 1
> uhci_hcd 0000:00:11.2: USB bus 1 deregistered
> uhci_hcd 0000:00:11.3: remove, state 1
> usb usb2: USB disconnect, address 1
> uhci_hcd 0000:00:11.3: USB bus 2 deregistered
> usbcore: deregistering driver usbfs
> usbcore: deregistering driver hub
> pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
> pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
> shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
> shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5

What is this?

> usbcore: registered new driver usbfs
> usbcore: registered new driver hub
> USB Universal Host Controller Interface driver v2.2
> ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 3 (level, low) -> IRQ 3
> uhci_hcd 0000:00:11.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller
> uhci_hcd 0000:00:11.2: irq 3, io base 0000d400
> uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1

Eh? Do you tear out part of the mainboard when you unplug the usb device?

Joking, but I find it strange that it removes support for the usb bus
alltogether, and rediscovers it when you reconnect. Just compare what
I see when I disconnect my USB printer:

Oct 30 18:57:04 apeiron kernel: usb 1-1: USB disconnect, address 61
Oct 30 18:57:04 apeiron kernel: usb 1-1.1: USB disconnect, address 62
Oct 30 18:57:04 apeiron kernel: usb 1-1.2: USB disconnect, address 63
Oct 30 18:57:04 apeiron kernel: drivers/usb/class/usblp.c: usblp0: removed
Oct 30 18:58:06 apeiron kernel: usb 1-1: new full speed USB device using uhci_hcd and address 68
Oct 30 18:58:06 apeiron kernel: hub 1-1:1.0: USB hub found
Oct 30 18:58:06 apeiron kernel: hub 1-1:1.0: 2 ports detected
Oct 30 18:58:06 apeiron kernel: usb 1-1.1: new full speed USB device using uhci_hcd and address 69
Oct 30 18:58:06 apeiron kernel: usb 1-1.2: new full speed USB device using uhci_hcd and address 70
Oct 30 18:58:06 apeiron kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 70 if 0 alt 0 proto 2 vid 0x043D pid 0x0069

Usbcore, uhci_hcd and usbfs remain active, and I still have usb ports on the
rear of the computer. Only the usb hub device inside the printer, the printer,
and the scanner are disconnected, and then the class driver usblp0 is removed.

> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 3 (level, low) -> IRQ 3
> uhci_hcd 0000:00:11.3: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (#2)
> uhci_hcd 0000:00:11.3: irq 3, io base 0000d800
> uhci_hcd 0000:00:11.3: new USB bus registered, assigned bus number 2
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> usb 1-2: new full speed USB device using address 2
> usb 1-2: device not accepting address 2, error -71
> usb 1-2: new full speed USB device using address 3
> usb 1-2: device not accepting address 3, error -71
>
> There is some error message, strange!

Yes, same error. I need to learn more how this part of the
protocol works. Obviously this error does not prevent the driver
 from reading the configuration data (including the vendor/product
ids).

>> What happens if you do "modprobe hci_usb" after booting with the stick
>> installed, without taking it out & back in?
>
> Does not help.

Strange... I have just read that /proc/sys/kernel/hotplug contains the
name of an executable user-space program that the kernel will run when
there is a hotplug event. Command line args and environment variables
will tell the executable what the event is. On my system, the executable
is "/sbin/udevsend", a bash script. I you add a few lines

   {
     date
     echo "$*"
     env
     echo
   } >> /tmp/udevlog

at the start of the script it should be possible to follow the traces
and find out what exactly the hotplug system does to get your device
going (if it's the userspace actions that matters)

> Neither does /etc/init.d/hotplug restart

There is no such animal on my FC4. Perhaps it just installs the
program name in /proc/sys/kernel/hotplug.

-Enrique

Relevant Pages