Messages in this thread | | | Subject | Re: Subject: 2.0.33: talk about weird | Date | Thu, 15 Jan 1998 22:23:14 GMT | From | linux-kernel subscriber <> |
| |
Samuli Kaski <samkaski@cs.helsinki.fi> wrote: > After playing a while with it, I gave up since something was definetly > wrong as I couldn't compile anything. I rebooted and everything seems > fine again, I can compile and mount/umount.
> Sorry there were no oops, I just thought I let you guys know. Maybe > the rm -rf caused inodes to get corrupted causing havoc? If so, I > still need to come up with a theory for the failing compile because I > use my box for compiling all the time and I wouldn't be much off by > saying that I had compiled something 10 minutes before the rm -rf > incident.
> I'm just speculating here but I must admit I have never seen a Linux > box behave this way before. Maybe failing hardware, hmm?
> The system is from a clean 2.0.33 tree with the Joliet patch applied, > rm is from fileutils 3.16, the mount is 2.7g and libc is 5.4.38.
I had something weird happen too while compiling the latest ftape on 2.0.33. I seemed to get some compilation errors in the zftape and compressor subdirectories when I didn't have the -DBROKEN_FLOPPY defined, but only if it was the first compile after untarring, and I changed MCONFIG before any compiles. If I compiled with the define, then removed it and compiled again, it was fine.
Needless to say, there was absolutely no way this define could produce the error. I was going to send off an email, and I tried it once again, and it worked.
I can only assume the buffer cache got corrupted somehow, and after more activity the corruption was flushed resulting in correct behaviour again. It was rather unnerving. I have a vague recollection of this happening with a much earlier kernel, so put it down to an alpha particle !
-- Peter Fox
| |