> > With some experimentation I found that the bug is a variant of the > > old "stop after restart" issue - the doorbell ring is internally > > reordered after the subsequent command. By busy-waiting I confirmed > > that EP state which is initially seen as Stopped becomes Running > > some time later. > > Seems host controllers aren't designed to stop, move dequeue, and > restart an endpoint in quick succession. As it was you who added the Running case handling, do you know hardware other than NEC which triggers this? Or could it be just a single vendor who screwed up once 15 years ago and caused all the chaos? NEC sometimes triggers the Running case too and it is obvious why. I'm not sure how I missed it back in January and assumed it's some sort of random failure for no reason. BTW, the NEC problem appears to be limited to periodic endpoints. I am unable to reproduce it on bulk. I thought that I reproduced it on bulk back then, but on second thought it may have been interrupt, which that device also has. Unfortunatel I wasn't printing endpoint numbers then. Regards, Michal
