On Mon, Dec 13, 2010 at 11:46:31PM -0000, Steven Hartland wrote: > ----- Original Message ----- From: "Arno J. Klaassen" > <a...@heho.snv.jussieu.fr> > > >Jeremy Chadwick <free...@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 j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
