Hi,

sorry for the delayed response...

On 13/06/06 00:29, Francois Romieu wrote:
> wget goes faster, right ? Do you have some vmstat 1 output at hand
> for it ?

It does indeed go faster, and it seems a little bit more reliable, but
with big enough transfers it locks up too. See commandline-2.txt and
vmstat-2.txt - it gets through around 600-700MB before locking up. I
also noticed that at 3-4 points during the transfer it seemed to
"pause", and then continue.

> Ok but can you set correctly the link with the command which was told
> to fail in you first mail ? The patch could fix it.

Yes, indeed: doing "ethtool -s eth0 speed 10 autoneg off" switches it to
the slow speed, and keeps it there too (at 10Mb/s).

"ethtool eth0" still reports "Advertised auto-negotiation: Yes" and
"Auto-negotiation: on", which is probably not right. It also reports
"Advertised link modes:  10baseT/Full" only, which is probably correct.

It only actually restarts auto-negotiation when I issue the command
"ethtool -s eth0 autoneg on", at which point the speeds goes back up to
1000Mb/s - the expected behaviour. So it seems ethtool works better than
before wrt auto-negotiation.

> Can you try something like:
> dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin 

Well this transfer (from shuttle -> hell) completed successfully. See
commandline-3.txt and vmstat-3.txt; However I noticed the speed was only
around 7 MB/s and wondered if the link speed was maybe set to 100Mb/s,
so I immediately afterwards did a "wget"-test again, which locked up
after only 5%. The wget test however did confirm the link speed to be
1000Mb/s. See commandline-4.txt and vmstat-4.txt for that last, short test.

> May I assume that the freeze locks everything (keyboard, mouse, led) beyond
> the scp command itself ?

Yes indeed. My (usb) keyboard doesn't respond at all anymore, networking
is completely out, (usb) mouse freezes too. SysRq doesn't seem to help
much either.


-- Mourad