The following reply was made to PR kern/34070; it has been noted by GNATS.

From: Matthias Drochner <M.Drochner@fz-juelich.de>
To: Iain Hibbert <plunky@rya-online.net>
Cc: Matthias Drochner <M.Drochner@fz-juelich.de>,
	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 18:09:10 +0100

 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...
 
 best regards
 Matthias