Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 May 1999 20:44:31 -0500
From:      Jonathan Lemon <jlemon@americantv.com>
To:        "Carlos C. Tapang" <ctapang@easystreet.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: FBSDBOOT.EXE
Message-ID:  <19990518204431.15136@right.PCS>
In-Reply-To: <00b201bea18a$93afbfc0$0d787880@apex.tapang>; from Carlos C. Tapang on May 05, 1999 at 05:00:16PM -0700
References:  <00b201bea18a$93afbfc0$0d787880@apex.tapang>

next in thread | previous in thread | raw e-mail | index | archive | help
On May 05, 1999 at 05:00:16PM -0700, Carlos C. Tapang wrote:
> >
> >In a nutshell, there is a table of interrupt vectors which is set
> >by the BIOS at boot time, which are used by the loader (and by the
> >FreeBSD kernel, if VM86 is turned on).
> >
> Thanks, Jonathan. Are any of the following TRUE?
> 1. FreeBSD is affected by these vectors only if VM86 is turned ON.

Um, I would say that is true.   Robert Nordier or Mike Smith may want
to step in here and correct me as to what the loader is doing, but 
I think the kernel only uses the interrupt vectors if VM86 is on.


> 2. If somebody is using VM86, s/he must be using DOSEMU or some other DOS
> emulator also (I can't think of anything else one would use VM86 for).

Not true.  VM86 is also required to support VESA.  Also, it is used
for reliable memory detection (which is why I want to make it mandatory).
No more "My Stinkpad only detected 64M, what do I do now??!" questions.


> 3. DOSEMU or any other DOS emulator re-initializes the DOS vectors for
> virtualization.

True - ``doscmd'' has a virtual copy of the vectors that it initializes
itself, and doesn't use the actual DOS vectors at all.


> Basically, what I am guessing is that probably we can fix the problem during
> vm86 or DOSEMU initialization. I am going to enable vm86 on my system and
> see what happens. Right now I am not experiencing any problems, and that's
> probably because I do not have vm86 enabled.

The problem only comes into play during case 2; where the kernel actually
calls the BIOS.  The difficulty is that while FBSDBOOT.EXE may work in some
cases, it is not guaranteed to work in _all_ cases (which causes a support 
nightmare).
--
Jonathan


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?19990518204431.15136>