Hm, is this a problem with our usb3 stack itself?

If you send me a pull request against ath3k I'll merge it into my git tree
just for completeness.

Maybe we need to loop in hps@ with a bunch of usbdump output to see what
the transactions look like...



-adrian


On Sat, 13 Apr 2019 at 07:21, Alexey Dokuchaev <da...@freebsd.org> wrote:

> On Fri, Apr 12, 2019 at 05:12:18PM +0000, Alexey Dokuchaev wrote:
> > I've then rebooted back into FreeBSD.  Apparently, this AR3012 hardware
> > is very fragile, it can be easily left in confused state and won't accept
> > further commands, "usbconfig reset" does not help.  To avoid this, it is
> > better run ./ath3kfw as root, after powercycling machine (to reset the
> > card).  This got me further:
> >
> > ath3kfw: opening dev 2.2
> > main: state=0x0e
> > ROM version: 285343744, build version: 155, ram version: 155, ref clock=1
> > ath3k_init_firmware: loading ath3k-1.fw
> > ath3k_load_fwfile:
> file=/home/danfe/ath3k/share/firmware/ath3k/ath3k-1.fw,
> > size=246804
> > ath3k_load_fwfile: transferring 20 bytes, offset 4096
>
> Looks like there is a bug with the logging, consider this pseudo-patch:
>
> @@ ...
>         ath3k_debug("%s: transferring %d bytes, offset %d\n",
>             __func__,
> -           sent,
> -           size);
> +           size, sent);
>
> > ...
> > ath3k_load_fwfile: transferring 65556 bytes, offset 4096
> > LIBUSB_FUNCTION: libusb_bulk_transfer enter
> > LIBUSB_FUNCTION: libusb_submit_transfer enter
> > LIBUSB_FUNCTION: libusb_submit_transfer leave 0
> > LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
> > LIBUSB_FUNCTION: libusb10_handle_events_sub enter
> > LIBUSB_TRANSFER: sync I/O done
> > LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
> > LIBUSB_FUNCTION: libusb_bulk_transfer leave
> > Can't load firmware: err=Timeout, size=4096
> > ath3k_load_fwfile: transferring 65556 bytes, offset 4096
>
> I've found seemingly related bug report about Atheros BT devices (ath3k)
> failing to work on USB 3.0 buses, while working well on USB 2.0:
>
>     https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400215
>
> In 2015, a work-around for this problem was committed* to Linux kernel:
>
> author  Adam Lee <adam....@canonical.com>       2015-01-28
> committer       Marcel Holtmann <mar...@holtmann.org>   2015-01-29
> commit  c561a5753dd631920c4459a067d22679b3d110d6
>
>   Bluetooth: ath3k: workaround the compatibility issue with xHCI controller
>
>   ath3k devices fail to load firmwares on xHCI buses, but work well on
>   EHCI, this might be a compatibility issue between xHCI and ath3k chips.
>   As my testing result, those chips will work on xHCI buses again with
>   this patch.
>
>   This workaround is from Qualcomm, they also did some workarounds in
>   Windows driver.
>
> I've patched ath3kfw tool in a similar way like this:
>
> +#define TIMEGAP_USEC_MIN 50
> +#define TIMEGAP_USEC_MAX 100
> +
> +static inline void
> +usleep_range(unsigned long min, unsigned long max)
> +{
> +    usleep(min); // or usleep(max);
> +}
>      ...
>
>      while (count) {
> +        /* workaround the compatibility issue with xHCI controller */
> +        usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
>
> Unfortunately, this hack didn't help, neither with usleep(min) nor with
> usleep(max).  Error message is the same "Can't load firmware: err=Timeout,
> size=4096".
>
> I will try to find a USB 2.0-only laptop which supports mini-PCIe cards
> to get more data points, but not sure if I can find one easily.  It would
> be nice if someone who has pre-xHCI hardware could conduct this test.
>
> ./danfe
>
> *)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/ath3k.c?id=c561a5753dd631920c4459a067d22679b3d110d6
> _______________________________________________
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org
> "
>
_______________________________________________
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to