On Saturday 12 January 2002 09:43, justin bengtson wrote: > On Sat, 2002-01-12 at 09:26, Bob Miller wrote: > > If you have a second computer, pinging the crashed box is useful. > > When a Unix/Linux box responds to a ping, it happens inside the > > TCP/IP stack. If you get a pong back, then you know that the box > > is accepting interrupts and able to run them. That means the > > problem is probably outside the kernel. > > i may have another computer in a week or so. i'll give that a try if > i haven't, uhm, re-installed... > > > Otherwise, you know you have a wedged kernel, and either you've > > created a bad kernel config (Hi, Mike!), installed a buggy driver, > > or the kernel just has bugs (which never happens, because this is > > Linux! *-: ) > > not, i. it's redhat's "proprietary" kernel (you know, the one that > has five times the crap that comes with the normal kernel... > s'truth! when installing, redhat reports the "kernel" package as > > 100 mb...) i suppose i'll just try a recompile with a newer kernel > and see if that works. > > > Another good test is switching to a different virtual console. > > CTL-ALT-F1 through F9. But buggy X servers sometimes break that. > > i'll give that a try too. though it didn't seem as if the keyboard > was responding. > > now that i think about it, i should check into being a guinea pig for > the kernel developers. considering how much i like "bleeding edge" > software... > > if anybody can break it through normal use, it'd be me. ;)
Occasionally removing a loaded kernel module can cause problems (this could happen w/o your doing anything if the module was loaded/unloaded via the hotplug tools). Some modules hook themselves into kernel services, and, if a subsequent module uses the same hooks, you have a potential for disaster when one is removed. Or a background userland program may be using a module interface, if the module is removed unexpectedly, the user program, calling into the non-existant module, can crash the kernel. The latter usually requires you, as root, to make some change to the system. The former can happen with poorly configured kernels, as an example, just by unplugging a USB printer that is currently printing a job. Most kernel crashes are due to bad device drivers. The NVIDIA binary only drivers have been an ongoing source of strange crashes.
