Let me tell you a little story….
For the last four years I have done the bulk of my development on a Macbook Pro running Linux. I generally like Mac laptops and find them to be well built. That said, I’ve had the internal SATA cable go bad *three* times in the last four years, which you could argue contradicts the previous sentence.
[lightbox title=”20150306_155252″ href=”http://www.kernellabs.com/blog/wp-content/uploads/2015/03/20150306_155252.jpg”]
[/lightbox]
The problem manifests as SATA errors in the dmesg log, which normally puts me in a panic as to whether the drive has gone bad, whether I’ve lost data, and how good are my backups. A trip to the Apple store, $55 later, and a “Genius” replaces the cable for me in ten minutes and all is well with the world again (with no actual data loss).
Now if you were the person who signs my expense reports, you might be inclined to ask:
Didn’t the company buy you a brand new Retina Macbook Pro in December?
Well, yes it did. And in fact I loaded up the latest version of Ubuntu on it and was pleasantly surprised that it worked out-of-the box (after installing the binary Broadcom drivers for the Wifi, that is). However I ran into a little problem..
You see, aside from all the random embedded platforms I do work on, I also happen to do quite a bit of work maintaining the Linux driver for the HVR-950q. This usually involves debugging tuning problems, power issues, and other random edge cases. So after setting up the new Macbook, plugging in the HVR-950q and starting up tvtime, I was a little surprised to see this:
xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Followed by every USB device connected to the bus being killed (including my mouse and keyboard). Ouch.
While we operate under the assumption that legacy USB 2.0 devices should behave in a backward compatible manner when connected to USB 3.0 ports, the truth is that we’re at the mercy of how stable/reliable the underlying XHCI host controller implementation is. And while I’m certainly not disparaging the hard work the USB subsystem maintainers have put into the XHCI driver, it doesn’t change the fact that I’ve found no less than three separate bugs in the XHCI stack which result in a kernel OOPS, a kernel PANIC, or devices being disconnected from the bus.
The reason I’m bringing this up is because I have a number of commercial clients using the HVR-950q or other tuners in their embedded design, and motherboards that *don’t* have USB 3.0 ports are becoming increasingly rare. Clients are quite naturally looking to upgrade their platforms to using the latest commonly available motherboards as existing products go end-of-life, and they assume the tuner should work just like it did in the previous platform.
Be forewarned: If you’re upgrading your motherboard, you should expect the possibility that USB 3.0 ports could have some adverse side-effects on your existing USB 2.0 products connected to them.
In the meantime, I’m working through the USB mailing list to get these issues addressed, but even if they are fixed the patches might only be available in the latest and greatest kernels – a headache commercial customers may encounter if they are already locked into some stable kernel version for unrelated reasons.
I’ve developed some strategies for working around such issues even without having real fixes upstream. If you’re a commercial party who wants to discuss such further, feel free to reach out to sales [ at ] kernellabs.com.
Addendeum: Quick clarification, while the problems I discussed occurred with the HVR-950q, they aren’t specific to the HVR-950q, and I’ve also seen them occur with other tuners.