From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] urb timeout with bluetooth USB HCI on ARM (2.6.11-rc3)
Date: Mon, 21 Feb 2005 23:45:26 +0100 [thread overview]
Message-ID: <1109025926.7626.2.camel@pegasus> (raw)
In-Reply-To: <7d01f9f00502210904ac37fae@mail.gmail.com>
Hi Tia,
> I'm writing to that list as my last resort in trying to fix a bug i'm
> facing. First of all let me say that this bug looks rather intricate
> to me, that I'm not certain that USB HCI is at fault (though I suspect
> it is, see detail below), and that I've spent a fair amount of time
> digging into code and documentation trying to find out what's going
> wrong. Apologies for the lengthy mail either.
>
> I'm using 2.6.11-rc3 + AT91RM9200 patches, cross-compiled with gcc 3.3.3.
>
> The issue happens when I try to use a bluetooth USB dongle on an ARM
> demo board: I can configure it, but I can't create any connection nor
> scan the local network (with 'hcitool'), for I take urb timeout errors
> when doing so.
>
> Here's a sample of the system logs when the bug happens (with both
> OHCI verbose debug and HCI USB verbose debug enabled):
>
> Jan 1 01:01:17 ptx-ek kernel: hci_usb_tx_process: hci0
> Jan 1 01:01:17 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: RET
> c03eaa78 dev=2 ep=1in-intr flags=0 len=6/16 stat=0
> Jan 1 01:01:17 ptx-ek kernel: drivers/usb/host/ohci-dbg.c:
> data(6/16): 0e 04 01 16 0c 00 stat:0
> Jan 1 01:01:17 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eaa78
> type 4 status 0 count 6 flags 0
> Jan 1 01:01:17 ptx-ek kernel: __recv_frame: hci0 type 4 data c1c28f84 count 6
> Jan 1 01:01:17 ptx-ek kernel: __recv_frame: new packet len 6
> Jan 1 01:01:17 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: SUB
> c03eaa78 dev=2 ep=1in-intr flags=0 len=0/16 stat=-115
> Jan 1 01:01:17 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eaa78
> type 4 resubmit status 0
> Jan 1 01:01:17 ptx-ek kernel: at91rm9200-ohci at91rm9200-ohci: urb
> c03eab04 path 2 ep2in 5c160000 cc 5 --> status -110
> Jan 1 01:01:18 ptx-ek kernel: at91rm9200-ohci at91rm9200-ohci: urb c03eab04 td
> ffc070c0 (1) cc 5, len=0/1028
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: RET
> c03eab04 dev=2 ep=2in-bulk flags=0 len=0/1028 stat=-110
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c:
> data(0/1028): stat:-110
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eab04
> type 2 status -110 count 0 flags 0
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: SUB
> c03eab04 dev=2 ep=2in-bulk flags=0 len=0/1028 stat=-115
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eab04
> type 2 resubmit status 0
> Jan 1 01:01:18 ptx-ek kernel: at91rm9200-ohci at91rm9200-ohci: urb
> c03eab04 path 2 ep2in 5c160000 cc 5 --> status -110
> Jan 1 01:01:18 ptx-ek kernel: at91rm9200-ohci at91rm9200-ohci: urb c03eab04 td
> ffc07100 (1) cc 5, len=0/1028
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: RET
> c03eab04 dev=2 ep=2in-bulk flags=0 len=0/1028 stat=-110
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c:
> data(0/1028): stat:-110
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eab04
> type 2 status -110 count 0 flags 0
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: SUB
> c03eab04 dev=2 ep=2in-bulk flags=0 len=0/1028 stat=-115
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_rx_complete: hci0 urb c03eab04
> type 2 resubmit status 0
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_send_frame: hci0 type 1 len 4
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_tx_process: hci0
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_send_ctrl: hci0 skb c030ae94 len 4
> Jan 1 01:01:18 ptx-ek kernel: __tx_submit: hci0 urb c15708d4 type 1
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: SUB
> c15708d4 dev=2 ep=0out-ctrl flags=0 len=0/4 stat=-115
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: setup(8):
> 20 00 00 00 00 00 04 00
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: data(0/4): 1a 0c 01
> 03 stat:-115
> Jan 1 01:01:18 ptx-ek kernel: drivers/usb/host/ohci-dbg.c: RET
> c15708d4 dev=2 ep=0out-ctrl flags=0 len=4/4 stat=0
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_tx_complete: hci0 urb c15708d4
> status 0 flags 0
> Jan 1 01:01:18 ptx-ek kernel: hci_usb_tx_process: hci0
>
>
> As one can see, at some point when processing received frames, a
> timeout occurs ("status = -110") on endpoint 2 IN (bulk endpoint). The
> faulty endpoint is always the same, and that fact, plus the fact that
> it is OHCI complaining, first led me to think it was an OHCI bug.
>
> I have posted to the linux-usb-devel mailing list for about that:
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110839632914184&w=2
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110872463928902&w=2
>
> but the answer I got pointed me toward either a hardware bug from the
> device (dismissed as it works fine on a x86 machine and the bug is
> reproducible with various dongles) or *maybe* a bug in the BT HCI USB
> driver.
>
> Besides, of all the devices I've been able to test on that machine
> (mice, hubs, mass storage, usbnet...), BT dongles are the *only ones
> failing*, hence my suspecting that the HCI driver is the culprit
> somehow.
>
> Back to the log I've pasted: I've looked at the hci_usb_rx_complete()
> code, and as the log shows, when the timeout is caught, the urb is
> resubmitted and (as it seems) finaly accepted by the USB subsystem
> ("resubmit status 0"). However, hcitool will timeout anyway:
>
> # hcitool scan
> Scanning ...
> Inquiry failed: Connection timed out
>
> I also noticed that "count" remains null for all the fauly urbs, which
> surprised me a bit (wouldn't it grow if data is processed?).
>
> So my questions are:
>
> 1) Is that a known bug? (who knows... :-) )
not that I know of.
> 2) Is it possible that I'm hitting some corner case bug in the HCI driver?
Yes, this is maybe possible. The hci_usb driver is not the cleanest one,
but it works quite good for almost every system at the moment.
> 3) Any clue about how to fix this?
The hci_usb driver contains some extra parameters that may can help you.
Try "isoc=0" or "reset=1" and post the content of /proc/bus/usb/devices.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2005-02-21 22:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-21 17:04 [Bluez-devel] urb timeout with bluetooth USB HCI on ARM (2.6.11-rc3) Thibaut VARENE
2005-02-21 22:45 ` Marcel Holtmann [this message]
2005-02-22 12:31 ` [Bluez-devel] " Thibaut VARENE
2005-02-24 10:40 ` Marcel Holtmann
2005-02-22 12:41 ` Thibaut VARENE
2005-02-24 10:38 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1109025926.7626.2.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.