On Fri, 2 Mar 2007, Gordon Messmer wrote: > With the patch, the resets happen a lot less often. However, > there are still IO errors recorded, which is unlike the older > kernels.
This log is easier to analyze than the other one. The first thing to note is that the second column is a timestamp, with time values recorded in microseconds. That tells us the time interval between I/O errors (rounded off to the nearest second): > f7e6e5c0 115310766 C Ii:003:01 -84 0 > f7e6e5c0 115324315 S Ii:003:01 -115 4 < > f7e6e5c0 126710411 C Ii:003:01 -84 0 11 seconds. > f7e6e5c0 126723766 S Ii:003:01 -115 4 < > f7e6e5c0 158309425 C Ii:003:01 -84 0 32 seconds. > f7e6e5c0 158322931 S Ii:003:01 -115 4 < > f7e6e5c0 179756756 C Ii:003:01 -84 0 21 seconds. > f7e6e5c0 179770253 S Ii:003:01 -115 4 < > f7e6e5c0 198060184 C Ii:003:01 -84 0 18 seconds. > f7e6e5c0 198072559 S Ii:003:01 -115 4 < > f7e6e5c0 218884149 C Ii:003:01 -84 0 21 seconds. > f7e6e5c0 218896689 S Ii:003:01 -115 4 < > f7e6e5c0 224396148 C Ii:003:01 -84 0 5 seconds. > f7e6e5c0 224409144 S Ii:003:01 -115 4 < > f7e6e5c0 244780139 C Ii:003:01 -84 0 20 seconds. > f7e6e5c0 244793426 S Ii:003:01 -115 4 < > f7e6e5c0 254588130 C Ii:003:01 -84 0 10 seconds. > f7e6e5c0 254601669 S Ii:003:01 -115 4 < > f7e6e5c0 268420112 C Ii:003:01 -84 0 14 seconds. > f7e6e5c0 268432778 S Ii:003:01 -115 4 < > f7e6e5c0 290372073 C Ii:003:01 -84 0 22 seconds. > f7e6e5c0 290384591 S Ii:003:01 -115 4 < > f7e6e5c0 295340063 C Ii:003:01 -84 0 5 seconds. > f7e6e5c0 295353188 S Ii:003:01 -115 4 < > f7e6e5c0 315924010 C Ii:003:01 -84 0 21 seconds. > f7e6e5c0 315937371 S Ii:003:01 -115 4 < > f7e6e5c0 352067892 C Ii:003:01 -84 0 36 seconds. > f7e6e5c0 352081130 S Ii:003:01 -115 4 < > f7e6e5c0 365539839 C Ii:003:01 -84 0 13 seconds. > f7e6e5c0 365552303 S Ii:003:01 -115 4 < > f7e6e5c0 385667750 C Ii:003:01 -84 0 20 seconds. > f7e6e5c0 385680578 S Ii:003:01 -115 4 < > f7e6e5c0 394395709 C Ii:003:01 -84 0 9 seconds. > f7e6e5c0 394408092 S Ii:003:01 -115 4 < > f7e6e5c0 442395446 C Ii:003:01 -84 0 48 seconds. > f7e6e5c0 442408385 S Ii:003:01 -115 4 < > f7e6e5c0 444555433 C Ii:003:01 -84 0 2 seconds, which triggered a reset. > f66d1440 444555450 S Co:001:00 s 23 03 0004 0001 0000 0 ... The patch could shorten the time window from 2 seconds to 0.5 seconds. That would reduce the number of spurious resets even more, but it wouldn't eliminate them entirely. I don't see any regular pattern in those time intervals, do you? Which leads me to think the cause is something more or less random, like electromagnetic interference. It's probably not a software entity periodically doing something bad. But of course that doesn't explain why the effect fails to show up at all with the earlier kernel... Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users