The following reply was made to PR port-i386/26007; it has been noted by GNATS.

From: Gavan Fantom <gavan@coolfactor.org>
To: Petar Bogdanovic <p+netbsd@2005.smokva.net>
Cc: Urban Boquist <urban@boquist.net>, gnats-bugs@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 13:06:42 +0100

 Petar Bogdanovic wrote:
 > Urban Boquist wrote:
 > 
 >> Actually, I think your problem is most probably the same as 26007. The
 >> problem now, I think, is that the work-around Gavan committed in
 >> August works for some people but not for all (which he also noted in
 >> the commit message).
 >>
 >> FWIW I also have an (older) VIA cpu machine that exhibits very similar
 >> symptoms; very early in boot the display goes either very weird, or
 >> completely black, or the text size gets very small. In all cases it
 >> hangs hard. Interestingly Gavan's change helped i bit in that it can
 >> now boot from floppy, but the same boot blocks booting from a CD still
 >> hangs... ;-(
 > 
 > 
 > The funny thing is also the 'randomness' of the hangs - if you play with 
 > the 'interactive boot-loader', you can get the weirdest 
 > color/resolution/size-combinations!
 
 The basic problem is that when switching back from protected mode to 
 real mode, and switching back to 16 bit code, the switch back to 16 bit 
 code doesn't always work. As noted in the comment in the code, the 
 reason for this is unknown.
 
 BIOS calls are wrapped with code to switch to real mode before entering 
 the BIOS, and back to protected mode afterwards. The results of entering 
 the BIOS in the wrong CPU mode are, well, undefined and vary wildly 
 between machines. On my EPIA board this would range from a simple hang 
 through clearing the screen to reconfiguring the video to display text 
 in strange sizes and colours.
 
 The branches and nops that I put in worked around the problem 
 sufficiently that my board booted using biosboot. I subsequently 
 discovered that less common cases still don't work. Booting single-user, 
 for example, caused my board to fail. pxeboot didn't work, and some 
 people reported that dosboot didn't work.
 
 I had speculated that this may be a CPU bug. I'm now starting to wonder 
 whether the BIOS is enabling more caches than we're expecting.
 
 -- 
 Gillette - the best a man can forget