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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message