Hi Alan!

On Mit, 24 Mai 2006, Alan Stern wrote:
> The normal usb-storage debugging isn't very good for tracking down 
> intermittent problems like this.  However if you want, you can add your 
> own printk statements to the driver to find out exactly when each reset 
> starts and ends.

Ok, I retract my statement that the reset takes so long, it takes less
than a second. I have put a printk before and another after the two
resets ( port reset and transport reset). I could only see port resets
and they usually take less than one second. Transport resets didn't
occur at all, ie. result = usb_stor_port_reset(us) always was > 0.

So it seems that my ls tests are not very useful. Interestingly I
observed the following: ls hangs always till there is a port reset, than
it succeeds. It looks like this: I do permanent ls -l of the target
direcory and can see the files growing with every ls -l. Then suddenly
nothing changes, and a ls -l onto other file hangs.

Then the port reset and the other ls continues, and the ls -l shows the
files again growing.

Maybe it is only that the hard disk needs so much time to actually safe
the data and while this time it is blocking. Possible?

I did another time run, for copying the same 30 files, each around
230Mb to the devidce, and this time I had again 29 resets and 
real    25m28.033s
user    0m0.272s
sys     0m29.250s

I found something strange than, maybe only strange for me:
 9727 ?        D      0:00 [pdflush]
 9733 ?        D      0:00 [pdflush]
 9735 ?        D      0:00 [pdflush]
 9736 ?        D      0:00 [pdflush]
 9738 ?        D      0:00 [pdflush]
 9749 ?        D      0:00 [pdflush]
 9785 ?        D      0:00 [pdflush]
 9788 ?        D      0:00 [pdflush]
 9789 ?        D      0:00 [pdflush]
 9790 ?        D      0:00 [pdflush]
Hmmm... so many of them? But I have no idea about these kernel layers.
They go away when the copying is finished.




Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at>             Università di Siena
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
CLACKAVOID (n.)
Technical BBC term for a page of dialogue from Blake's Seven.
                        --- Douglas Adams, The Meaning of Liff


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to