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