Brian Buhrow <buhrow%nfbcal.org@localhost> writes: > If I'm using ehci(4) and option DIAGNOSTIC is defined, I get a panic: > "curlen == 0". That's a bug. DIAGNOSTIC should only be checking assertions about invariants that the code always maintains, not user input. So if there is a requirement lower down in the stack that transactions have >0 length, then the parts that validate system calls should check that. > If option DIAGNOSTIC is not defined, then I'm simply unable to write to any > USB devices attached to that bus without a reboot. Generally in a situation where DIAGNOSTIC blows up, bad things happen in the same case without DIAGNOSTIC. > Since the length is 0 in that request, it seems like I should cause > the USB stack to generate a zero-length transaction to the target device. Are you sure that this is well defined in the standard? > I don't think that's happening, but I'm not entirely certain as yet. > The panics as described above and the inability to write to the bus after > such requests on the ehci(4) controlled busses are definitely true, but, > again, I may be trying to do this the wrong way. Is there another way I > should be trying to generate such transactions on the USB bus? It would seem you need to work on the driver... Nick: perhaps not in this thread, but a summary to tech-kern of where you are in your usb work and your roadmap to merging would be nice. (I am generally interested in USB3 working, and keeping the USRP stuff working. I have not been actively working on USB since the read-ahead/write-behind code back in 2006ish.)
Attachment:
signature.asc
Description: PGP signature