[Testers wanted] /dev/console cleanups

[Dag-Erling Smørgrav]

Jeremy Chadwick <koitsu at freebsd.org> writes:
> Peter Jeremy <peterjeremy at optushome.com.au> writes:
> > This is deliberate.  If the system panics, stuff that was in the
> > message buffer (and might not be on disk) can be read when the
> > system reboots.  If there is no crashdump, this might be the only
> > record of what happened.
> That doesn't sound deliberate at all -- it sounds like a quirk that
> people (you?) are relying on.

No, it is deliberate.  Just because you don't like it doesn't mean we're
morons.

> You're under the mentality that the information is *always* available
> after a panic/reboot -- it isn't.  I have 4 different Supermicro
> motherboards (all from different years) which will "most of the time"
> lose the msgbuf after rebooting from single-user -- but sometimes the
> msgbuf is retained.  And no, bad hardware is not responsible for the
> randomness of the problem.

We know there are systems where it doesn't work.  That doesn't mean it's
not useful when it *does* work.  There are also systems where it works
reliably, including most SoC and SFF systems.

> I think it's been discussed in the past how/why this can happen.  It has
> to do with what each BIOS manufacturer chooses to do with some parts of
> memory during start-up.

Mostly whether memory remains powered-on through the reset process.

Speaking only of i386 / amd64 systems, there are several ways to reboot
a computer:

 - Return to real mode and call the BIOS reboot subroutine.  This will
   perform a cold boot (memory is cleared) or a warm boot (memory should
   not be cleared, but the BIOS may do so anyway) depending on the value
   stored at a specific location in memory.

 - On systems with an i8042 keyboard controller, one of the controller's
   output lines is usually wired to the CPU's reset pin.  Writing a
   specific value to one of the keyboard controller's control registers
   causes it to pull that pin low.

 - Triple fault: set up an empty interrupt descriptor table and trigger
   an interrupt (e.g. divide by zero).  The CPU will fail to invoke the
   corresponding interrupt descriptor, causing a double fault interrupt,
   which will fail to execute, causing a CPU reset.

The latter two techniques can be used (and *have* been used) to switch
back from protected mode to real mode, because they are faster than the
documented method.  Memory is *not* cleared, and the CPU will start
executing whatever code is stored at 0xfffffff0 in real memory; this is
normally a far jump into the BIOS reboot subroutine, so if you don't
pull any tricks (e.g. jump to your own code that does whatever it was
you needed to do in real mode, then return to protected mode), they are
equivalent to the first technique.

 - ACPI reset: store the value specified by RESET_VALUE in the FADT into
   the register specified by RESET_REG in the FADT.  According to the
   ACPI spec, this results in a cold boot.  However, this part of the
   spec is optional, so not all motherboards support it.  FreeBSD will
   only use ACPI reset if the hw.acpi.handle_reboot sysctl is not zero,
   which it is by default (mostly, if I recall correctly, because ACPI
   reset is unreliable).

DES
-- 
Dag-Erling Smørgrav - des at des.no