Date: Wed, 17 Jul 2002 14:16:00 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Szilveszter Adam <sziszi@bsd.hu>, Peter Wemm <peter@wemm.org>, freebsd-current@FreeBSD.ORG Subject: Re: Interesting panic very early in the boot Message-ID: <200207172116.RAA10793@tonnant.cnchost.com> In-Reply-To: Your message of "Wed, 17 Jul 2002 11:19:31 PDT." <3D35B533.9DF22814@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Turns out the workaround is to use DISABLE_PG_G. Two things made me try this. One: In his commit of pmap.c and locore.s on 7/12 7:56 Peter had this to say: +-- |- Try and fix some very bogus PG_G and PG_PS interactions that were bad | enough to cause vm86 bios calls to break. vm86 depended on our existing ... |New option: DISABLE_PG_G - In case I missed something. +-- Two: cvs diff -r1.336 -r1.337 of i386/pmap.c showes that #ifdef SMP was changed to ifndef DISABLE_PG_G and it is in here that pfeflag is set (pfeflag is what guards the code at the crash site!). > set boot_ddb Didn't do this. > set boot_gdb Did this. I though the above two were mutually exclusive options. boot_ddb should be renamed to start_in_debugger or something. Though boot -d is what I was really looking for. > higher/later code, the root cause is catually in locore.s. Happy > bug hunt! ;^). Thanks but looks like I easily escaped from the hunt this time :-) -- bakul 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?200207172116.RAA10793>