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 */