8.2-PRERELEASE freezing on reboot (-current OK)

Jeremy Chadwick freebsd at jdc.parodius.com
Tue Dec 14 00:38:38 UTC 2010


On Mon, Dec 13, 2010 at 11:46:31PM -0000, Steven Hartland wrote:
> ----- Original Message ----- From: "Arno J. Klaassen"
> <arno at heho.snv.jussieu.fr>
> 
> >Jeremy Chadwick <freebsd at jdc.parodius.com> writes:
> >
> >>On Fri, Dec 10, 2010 at 10:37:32AM +0100, Arno J. Klaassen wrote:
> >>>just FYI that on an 8-way Tyan S3992-E based box, a reboot under
> >>>8.2-PRERELEASE (in fact, 8-stable since quite a while) makes the box
> >>>freeze, whilst the same thing under -current works OK.
> >>
> >>Try toggling these two sysctls on the 8.2-PRERELEASE box.  Be sure to
> >>check what the defaults are before toggling them, and only mess with one
> >>at a time.
> >>
> >>hw.acpi.handle_reboot
> >>hw.acpi.disable_on_reboot
> >
> >nope, no difference. Defaults are 0 for both sysctls, both on -current
> >and -8-stable.
> >
> >I noticed that -current prints 'cpu_reset: Stopping other CPUs' at the
> >very end were -8-stable doesn't.

This message isn't always shown, and as I understand it, this is normal.
There may have been a fix for the issue in HEAD/CURRENT, but
historically this message has not always been shown.  It probably has
something to do with which CPU is handling the printing of the messages
(and which gets reset first on a multi-CPU system).

> >Thanx for your answer, best, Arno
> 
> Ooo we had that on a box here on Friday that was running a recent stable,
> thought it was an isolated incident, possibly not! Will try those options
> if it happens again but I know this hardware doesn't usually have issues
> rebooting, so if that fixes its a recent issue in stable.

This is purely speculative on my part, and is the only thing I (off the
top of my head) can think of that might cause it: there were some ACPICA
changes that were brought in within the past 4-8 weeks (possibly two
different sets), that may have caused this.  I'm not sure however, and
sadly I can't remember who did the work or the commit.

Two things to point out:

1) I've seen systems where "cpu_reset: Stopping other CPUs" gets printed
(or sometimes doesn't, see above), then for about 5 *full minutes* the
system sits there doing nothing, but then eventually reboots.  Try being
a bit more patient to see if this is the case.  Also try dropping to the
debugger via serial console (serial break) or VGA (Ctrl-Alt-Esc).

2) I'd recommend to those who are experiencing this problem to try
booting with ACPI disabled (it's one of the boot menu options), and then
try rebooting the system.  If this works, chances are the issue is
related to the ACPI code, and someone may want to cross-post to
freebsd-acpi to get proper attention to it.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list