[PlanetCCRMA] Lockup on tar command over ssh

[Fernando Lopez-Lezcano]

[sorry for the delay, currently travelling....]

On Fri, 2008-06-20 at 19:34 +1000, Adam Swift wrote:
> > 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.

Yup, that's not it. 

> > 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.

Are you booting without the "rhgb quiet" option? You _may_ be able to
see what leads to this...

> 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?

You could try the lkml and cc' Ingo Molnar. I currently can't really
read lkml so cc' me directly if you email them...

Sorry you are having problems. Which is the latest Fedora kernel you
have tried?

-- 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__")