On Thu, 17 Jun 2004, Jacques Grove wrote:
> Alan,
>
> RE your post at:
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg23879.html
>
> (Sorry, I didn't feel like going to the hassle to craft a disposable
> email address before posting to the list).
>
> Anyway, I have been experiencing the same problems with a Genesys
> IDE/USB bridge (running 2.6.7-rc3-mm2 here). I seem to be having the
> problems most people see, i.e. the enclosure locks up soon after most
> types of heavy transfers start, with the LED solid red. Only a device
> reset and reloading the modules will save me (sometimes) in this
> situation.
>
> However, I have noticed that if I switch on full USB and USB storage
> debugging, I can't make it lock up (and I've tried really really hard,
> running all kinds of workloads and benchmarks for 24 hours straight).
> Of course, I need to live with the hundreds of megs of crap spewed into
> my log and crappy thruput (tops out at 5 MB/sec).
>
> So I had a bit of a epiphany, and kept the USB storage debugging on, but
> nulled out the US_DEBUGPX and US_DEBUGP macros in storage/debug.h and
> replaced the US_DEBUG macro with a udelay(250) call. I know this is
> horribly timer-dependant, and probably also dependant on the speed of my
> machine (A 1.4 Ghz Centrino Pentium M laptop).
>
> However, running like this, I get 12 MB/sec thruput (sustained over 7+
> GB of file data on ext2), and I again haven't been able to make it break
> (even sustaining 32 IO threads over 10s of gigabytes of data). Of
> course, the usb-storage kernel thread CPU usage becomes significant
> under load (about 10-15%), but this is acceptable.
>
> So, as you mentioned in one of your emails to linux-usb-devel, this is
> almost certainly a timing issue.
>
> While this probably doesn't help much, I'm just happy to report that I
> can use this crappy enclosure on Linux now :-)
>
>
> Thanks
>
> Jacques
>
>
> PS: I also tried lower udelay values (e.g. 100), but I still got
> lockups with these values. Also, instead of hacking the macros, I'm
> pretty sure shoving the delay into usb.c before executing the command
> (where the US_DEBUG macro is called) will do the job as well.
Thanks for letting me know; that's very interesting and encouraging.
So if you turn usb-storage debugging off and go back to the original
source but just insert that single delay before calling the protocol
handler, does it work okay?
Does the patch below work also? It should do about the same thing as your
250 microsecond delay, but with less CPU overhead.
If making this simple change will get all those broken Genesys Logic
interfaces to work, it would be great!
Alan Stern
===== drivers/usb/storage/usb.c 1.119 vs edited =====
--- 1.119/drivers/usb/storage/usb.c Sun Jun 13 16:09:07 2004
+++ edited/drivers/usb/storage/usb.c Fri Jun 18 11:48:08 2004
@@ -358,6 +358,18 @@
/* we've got a command, let's do it! */
else {
+ int frame1, frame2, count;
+
+ frame1 = usb_get_current_frame_number(us->pusb_dev);
+ count = 0;
+ do {
+ yield();
+ frame2 = usb_get_current_frame_number(us->pusb_dev);
+ if (frame1 != frame2) {
+ frame1 = frame2;
+ ++count;
+ }
+ } while (count < 2);
US_DEBUG(usb_stor_show_command(us->srb));
us->proto_handler(us->srb, us);
}
-------------------------------------------------------
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
