Messages in this thread |  | | Subject | total freeze - 2.0.23/2.0.24/2.0.25 | Date | Wed, 20 Nov 1996 18:40:52 +0000 | From | Paul Dunne <> |
| |
> If you are connecting to a linux box over a lan without an NFS, you must > have all computers that will be connecting to it listed in /etc/hosts. > Otherwise your box will stupidly dilly dally around for a minute waiting > for the NFS to respond or something. This may only happen if eth0 is your > default route, I'm not sure. Add them to /etc/hosts and see if the delay > goes away.
Yes, it did! Why the bloody hell does that happen? I specifically didn't put the local network host in /etc/hosts because I'm running a local named for the network.
> > This test did not yield the expected results; the crashing continued. > > I have now reverted to 2.0.23, which is very stable on my machine; > > but before I did so, I noticed an interesting thing. When using my > > terminal, I could not keep the machine up more than a few hours at > > most; however, if I left the terminal switched off, and used only the > > console, I went a whole day (!) without a crash. So, some problem > > with the serial driver, maybe? I'm no kernel hacker; but there does > > seem to be a kernel problem here. > > That could just be a coincidence. I've "fixed" programs to have them > magically work for a week but then crash again from the exact same > problem. >
Yes, I take your point; but I haven't been doing any programming. I had a stable kernel - 2.0.23, max. 14 days uptime before I shut it down - then I did several things: patched to 2.0.24 and then 2.0.25, added the local network, and stuck on the terminal. Hey, presto! Unstable machine, prone to freezing. I notice I say "crash" in my previous message; but what actually happens is a total freeze: no disk activity, dead keyboard, can't log in from the terminal or the network, the works. This must surely be a kernel problem?
Paul -- paul@tiny1.demon.co.uk | http://www.tiny1.demon.co.uk | 0181-365 2821
|  |