On Fri, 22 Jul 2016, Bruce Korb wrote: > A few questions: > > 1. Where do the values for TRB completion codes come from? > COMP_BW_ERR and COMP_2ND_BW_ERR seem to be defined > and then only used in a switch statement. They come from the xHCI hardware. > 2. xhci_queue_configure_endpoint() seems to be the function for > sending down a command that somehow loads the "BW_ERR" > code into command->status asynchronously. What thread > handles the command dispatch after queue_command() has > queued it? Finding it seems a little obscure. No thread handles the command; it is handled by the xHCI hardware. > I want to look into two things: > > How is bandwidth computed? The computation is done by the xHCI hardware in an unspecified, vendor-specific way. > Is it possible that a USB3 hub's capacity > is interpreted as its bandwidth requirement and that devices plugged into > it then _augment_ required bandwidth instead of reducing available hub > capacity? I don't know what you mean by "capacity". In any case, we don't know how the xHCI hardware does its bandwidth computations. 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. > Secondly, if that is too hard to figure out, then, yes, I want to disable the > bandwidth limitations for my computer. Not a general solution, but at this > point, whatever works, works. You can't eliminate them; there's no way to do it. What happened with the iommu workaround? 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
