Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Aug 2010 23:11:51 +0300
From:      Manolis Kiagias <sonicy@otenet.gr>
To:        Chris Maness <chris@chrismaness.com>
Cc:        FreeBSD-questions@freebsd.org
Subject:   Re: Spontaneous Reboots (I thought it was Virtualbox Kernel Modules)
Message-ID:  <4C742787.6090906@otenet.gr>
In-Reply-To: <AANLkTikfXf7cCuDBXfZsW4B81UvUQ2d3r-Ae3jx1RnKK@mail.gmail.com>
References:  <201008241947.o7OJlYbJ012327@mail.r-bonomi.com> <AANLkTikfXf7cCuDBXfZsW4B81UvUQ2d3r-Ae3jx1RnKK@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 24/08/2010 10:58 μ.μ., Chris Maness wrote:
> On Tue, Aug 24, 2010 at 12:47 PM, Robert Bonomi
> <bonomi@mail.r-bonomi.com> wrote:
>   
>>> From owner-freebsd-questions@freebsd.org  Tue Aug 24 12:29:16 2010
>>> Date: Tue, 24 Aug 2010 10:29:27 -0700
>>> From: Chris Maness <chris@chrismaness.com>
>>> To: freebsd-questions@freebsd.org
>>> Subject: Spontaneous Reboots (I thought it was Virtualbox Kernel Modules)
>>>
>>> I have commented out the lines that load kernel modules for
>>> virtualbox, and made sure they were gone with kldstat. However I am
>>> still getting VERY infrequent spontaneous reboots.  So it is not the
>>> modules.  I am thinking hardware.  It has a temperature alarm that
>>> sounds when it is hot, but since I have cleaned it out I have not had
>>> any issues with heat.  I am thinking bad processor/ram.  It is
>>> behaving the same way before/after the upgraded to the latest release.
>>>  What do you guys think?
>>>       
>> I think its 100% certain that it is hardware, or software.  <*GRIN*>
>>
>> You can try randomly replacing things, which can be expensive, time-
>> consuming, and not necessarily effective -- how do you *KNOW* that the
>> parts you're putting _IN_ do not, themselves, have (as-yet undiscovered)
>> problems?
>>
>> I'd try to make the box tell me "something" about *why* it crashed.
>>
>> crank up the level of logging for 'kernel' events in syslog.con,
>> enable crash dumps, and make sure the boot process saves the dump
>> Then you can get into the weird,wonderful, world of 'crash dump'
>> analysis.
>>
>> With a few dumps in hand, you can begin to see if there is any consistency
>> in what the machine was doing -when- it crashed.
>>
>> Happy hunting
>>
>>     
> When I looked at the regular level kernel log, it seemed  to be out of
> the clear blue.  I am an experienced user, but I am not sure if I have
> the programing skills to look at debug output to find a fault.  I
> might need a bit of hand holding on this one.  I looked at backtrace
> to.  I was thinking it was a command or something, but it looks like
> some debugging procedure.
>
> Regards,
> Chris Maness
>   

If the reboot is so abrupt and sudden that nothing is logged (like
someone pressing the reset button), it is most probably hardware.
As others have said the most usual culprits are RAM and power supply. If
you have any spare parts at hand, it may be worth the effort to try with
an other power supply.
If the reboot happens when the system is stressed (lots of disk activity
and/or high power consumption by the CPU, like when portupgrading) the
power supply is even more suspect.
Bad RAM usually causes error messages and dumps to appear rather than
out of the blue reboots. Since it is unlikely that the same program will
always be in the faulty area of memory each time, the dumps will not be
consistent - will seem to be caused by entirely different apps. It is
still worthy to at least take out the RAM modules and clean the contacts
before reinstalling. Use rubbing alcohol (a pen eraser is also good for
gold plated contacts). Many RAM problems on older systems are definitely
caused by dust and corrosion on these contacts.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C742787.6090906>