Subject: Re: kern/34070: btconfig: SIOCSBTFLAGS: Resource temporarily
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Iain Hibbert <plunky@rya-online.net>
List: netbsd-bugs
Date: 11/21/2006 20:15:05
The following reply was made to PR kern/34070; it has been noted by GNATS.

From: Iain Hibbert <plunky@rya-online.net>
To: Matthias Drochner <M.Drochner@fz-juelich.de>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, wulf@NetBSD.org
Subject: Re: kern/34070: btconfig: SIOCSBTFLAGS: Resource temporarily 
 unavailable
Date: Tue, 21 Nov 2006 20:11:10 +0000 (GMT)

 On Tue, 21 Nov 2006, Matthias Drochner wrote:
 
 >
 > plunky@rya-online.net said:
 > > ubt provides an event buffer with the size that is the maximum
 > > Bluetooth event packet size and let the usb stack fill it in
 >
 > This is definitely correct -- the USB spec (ch. 5.7.3) explicitely
 > mentions the case that an interrupt transfer (the term "transfer"
 > is used inconsistently) involves multiple transactions where all
 > but the last have the maximum payload size.
 >
 > > what happens with this patch for instance when doing a 'btconfig -vvvv' ?
 > > eg, the Read_Local_Name response packet in particular is I think 256 bytes..
 >
 > Yep, the device name gets truncated.
 > Using the packet size of 16 at the driver request level is
 > certainly not right. Reassembly should be done by the USB host
 > adapter layer. Remains the question why transfers which consist
 > of one USB packet get through while larger ones don't.
 >
 > > I would say though, that since the uhci code does automatically catenate
 > > USB packets into a single transfer (the bluetooth packet), the ehci code
 > > should do that properly also..
 >
 > As I understand it, the EHCI hardware is supposed to do that automatically.
 > See the description of the "queue head" and the "queue element transfer
 > descriptor" (ch 3.6/3.5) in the EHCI spec.
 > It might be that the desciptors are not filled in correctly, or that
 > there is a bug in interrupt handling which makes that the response
 > is ignored, or something with the data toggle handshake, or with
 > the translation...
 
 I'm looking at the FreeBSD CVS log for ehci.c and I see this commit
 mentioned:
 
   Revision 1.30 / (download) - annotate - [select for diffs], Tue Mar 8
   02:47:18 2005 UTC (20 months, 2 weeks ago) by iedowse
   Branch: MAIN
   Changes since 1.29: +3 -5 lines
   Diff to previous 1.29 (colored)
 
   Fix the silly bug that prevented most EHCI interrupt transfers from
   ever working correctly: the code was linking the QHs together but
   then immediately overwriting the "next" pointers. Oops. Also
   initialise qh_endphub, since the EHCI spec says that we should
   always set the pipe multiplier field to something sensible.
 
   This appears to make basic split transactions work, so enable split
   transactions for control, bulk and interrupt pipes (split isochronous
   transfers are not yet implemented). It should now be possible to
   use USB1 devices even when they are connected through a USB2 hub.
 
 So, I'm not really sure that this is relevant but it sounds plausible.
 From their diff below, I see that the removal of "sqh->next = NULL" has
 not happened on NetBSD and I wonder if this can be the problem? The
 comment at least does apply as next has previously been set..
 
 iain
 
 ===================================================================
 RCS file: /usr/local/www/cvsroot/FreeBSD/src/sys/dev/usb/ehci.c,v
 retrieving revision 1.29
 retrieving revision 1.30
 diff -u -p -r1.29 -r1.30
 --- src/sys/dev/usb/ehci.c	2005/01/09 23:49:45	1.29
 +++ src/sys/dev/usb/ehci.c	2005/03/08 02:47:18	1.30
 @@ -65,7 +65,7 @@
  */
 
  #include <sys/cdefs.h>
 -__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/dev/usb/ehci.c,v 1.29 2005/01/09 23:49:45 julian Exp $");
 +__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/dev/usb/ehci.c,v 1.30 2005/03/08 02:47:18 iedowse Exp $");
 
  #include <sys/param.h>
  #include <sys/systm.h>
 @@ -451,9 +451,8 @@ ehci_init(ehci_softc_t *sc)
  			    EHCI_LINK_QH);
  		}
  		sqh->qh.qh_endp = htole32(EHCI_QH_SET_EPS(EHCI_QH_SPEED_HIGH));
 -		sqh->qh.qh_link = EHCI_NULL;
 +		sqh->qh.qh_endphub = htole32(EHCI_QH_SET_MULT(1));
  		sqh->qh.qh_curqtd = EHCI_NULL;
 -		sqh->next = NULL;
  		sqh->qh.qh_qtd.qtd_next = EHCI_NULL;
  		sqh->qh.qh_qtd.qtd_altnext = EHCI_NULL;
  		sqh->qh.qh_qtd.qtd_status = htole32(EHCI_QTD_HALTED);
 @@ -1408,14 +1407,13 @@ ehci_open(usbd_pipe_handle pipe)
  	case USB_SPEED_HIGH: speed = EHCI_QH_SPEED_HIGH; break;
  	default: panic("ehci_open: bad device speed %d", dev->speed);
  	}
 -	if (speed != EHCI_QH_SPEED_HIGH) {
 +	if (speed != EHCI_QH_SPEED_HIGH && xfertype == UE_ISOCHRONOUS) {
  		printf("%s: *** WARNING: opening low/full speed device, this "
  		       "does not work yet.\n",
  		       USBDEVNAME(sc->sc_bus.bdev));
  		DPRINTFN(1,("ehci_open: hshubaddr=%d hshubport=%d\n",
  			    hshubaddr, hshubport));
 -		if (xfertype != UE_CONTROL)
 -			return USBD_INVAL;
 +		return USBD_INVAL;
  	}
 
  	naks = 8;		/* XXX */