[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Kernel problems

Ok, I'll start by saying that I adore the "Debian Way"(TM). However, I
have a long-standing problem that is pretty much the only blight I can
find with Mr Debian.

My server PC is old. Really old. Cyrix M2 old. That said, it does the
job until newer spare hardware becomes available. My first foray into
Linux was Redhat 7.3, which in due course got upgraded to RH8. In that
config the box ran for 9 months with the only downtime caused because I
hit the plug with my foot :) I switched to Debian after I broke RPM so
badly I couldn't install anything (they broke the pthread debugging
symbols for libc, and I needed them urgently....so I forced a newer
fixed version that hosed RPM badly as it wasn't ABI-compatible(d'oh,
you'd think RPM would be statically linked!) Thanks to ./ evangelising,
APT was my future.

My Debian install has been great, bar one thing. Roughly every two
weeks, not quite clockwork, but close enough, I get a kernel panic. It's
near always (IIRC) in an IRQ handler, generally network or disk related.
The load on the machine isn't huge, so I doubt that's a problem. At
first I suspected the RAM had gone bad, given the strange nature of the
panics (always in different places), but I've swapped it countless
times, and memcheck has always said the ram is fine.

The first few times I scribbled down the panic data and tried various
places to report it...but no-one seemed interested...so where do I go
with this? I disabled a DSL module that tainted the kernel, thinking
that would help me get some attention, but no, it still panics, and
still no interest. Strangely enough, the write panic to swap code/patch
doesn't seem to be in the stock kernels, so short of a serial terminal,
there's no way other than manual transcription of getting the panic data
(which scrolls a looong way) to those in a position to do something
about it. Tweaks of this and that are all fine and well, but given the
~2 week gap it takes for the panic to manifest itself, I gave up on that
avenue a long time ago as, well, the panics never stopped.

These days I just reboot, let the quota checks go though their thing,
and all is well for ~2 weeks. I can't help but feel this isn't the way
it's supposed to be though. I was winning an uptime competition between
a mate and his Win2K server before I installed Debian...now he's been up
 3 years or so...and my record has been 35 days. It makes me sad, but
still, there's not a chance in hell of running equivalent Windows
services on the box, so I make do, knowing that it's still a better
system as I can fix (and have several times) most of the other problems
I get thanks to the open source nature of the project.

- Jamie

PS, for those interested, here's lspci's output:
0000:00:00.0 Host bridge: Intel Corporation 430VX - 82437VX TVX [Triton
VX] (rev 02)
0000:00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA
[Natoma/Triton II] (rev 01)
0000:00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II]
0000:00:07.2 USB Controller: Intel Corporation 82371SB PIIX3 USB
[Natoma/Triton II] (rev 01)
0000:00:11.0 VGA compatible controller: S3 Inc. 86c764/765
[Trio32/64/64V+] (rev 43)
0000:00:12.0 System peripheral: Conexant ADSL AccessRunner PCI
Arbitration Device (rev 01)
0000:00:12.1 ATM network controller: Conexant AccessRunner PCI ADSL
Interface Device (rev 01)
0000:00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
0000:00:14.0 Ethernet controller: Digital Equipment Corporation DECchip
21041 [Tulip Pass 3] (rev 21)

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: