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

Reply via email to