>I made some changes to your patch. Most notably, I set the retry limit >to 255. If there is one retry per microframe, that will last for 32 >ms. When you add in the overhead of interrupt handling, it will >probably last longer. I guess it will be long enough to handle most >transients. Thank you for your review. It became a very refreshing code. >When I tested it by unplugging a second device during an ongoing >transfer, it worked with only one retry, just as you found. When I >tested it by unplugging a flash drive during I/O, I got a rapid string >of 254 debug messages at intervals of 250 us -- so the total retry >period was 64 ms, which I like better than 32 ms. Of course, with >debugging turned off it might go more quickly. When testing in my environment, total retry times was 32ms. In my environment, interval of retrying was 125us. Is this difference different of cpu? (my testing cpu is Pentium 4 3.4GHz) I'm anxious whether this overhead affect other process. I am sorry, I don't know in limited knowledge whether this overhead is within acceptable. If you know that this overhead isn't problem, please tell me reason. >There were a few other changes, some stylistic and some functional. >We could consider merging this -- except that of course Dave has to >review it. An important special case to think about: What happens if >the device isn't running at high speed? When I unload ehci_hcd module, I repeated whether XactErr occurred for about one hour. But the error didn't occur. In other speed, I don't know what have an impact. best regards Koichiro Saito -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
