Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, 2 Jan 2017, Mathias Nyman wrote: > >> On 30.12.2016 14:01, Felipe Balbi wrote: >> > >> > Hi Mathias, >> > >> > So the problem I found with v4.10-rc1 doesn't appear to be a >> > regression. I can't, however, trigger it with Broadwell, only Skylake >> > and Kabylake. >> > >> > According to tracepoints, our Reset Device Command sometimes completes >> > with "Context State Error", which tells us that we're issuing Reset >> > Device Command when we shouldn't. >> >> This could happen if reset device is issued twice, >> >> xhci reset device command only works for slots in Addressed or >> Configured states. Reset device sets the slot to "Defult" state. > > Doesn't the xHCI hardware automatically assign addresses to devices? > And send a Set-Address request after a reset has completed? > > And doesn't this mean the slot should automatically go from the Default > state to the Addressed state? It should remain in the Default state > only for a brief time, while the Set-Address request is in progress. My copy of xHCI spec says differently. The only thing that moves default from Default to Address is an Address Device command with BSR set to 0. The only situation where we don't see Default State is if we issue Address Device with BSR set to 0 from Enabled state. However, a Reset Device command will put the device in Default State where it should remain until another Address Device command with BSR = 0 is issued. > Unless there's something wrong with the device, and it doesn't accept > the Set-Address request. In which case, usbcore would naturally retry > the reset. Is that what happened here? Doesn't seem to be what's happening here. My Test case is merely a series of resets (started via userland with libusb) to mimic USB CV's 500 enumeration test (which is implemented with a series of USB Resets). I haven't come up with an explanation as to why the device moved from Configured/Addressed back to Default yet. In order to answer that, I have to finish my Slot and Endpoint context tracers which I started writing today. If I were to guess, I'd say that we issued Enable Slot command, then Address Device command (BSR=1), then Reset Device command. This would cause te error above ;-) We should, anyway, apply the other patch I sent [1] (BTW, anybody knows what's wrong with marc.info?? It's not indexing messages anymore), to prevent us from even issuing the command if we're in the wrong state. [1] https://marc.info/?i=20170102123412.9214-1-felipe.balbi@xxxxxxxxxxxxxxx -- balbi -- 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
