On Saturday 18 June 2005 12:26 pm, Matthias Urlichs wrote: > Hi, > > (I don't know if my earlier mail went through, I had a full disk) > > David Brownell: > > But there are some OHCI implementations (OPTi comes to mind, and SiS) > > that won't issue UE ... in /sys/class/usb_host/usbN/registers, there > > No such file exists on my system (2.6.11, mostly). Has that been added > recently, and/or is it available with debugging only? > I couldn't find that string in my kernel tree.
CONFIG_USB_DEBUG enables debug files there for OHCI. > Anyway, of *course* it's an Opti (no wonder that company died...). > Worse, the chip is on a PC-Card, and it's hardwired to an USB-interfaced > GSM 'modem', so there's no way to rip it out and test with something > else. Believe me, I *want* to. :-/ > > I'm also looking at Apple's OPTi fixes, Brave person! > > One way to shake such problems loose earlier is to turn on the slab > > poisoning options (CONFIG_DEBUG_SLAB). > > It's also a good way to prevent the problem from occurring in the first > place. In my case anyway... Interesting. As an experiment, try forcing on OHCI_QUIRK_ZFMICRO ... that will slow certain things down (excessively), maybe that'll make a difference. If slab poisoning prevents the problem from happening there are two basic scenarios. One is that the driver is too fast for the hardware, as with the ZFMICRO case ... old old chips that don't seem to implement the OHCI spec right. A variant of that is the (increasingly unlikely) possibility of a race with the hardware; those are hard to find nowadays. The second scenario is that the pattern being used to poison the memory (probably TDs) just happens to make the hardware happy, hiding another bug. I've seen both cases ... Then there's the the "chip has a real bug" scenario. I have one OPTi card, which has never really misbehaved that rudely for me ... but as I understand things, there are loads I could throw at it that would cause it deep unhappiness. > > I'd avoid such things; if usbcore isn't involved in shutting > > down and restarting the HCDs, it's going to get deeply confused > > and start throwing tantrums. > > So I involve it. Or call the UE interrupt handler myself when that > happens. Easier said than done, unfortunately for you. Somehow the code to gracefully recover from a chip that's crapping out always ends up at the end of the priority list, too. :( > The important part, for me, is to get the system back into a state it > can recover from -- as long as that doesn't involve rebooting, my client > will be reasonably happy. "Flaky hardware", if approximately correct, > is good enough a reason. If you need to chase that "recover from chip that craps out" logic down and make it work, more power to you! - Dave ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
