On Saturday 08 January 2005 10:36 am, Larry Schiefer wrote: > > BTW, while working for this particular customer I did find a problem in > the 2.4 EHCI code that was particular to the MIPS platform (which is > what my customer is using.) In the structure ehci_qh, there is an > atomic reference counter, refcount.
While in 2.6 there's a "kref", wrapping an atomic_t. So it's not a 2.4-only thing. > This structure gets allocated from > uncached memory set aside for the PCI bus. Strictly speaking, only part of the EHCI QH (and QTD) stuff _needs_ to be dma-coherent (== uncached on many non-PC platforms, like yours). Combining both parts made for much simpler driver code, albeit at a slight performance cost on some systems ... and yours is the first report of a situation where that makes any trouble. > The snag is that the MIPS > does not implement a test and set instruction and instead relies on a > specialized set of instructions to detect potential memory conflicts > during the attempt for an atomic operation. These instructions are > repeatedly run in a tight loop until there is no conflict and the > operation succeeds. These instructions rely on the atomic operation > being done on cached memory space. The behavior in uncached space is > undefined. Some processor's MIPS implementations allow it to always > succeed in uncached space (obviously a bad thing) and some fail the > operation in uncached space (which is what the core I was using does.) Hmm ... the classic solution would be protect such data with a spinlock, which I see is the default for (older?) CPUs without MIPS_CPU_LLSC. > When I encountered this problem, the machine would get stuck in the > atomic operation loop the first time one of the ehci_qh instructions was > used and the EHCI driver attempted to bump the refcount. I do have a > workaround using a cached memory pool in the driver and changing > refcount to be a pointer to refcount, if anyone is interested. Hmm, I'm not sure what a clean all-arch fix should be. Splitting the QH into two parts (dma-coherent, cacheable) seems like it'd be the most generic solution, but it'd cost (extra allocations to manage) on common hardware; your workaround is a variant of that more general approach. Alternatively, special-casing that refcounting to use a static spinlock would seem to be the least-cost fix on 2.4, where that's not wrapped in a kref. That'd be specific to ehci-mem.c and invisible elsewhere. What I'd like to see is a nice clean fix for 2.6 ... but posting some MIPS workaround for 2.4 would be a good thing in any case, archiving it so other folk can get some solution. - Dave > > Best Regards, > Larry > > On Sat, 2005-01-08 at 12:18, David Brownell wrote: > > On Saturday 08 January 2005 7:45 am, Larry Schiefer wrote: > > > > > 2. Is there something in the scatter-gather change that restricts it > > > from being back-ported to the 2.4 kernel? > > > > The main thing I'd worry about with respect to calling usb_sg_*() is > > that for 2.4 HCDs the URB queueing isn't trustworthy ... though I > > suspect EHCI handles them mostly OK for bulk transfers (even though > > that HCD is out of sync with 2.6), and maybe one of the UHCIs behaves > > by now. (Some folk report problems with queuing in recent OHCI code; > > but it was solid back in 2.4.12 or so when I tested all those USB 1.x > > HCDs.) Regardless, I've never advised relying on URB queueing with 2.4 > > kernels, and I don't know of any device drivers that rely on it to work. > > > > There'd also be usb-storage changes. The usb_sg_*() calls were > > relatively straightforward as I recall; but there were more > > subtle changes related to fault handling and drive-specific > > handling. Some drive adapters don't seem to like being driven > > very near the wire rates. > > > > - Dave > > > > > > > -- > ___________________________________ > Larry Schiefer > Senior Software Engineer > Intelligraphics, Inc. > (214)618-3006 > GPG Public Key: AEE81CEE > [EMAIL PROTECTED] > http://www.intelligraphics.com > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > [email protected] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
