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 _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"