Date: Thu, 20 Nov 2008 10:53:07 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: [Testers wanted] /dev/console cleanups Message-ID: <86r656oha4.fsf@ds4.des.no> In-Reply-To: <20081120070820.GA19307@icarus.home.lan> (Jeremy Chadwick's message of "Wed, 19 Nov 2008 23:08:21 -0800") References: <e71790db0810271936r1ce4619an1d64c6aae62c3ec1@mail.gmail.com> <20081028081154.GQ6808@hoeg.nl> <20081118213410.GA81783@hoeg.nl> <20081118214919.GM83287@bunrab.catwhisker.org> <7d6fde3d0811190202p4f6d8941h3932b70b8fe1a93a@mail.gmail.com> <20081119104731.GA83366@icarus.home.lan> <20081120063936.GU51761@server.vk2pj.dyndns.org> <20081120070820.GA19307@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick <koitsu@freebsd.org> writes: > Peter Jeremy <peterjeremy@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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86r656oha4.fsf>