5

Once in a while I get my server running FreeBSD 8.0 amd64 fail due to bad memory (incompatible with motherboard) modules. Each time it happens, the box stalls with the last note saying that it will automatically reboot in 15 second, but it never does.

How do I fix this? I need computer to reboot after kernel crash, unattended.

(Please do not recommend to replace memory, as soon as I get the modules, I will, but I need a quicker solution that will not require me to stand still next to the box just to press the reset button each time it crashes.)

1
  • 2
    It's possible that the mismatched memory causes the machine to never complete the reboot. It would be helpful if you posted the relevant part of your logs. Mar 29, 2010 at 12:44

1 Answer 1

3

Unless someone/something is causing keyboard input (or something that looks like keyboard input) FreeBSD should reboot automatically after a panic. You'll know if that's the case because instead of saying that iy will reboot in 15 seconds it will say something to the effect of "press any key to reboot" because it thinks you're looking at the panic trace.

The fact that the auto-reboot is not working & you suspect bad RAM suggests that's what could be causing the auto-reboot to fail (the auto-reboot is just another software function - if it's in corrupted memory it may not work).

Did you get this bad RAM from a memory upgrade? If so, downgrade back to the old configuration (better to have a machine with less RAM than one with bad RAM that causes crashes). Alternatively if your system can run without matched pairs of RAM run one of the free memtest tools to locate the bad DIMM & pull it (if ALL your DIMMs are bad or incompatible you're pretty well screwed: If anything on this box is important I'd take the machine out of service rather than risking data corruption).

3
  • Thanks for a good guess regarding the reboot function is stalled by the memory fault. However, there is still a software function that puts a message on the screen with error data (like memory address, values of processor registers). This particular function is not stalled by the protection fault in kernel mode. I assume that exactly this particular part of the code is responsible for triggering the reboot (ACPI/APM/whatever). If so, then the box should not stall after the error message on the screen. Mar 31, 2010 at 10:48
  • You're proceeding from an invalid assumption ("The RAM address that holds the panic() message is OK, so the one that holds the reboot instruction is OK") -- they're probably near eachother, but not the same physical location in RAM. Unfortunately you can't say with any certainty that an area is/isn't OK (unless you have ECC RAM in which case the server's event log should give you address of error data). All that said, if your machine fails to reboot every time it may be an ACPI issue -- Does it complete a reboot when you do shutdown -r?
    – voretaq7
    Mar 31, 2010 at 17:22
  • voretaq7, It does stall every time. I always suspected the ACPI/APM defect, however, I have little idea on how to test it. And I asked this question on serverfault just because I could not find a quick solution of diagnosing the issue in FreeBSD Handbook. I though that if someone had come across this, I would get a quick solution. (Quicker then waiting for another failure to test each option, and it fails only once or twice in a month). Apr 1, 2010 at 6:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .