Slashdot Mirror
Preparing for the Worst in FreeBSD
LiquidPC writes "In Part I of this series,
Michael Lucas, from ONLamp.com, goes over preparing your FreeBSD computer for the worst in case of a system panic."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I'm a Sun admin by day, and Sun has always (since at least SunOS 4.1, when I started) made provisions to do this. I'll admit that I'm rarely cutting-edge with my Linux systems, so I haven't had any panics that I wanted to track down, so I don't know if Linux does this sort of stuff for you. I'm shocked that OpenBSD doesn't.
Nothing for 6-digit uids?
This is most likely a hardware failure, possibly memory. Try memtest86 before you go on a kernel debugging hunt... basically, if your server has worked great for 12 months and then craps like this it probably ain't software.
In 8 years of running bsd, I've NEVER had a kernel panic. The article is just about the kind of thinking that prevents kernel panics in the first place: careful precautions.
Can you say the same about linux? Never a kernel panic? Never a corrupted file system? Never a bad kernel release? Hardly.
Talk about hook, line and sinker! The mere mention of 'OpenBSD running on qaud processor systems' should have set alarm bells off in your little head.
As an OpenBSD user, I am well aware that it does not support more than one processor. Ooh you have been so trolled. Priceless.
One future, two choices. Oppose them or let them destroy us.
Oh your so so so wrong. A stop 0xA is purely driver bug. It typically occurs when it tries to touch pagable memory at high IRQL (like in a DPC) and that memory is actually swapped out in the swap file. That particular case is due to poor programming practice on the driver writter's part. They should have allocated that memory as non-paged. Also before they shipped that driver they should have run "verifier" with special irql checking enabled. (For those who don't know what verfier is, it is a built in tool that is used to test device drivers [old and new]. If you are running a Win2k or WinXP box just open up the run line and type in verifier. You will get this program. Unless you know what you are doing and have a kernel debugger enabled and attached I wouldn't fuck with its setting or you may be looking at a blue screen due to a bug verifier found and you may not know how to recover it [without reinstalling]) If you want a defination of all of the bugchecks and what each parameter means download the lastest debugger from http://www.microsoft.com/DDK/Debugging/default.asp and look in the help file.
Silly Rabbit...Sig's are for kids.
The article is informative and clearly written, but crashdumps are more useful for determining kernel software problems than hardware ones.
If the system is a stable release, and has been running without crashes for about a year, I'd start by running diagnonstics on the hardware - specifically, memory and disk - before trying to debug the kernel.
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
Wow, a well written, entertaining, somewhat original troll.
:-) Also, there was a Win2k box at work that had a sound card that NT 4 supported but Win2k and above didn't (and the company was out of business, so no future support was going to happen). Linux has and still does support the thing fine.
+1, Troll
However, because some of these points are valid, I'm going to respond.
"When my Linux machine crashed and I was unable to mount my root partition..."
In terms of troubleshooting capabilities, Linux is the best OS I've ever used. When Windows dies, all the techs I know just reinstall the thing, and if that doesn't work, wipe the drive and reinstall. There simply aren't any good diagostic tools, and if a crash happens during startup...well, how the heck are you supposed to know what caused it? If I can view and edit my initscripts, I *can* fix this. The main problem is that while you *can* fix almost any problem in Linux, it's also not necessarily easy, and you may spend a while reading up on things.
IE 5 *for Windows* is not more W3C compliant than Mozilla, and IE 6 is worse.
As for an "American OS", I wouldn't be suprised if large chunks of Windows are developed in MS's software dev branch in India, though admittedly I don't know for sure, and MS may have a keep-the-crown-jewels-at-home policy.
Windows *does* provide good game support. Better than Linux. My productivity has climed a bunch since getting rid of Windows.
As for NT and routing, my experience with trying to convince NT to handle Ethernet and a modem line at once have gotten me incredibly frusterated with Windows as a whole. The wizards are fragile (close a window when the wizard doesn't expect it and things start breaking, I reached a state where the entire networking component needed to be reinstalled or else it ignored all the numbers I was entering in to it...) Granted, the non-GUI wrapped interface to Linux routing is a little more complicated than in NT, but it's not that bad.
May we never see th
Today the faulty or poorly supported hardware is much more likely reason for a crash. I have quite a few K6-2 and K6-3 boxes around, and they die like flies, after 1 or 2 years of continuous use; most often the motherboard fails. I had a Linux box that crashed once in 2 weeks; I moved the HDDs into another computer, moved most of cards and it now averages 150 days of uptime, interrupted only by power outages (no UPS there). Another K6-3 box sometimes fails in BIOS, during memory test in POST routine! I gave up on this one; it is not worth of my time. Needless to say, this box had all sorts of weird crashes in all OSes that I ran on it; NetBSD didn't even boot from the boot floppy, mumbling something about "garbage IDE DMA" :-)