ooops - sent to wrong adress first, here we go: > Your problem sounds very similar to one that came up not too long ago. > In that case it turned out that the USB-IDE interface was unable to > handle data flows that were too fast. As more and more data was > transferred, the interface would just crash and require time-consuming > error recovery. The transfers just slowed down to a crawl, while > unwritten buffers filled up the memory.
Thanks for the information :) That indeed is not totally unlikely. After a new test I did today, I noticed that my kernel does indeed not totally crash, but this happens: The transfer indeed slows down very much, and at some point (with about 2 MB of Ram left ;) ) it stopped. My drive signaled no more activity. I could still switch consoles on my linux, but none of them would accept keyboard input. MagicSysRq Key still worked. I will compile a 2.6.0-test kernel and try for the rsync and bandwidth limiting, just to see if that is the problem. Thanks for the hint. Indeed, I just did that(compile and try with rsync), but this does not really seem to help. It (rsync bandwith throtteling) just slows down the process, making buffers in memory increase slower. I can see when commands are sent to the device (which are not a continuing stream, but more like a series of commands, pausing in between due to the bandwidth limiting. Maybe I need to lower it a lot more - I tried with rsync and between 50 kb and 20 kb), seeing it work in turn with those bursts and pausing in between. When the transfer begins, for a time nothing happens. I suspect the buffers of the USB to IDE connector, or of the HDD itself first fill - and then the commands are sent to the device. :( Is there anything I could do about it? (heh - maybe I have to learn to write my own driver... or just sell this stupid thing :( ) -- Today is Setting Orange, the 54th day of Confusion in the YOLD 3169
pgp00000.pgp
Description: PGP signature