On Tue, 11 Jul 2006, Berndt Josef Wulf wrote:

> uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> ubt0: Dell TrueMobile 350 Bluetooth USB Adapter, rev 2.00/24.22, addr 3
>
> Any suggestions?

Well, this error origniates from a tsleep() in sys/netbt/hci_unit.c after
the device is enabled while we wait for it to reset and initialise. You
could try increasing the timeout with the patch below..

--- /usr/src/sys/netbt/hci_unit.c	2006-06-19 16:44:45.000000000 +0100
+++ hci_unit.c	2006-06-28 16:08:23.000000000 +0100
@@ -144,7 +144,7 @@
 		goto bad2;

 	while (unit->hci_flags & BTF_INIT) {
-		err = tsleep(unit, PWAIT | PCATCH, __func__, hz);
+		err = tsleep(unit, PWAIT | PCATCH, __func__, 5 * hz);
 		if (err)
 			goto bad2;


..but actually I wonder if this may be caused by the absence of
isochronous transfer support in the ehci(4) driver - was the older laptop
a different USB controller?

Did you have a hw.ubt0.config sysctl set? This is for configuring the
isochronous endpoints and although there is no way to turn that
configuration off, it may make a difference if you leave it at zero.

I'm not sure what issues could arise if a driver tries to configure
isochronous endpoints through the ehci(4) driver (there seemed to be no
errors printed, either by ubt or by ehci), but they would normally only be
used for audio data with the bthset(4) driver and it would be nice if the
rest of it worked. There is nothing that btconfig(8) does that would
require isoc endpoints to be configured, and if using config#0 makes no
difference, you could try commenting out the function call that tries to
set it up, like so..?

--- /usr/src/sys/dev/usb/ubt.c	2006-06-19 22:24:19.000000000 +0100
+++ /usr/src/sys/dev/usb/ubt.c	2006-07-11 20:17:01.000000000 +0100
@@ -427,6 +427,7 @@
 	sc->sc_iface1 = iface;
 	uaa->ifaces[1] = NULL;

+/*
 	/* set initial config */
 	err = ubt_set_isoc_config(sc);
 	if (err) {
@@ -435,6 +436,7 @@

 		USB_ATTACH_ERROR_RETURN;
 	}
+*/

 	/* Attach HCI */
 	sc->sc_unit.hci_softc = sc;


iain