[PlanetCCRMA] Lockup on tar command over ssh
nando at ccrma.Stanford.EDU
Sat Jun 21 05:46:57 PDT 2008
[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 18.104.22.168... 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
> > 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__")
More information about the PlanetCCRMA