Date: Wed, 17 Jul 2002 11:19:31 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bakul Shah <bakul@bitblocks.com> Cc: Szilveszter Adam <sziszi@bsd.hu>, freebsd-current@FreeBSD.ORG Subject: Re: Interesting panic very early in the boot Message-ID: <3D35B533.9DF22814@mindspring.com> References: <200207171657.MAA28965@glatton.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
> > I believe setting DISABLE_PSE in the config file and rebuilding
> > will make this go away.
>
> Terry, thanks for the suggestion but that didn't do it.
This surprises me. I thought it would be the result of Peter's
recent pmap changes, and the fact that there is a bad problem
with Intel processors with 4M and 4K page mappings existing in
the TLB caches for the same regions simultaneously, particularly
because invltlb() doesn't do what it's supposed to do when that
happens, and you have to be really, really sneaky to get it to
do the right thing. FreeBSD was "accidently sneaky" because it
used to do things very similar to an Intel example of how to do
things, and that example was similar to Intel's test code to
make sure the processor was functioning in it's ICE configuration
with the extra pins and things.
That there could be a real error in that code surprises me, since
Peter really knows what he's doing, even if that low in the
hardware, there are undocumented interactions that even Intel's
errata doesn't seem to know about.
> Time to review recent changes and single step the kernel.
> BTW, how do you stop the kernel before it panics? It
> panics so early that there is no time for sending a break.
There is a boot option that breaks directly to the debugger;
here is the information from /usr/src/sys/boot/common/help.common:
set boot_ddb
Instructs the kernel to start in the DDB debugger, rather than
proceeding to initialise when booted.
set boot_gdb
Selects gdb-remote mode for the kernel debugger by default.
It should work in this case, because the place you are having
the problem is after the DDB (BDE) debugger has been initialized,
after the kernel has made the hand crafted virtual memory mirror
the physical memory, and jumped into protected mode, and that's
about the earlierst you can start stepping through the assembly
code with the debugger.
To use these, you should hit space to interrupt the boot after
the kernel is loaded, while it's in the boot count-down, and
just type the commands manually. You could do it earlier, but
I don't know what your loader configuration files look like
(and, no, I don't, I don't want you to send them to me... 8-)).
In a general sense, you should act like the debugger exists
outside the kernel and VM system, and concentrate on what the
system is trying to do at this point, and why, and how the code
does or doesn't do that. As a starting point, it's important
to know that this deep in the code, the virtual image is
*supposed* to match the physical image, except for the extra
content of pages used for the management of the virtual memory
itself. That suggests to me that while the symptom is in some
higher/later code, the root cause is catually in locore.s. Happy
bug hunt! ;^).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D35B533.9DF22814>