On Sat, 19 Jun 2004, Adam Koh wrote: > Confirmed here too - it works without debugging using that patch, but > the kernel CPU time is pegged high whenever the drive is being accessed. > I'm guessing this is because yield() won't really yield unless other > threads are being scheduled...?
I think you're right and we'll end up using udelay(). On Sun, 20 Jun 2004, Jacques Grove wrote: > Anyway, I've succeeded in making it lock up even with the patch. I had > to punish the drive/interface rather severely with multiple iozone tests > up to 4 GB filesizes. It eventually locked up after I probably had > transfered well over 600 GB to/from the drive. Same thing as before, light goes > on red solid. > > However, it's good enough for my purposes now, whereas before it was > completely useless. Presumably what really matters is the delay between the completion of the preceding CSW and the start of the next CBW. It's easy enough to account for that, if we need to. But I'm afraid that the total delay time required will vary depending on the type of drive installed in the USB-IDE enclosure and the length of the preceding I/O operation. Maybe we shouldn't worry about it; if using a fixed 250 or 300 microsecond delay will make the drives 99% reliable instead of their current 10%, that's a pretty big improvement. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
