Back on March 11, I wrote here about the problems I was having with a new
Anker[tm] 2-port USB 3.0 PCIe card.  After Hans Petter Selasky kindly
responded, I believed that I had isolated the problem to just one specific
pairing of a specific device and my specific card.  Well, it seems now that
I was utterly wrong.  (I have only just now realized this because since
the 11th, I have been working on other things and haven't even touched
any of the USB 3.0 stuff... at least not in conjunction with FreeBSD.)

Anyway, the problem is back now, and with a vengence.  In fact now, it is
causing kernel freezes.  (This is exceptionally serious in my book.)

The problem is what it was before... the Anker[tm] card, together with the
9.1-RELEASE xhci driver, is refusing to properly connect a USB mass storage
type device that has been plugged into the card.  I have now reproduced this
problem multiple times, both with external (non-powered) USB 3.0 drive
enclosures (2 x Patriot Gauntlet2) and also even with a USB 3.0 flash
thumb drive I have here (ADATA S102 16GB).

It appears that once the drive+card gets into a mode (mood?) where it no
longer wants to properly recognize any newly inserted USB mass storage
type device it will, after that point in time, refuse to properly
recognize _any_ USB mass storage device (3.0 or 2.0) that is plugged
into the Anker card after that time.

So far, this problem only seems to occur when I plug something in to the
Anker card _after_ boot time.  But since the problem appears to be somewhat
random... sometimes failing, sometimes not... I cannot tell for sure if
pre-boot-time versus post-boot-time device insertion is making any real
difference to the problem.

After boot time, about 50% of the time when I plug a device... apparently
_any_ device... into the Anker card, I will get messages like the following
in my /var/log/messages file:

...
Mar 18 13:36:44 segfault kernel: xhci_do_command: Command timeout!
Mar 18 13:36:44 segfault kernel: usb_alloc_device: set address 3 failed 
(USB_ERR_TIMEOUT, ignored)
Mar 18 13:36:44 segfault kernel: xhci_do_command: Command timeout!
Mar 18 13:36:58 segfault last message repeated 47 times
Mar 18 13:36:58 segfault kernel: usbd_req_re_enumerate: addr=3, set address 
failed! (USB_ERR_TIMEOUT, ignored)
Mar 18 13:36:59 segfault kernel: xhci_do_command: Command timeout!
Mar 18 13:37:12 segfault last message repeated 41 times
Mar 18 13:37:12 segfault kernel: usbd_req_re_enumerate: addr=3, set address 
failed! (USB_ERR_TIMEOUT, ignored)
Mar 18 13:37:14 segfault kernel: xhci_do_command: Command timeout!
Mar 18 13:37:25 segfault last message repeated 39 times
Mar 18 13:37:25 segfault kernel: ugen0.3: <Unknown> at usbus0 (disconnected)
Mar 18 13:37:25 segfault kernel: xhci_do_command: Command timeout!
Mar 18 13:37:25 segfault kernel: uhub_reattach_port: could not allocate new 
device
Mar 18 13:37:26 segfault kernel: xhci_do_command: Command timeout!
...


In all cases where the set of /var/log/messages messages is exactly like
what is shown above, after the final messages of the sequence (see above)
the little blue power light on my Gauntlet2 box goes out and at that point
the kernel absolutely freezes... there is no longer any response from key-
board or mouse input, and the system in question then and henceforth
refuses to respond even to pings from elsewhere on the same networtk.

I have now seen these kernel freezes several times.  They can and do happen
regardless of whether or not X is running at the time.

These kernel freezes are unambiguously linked to the physical act of me
plugging in a device to the Anker card... they always happen very shortly
thereafter, and only and immediately after the exact sequence of messages
shown above are written to /var/log/messages.

For the record, the card+driver is/are malfunctioning... specifically not
completing the attach of a newly inserted mass storage device... regardless
of whether the device just inserted is an external hard drive or an external
flash drive, however I have only seen the kernel freezes occur when the
device just inserted was an external (self-powered) hard drive.

In due course, I will of course file appropriate formal PRs for these USB
problems, however for now I am more focused on just getting these bloody
things working.  (I have already invested a fair amount of time and effort
into this "little" project and I have nothing to show for it, other than
some personal aggravation.)

So anyway, for right now I just want to debug these problems, if possible,
and get this equipment working properly.  Along those lines, I have a few
questions:

1)  What is the best way to debug this?  I have seen HPS suggest to others
with USB problems that they either (a) use the usbdump(8) command to get
more info about the problems or else (b) compile and install a new kernel
in which the option USB_DEBUG has been defined.  Which should I do, and
how may I interpret the results in either case?

2)  What are the command timeouts set to in the XHCI driver and how can I
    increase them?  (Perhaps my card is just barely meeting the published
    USB standard timing specs, and just need a tiny bit more time?)

3)  What exactly is "hw.usb.no_cs_fail" ?

4)  What exactly is "hw.usb.u3g.debug" ?

5)  What exactly is "diveration" ?


Regards,
rfg
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to