HI,
On Fri, Jul 22, 2016 at 12:57 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> They come from the xHCI hardware.
I'd suggest a comment referencing the spec then :)
> /* 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. 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
