On Tuesday 12 October 2004 3:16 pm, Russell King wrote: > No - this bug is completely specific to the way the SL811 code is > interacting.
Except in its description; similar bugs have shown up with other HCDs! > The basic sequence of events is: > > 1. receive interrupt for insertion/removal. trigger bottom half > 2. bottom half starts looking at the insert/remove state, and delays 10ms Shouldn't this just be "kick khubd"? That's usually done with the virtual root hub polling chip registers, not using an IRQ, but I have nothing against using IRQs there instead. > 3. bh discovers the device speed and enables SOFs > 4. some time later, the USB subsystem issues a reset, which disables SOFs Strictly speaking, speed isn't known until after port reset. Or are you talking about controller reset, not USB reset? There's no real point in sending SOFs that early, though I guess it shouldn't matter either. And a chip reset would be a bad thing on most chips, since it'd reset more root hub ports than the one which needs to be reset. > 5. reset is released 10ms later, and triggers an insert/remove interrupt. > this triggers the bottom half again. > 6. bottom half runs again, and again delays 10ms SOFs have to start within something like 3msec after the reset finishes. What's with punting all this to a BH? > 7. SOFs are re-enabled > > Unfortunately, between steps 5 and 7 is some 10ms delay which is > outside the suspend delay of any peripheral device I have here. > So, the device refuses to accept its address. 10msec could be a task preemption, but such delays should be designed out of existence. > My solution to this - rip out the device speed discovery from the BH > and make it merely trigger the relevant connection change events. Sounds like the right ideas. > Then, intercept the hub control path and handle the reset event > ourself doing everything that the USB spec requires in a linear > progression, from detecting the device speed to issuing and releasing > the reset, to enabling the generation of SOFs. > > This gives 100% reliability for this section of the code, and hey - > it's a hell of a lot more understandable what's actually going on > in there. Is there any problem having khubd do its usual job? There are root hub requests for all the key things: reporting port change events, resetting ports, disabling them, suspending, resuming, retrying, and all that good stuff. > Unfortunately, many other problems appear to remain, including but > not limited to bad scheduling of transfers - I regularly see the > timer handler killing transfers off with bad consequences. I can > generally get devices connected directly to the chip to be > recognised, but anything behind a hub seems a dead loss. Well, that's all outside scope of OHCI, it doesn't have a timer doing anything like that. Software scheduling probably takes a while to get right, especialy with periodic transfers (what you'd use to get status updates from that hub). > Even so, I do wonder whether it would be far better to start from > scratch with a clean design. That's probably not the fastest way to working code, unfortunately. Unless maybe you've already written waaay too many HCDs! - Dave ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
