From owner-freebsd-current Sun Mar 16 12:37:56 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF95937B401 for ; Sun, 16 Mar 2003 12:37:52 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01B5543FA3 for ; Sun, 16 Mar 2003 12:37:47 -0800 (PST) (envelope-from Maksim.Yevmenkin@cw.com) Received: from scl8ex04.int.exodus.net ([10.255.74.246]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Sun, 16 Mar 2003 12:37:46 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: bluetooth BW-BH02U reset failure Date: Sun, 16 Mar 2003 12:37:46 -0800 Message-ID: <790A8B1F40ACA848939EBD247AE490302794F8@scl8ex04.int.exodus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bluetooth BW-BH02U reset failure Thread-Index: AcLrb2maFRRg+8/DQfuChd4Qy7DxqAAh/R4z From: "Maksim Yevmenkin" To: "miniyan" Cc: X-OriginalArrivalTime: 16 Mar 2003 20:37:46.0821 (UTC) FILETIME=[E7364F50:01C2EBFB] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello Takahiko, [...] > OK, I checked my copy of 2003-03-05. It only has sys. I'd download = latest > 2003-03-05 on your directory. I've rebuild environment. good [...] > > > ugen0: Broadcom product 0x2033, rev 1.01/0.a0, addr 2 > >=20 > I just mistake device name, it not BW-BH02U. true name is "GW-BH02U". well, i did some research on that. it turns out Broadcom Bluetooth chip based devices require firmware download. in particular the device you have (Vendor ID 0x0a5c/Product ID 0x2033) uses special procedure to download firmware file, i.e. you have to download mini-driver first and then firmware itself. you can find both = mini-driver and firmware images on the net. also Linux BlueZ stack has bluefw utility that can download firmware into this device. i will need to port this on FreeBSD. however i'm not sure about copyright issues. bottom line: i removed this device from the list of supported devices for now. i will add support for firmware download in the next version of ng_ubt(4) driver. [...] > I tried to get DBT-120M, but I cannot get yet. fortunately, I got > another device. It is HASEGAWA SYS-COM's HNT-UB01. I checked this > device with usbdevs. ng_ubt asked this device is MITSUMI(0x3ee) > BT_DONGLE(0x641f) yes this device should work just fine. > This device is work on my environment(some time failure in "reset", > "initialize" I cannot solved yet why that failure). following message = is > this devices' one. Action is connect -> start -> stop -> disconnect [...] dump this looks fine to me, btw you might want to use hcidump -x next time. > ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) > ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) > ubt_intr_complete: ubt0 - Interrupt xfer failed. IOERROR (13) > ---- 12 time repeats last 3 lines---- > ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) > ubt0: at uhub0 port 2 (addr 2) disconnected > ubt_bulk_in_complete: ubt0 - Bulk-in xfer failed. IOERROR (13) > ----- 19 times repeat last line ---- > ubt0: detached 1) do these errors happen only when you disconnect the device? 2) do you see these errors during the normal activity, i.e. when device is active and you try to send/receive data? 3) is it uhci or ohci USB controller? note you might see these errors when you disconnect the device. i do get them as well. for some reason USB stack does not return CANCELLED status for pending requests right away. instead USB returns IOERROR status. ng_ubt(4) driver tries to re-submit USB transfer, but since device is gone it fails again with the same IOERROR status. now at some point USB stack deliver CANCELLED=20 status for pending request and then everything stops. i'm looking into this right now. perhaps i'm doing something wrong, or perhaps its normal and i just should not log this at all. also you might get the same errors if you just start/stop/start the stack *without* disconnecting device after you stop stack. this is also a known issue and i'm tracking it down. > So back to GW-BT02U, I tried to GW-BT02U again. This device ofcourse > failure with "reset" command. I captured hcidump for this. Action is > same connect -> start -> stop -> disconnect > hcidump log is just follows: [...] > This looks like device not response. I think freebsd should work > because MITSUMI's device work. Then this problem relate BroadCom's > device. What's next steps? device does not respond because you need to download firmware first :( i'm working on this.=20 =20 thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message