This makes it look as though the machine is comatose - keyboard and mouse input are ignored. In fact, the first time it happened I thought perhaps Crucial had sent me some bad RAM.

After it happened a few times, I decided it's somehow related to the TCP/IP stack or the PCMCIA daemon (since the system always freezes for a couple of seconds while the PCMCIA network card is reinitialized after coming out of suspend or hibernation). It may be attributable to DNS lookups - it happens less frequently now that I've upgraded to Netscape 4.7.2, which does DNS in the background. pine still can cause trouble.

It's somewhat counterintuitive that the network should have anything to do with the GUI, but since X uses TCP/IP to do everything it does seem plausible.

It's possible the condition would disappear if I waited long enough. I'm not that patient, so I usually hit Fn+F4 to suspend the machine. This seems to unstick whatever's got things stuck and puts the machine into suspend. Of course, when I come back out the network is hosed and I have to ifdown eth0/cardctl eject/suspend again and then bring things up normally when I come back to get network connectivity again.

2001 Jul 24 -I received the following note. I have not noticed the problem for some time, but I went ahead and followed the advice it contains.

I had the same problem but I found a fix. It has something to do with the enabling / disabling of internal point device in the bios. Nothing to do with the TCP/IP stack. To fix, use ntpctl and change the following to "enabled":

Int. pointing device (current) enabled (ctrable)

Int. Pointing device (CMOS) enabled (ctrable)

The kb / mouse hanging problem existed when they were in "auto" mode, but gone away after changing to "enabled". I guess it is due to the bios trying to constantly figure out whether to turn on the internal pointing device and then eventually screw it up.

Those of you who prefer tpctl's command line interface presumably should use

tpctl --setup-pointing-device-internal=enable