[PlanetCCRMA] Lockup on tar command over ssh

[Adam Swift]

> Not much to do, regretfully. Are the keyboard lights blinking after the
> computer locks up? That would suggest a kernel panic (which is my best
> guess of what might be actually happening).

Nope, standard lights, and not responsive.

>
> Anything in /var/log/messages after you reboot?

The only thing in the log is
restorecond: Will not restore a file with more than one hard link
(/etc/resolv.conf) Invalid argument
But I'm pretty sure that's irrelevant and to do with the tar command itself.

>
> Hmmm, you could try a new experimental kernel I have just released based
> on 2.6.25.7... It is in the "testing" repository.

Tried out the kernel. Unfortunately, it wouldn't boot, gave me this:
Reading all physical volumes...
No volume groups found
Volume group "VolGroup00" not found
Unable to access resume device (/dev/VolGroup00/LogVol01)

followed by a bunch of unable to mount errors.

I've done some more testing, and found that I can trigger the crash  
with an SFTP transfer at high speed ( > 1MB/sec) but not at a lower  
speed (128 KB/sec). I can also trigger it very rapidly just by piping  
a large file over a netcat connection. This leads me to believe it's a  
problem with the ethernet driver  (8139too) under the realtime kernel.

Are there any patches or config options specific to this kernel that  
might be causing it? Should I try the kernel mailing list?

Adam

>
> -- Fernando
>
> PS: you can activate the testing repo by installing:
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/8/i386/repoview/planetccrma-repo-testing.html
>
> That will install a planetccrma-testing.repo file in /etc/yum.repos.d/,
> what I would suggest doing is actually disabling it by editing the file
> and manually enabling it in the yum command line when you want to try
> something specific that is there ("yum --enablerepo planetccrma-testing
> __commands__")
>
>
>