On Mon, 2 Jan 2017, Felipe Balbi wrote: > 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. [After re-reading the xHCI spec to refresh my memory...] Yes, you're right. > > 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 ;-) During a normal enumeration under the "new" scheme, the hub driver issues a port reset and then invokes the HCD's reset_device and enable_device callbacks (which should leave the device slot in the Default state) in order to read the device descriptor. It then does another port reset. The HCD's reset_device callback for this second reset should _always_ get a Context State Error completion code; I don't know why you don't see this all the time. Of course, if something goes wrong during a device reset then almost anything is possible. There are plenty of error pathways that skip over the address_device callback. > 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 Agreed. The command's name is a little misleading; a Reset Device command does not actually reset the device. Rather, it resets the device's Slot Context. 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
