David, Thanks for the additional input.
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. This structure gets allocated from uncached memory set aside for the PCI bus. 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.) 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. 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
