On Fri, 22 Jul 2016, Bruce Korb wrote: > HI, > > On Fri, Jul 22, 2016 at 12:57 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > They come from the xHCI hardware. > > I'd suggest a comment referencing the spec then :) Don't be silly. Nobody could possibly understand the code without reading the spec first. There's no need to mention the spec in a comment; it's an obvious prerequisite. > > /* Completion Code - only applicable for some types of TRBs */ > > #define COMP_CODE_MASK (0xff << 24) > > #define GET_COMP_CODE(p) (((p) & COMP_CODE_MASK) >> 24) > > > No thread handles the command; it is handled by the xHCI hardware. > > That explains the obscurity. :( > > > Clearly, in your case the computation is done wrongly. But it's not so > > easy to tell why or to know how to fix the problem. > > Only Gigabyte knows for sure. No, only the designer of the xHCI controller that Gigabyte uses in the chipset knows for sure. > Can a firmware update fix it, or is > it permanently burned into the controller chips? I will ask 'em and > hold my breath for an answer. I doubt that a firmware update would have any affect, but that's just a guess. > > What happened with the iommu workaround? > > Nothing I have tried has been successful. Enabled or disabled with > GRUB_CMDLINE_LINUX setting for iommu set to "pt" or "soft" (or > omitted all together) yielding 6 alternates with the same results: > "Nope. Not going to do it." > > I guess I could cripple my OS and run 32 bit, but that might waste > some of my 32GB of RAM. Naw. That ain't happening. Maybe > it's time for another mother board. It's 4 years old, but there's still > plenty of power with 8-3.5GHz threads and 32GB of DDR3-1600. Have you tried running a 32-bit kernel to see if it works? If it does, maybe that's a clue that the high-order part of some address register isn't getting set properly. But I have no idea where in the driver to start looking. The xhci-hcd maintainer might be able to help, but he's currently on vacation for several weeks. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
