Re: [Etherboot-developers] Windows 98 slow booting

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On Thu, 19 Sep 2002, Michael Brown wrote:
> > > > > > don't have time to hack on Etherboot at the moment.  However, if
> someone
> 
> > > > > > can tell me why, on some machines, Windows 98 takes forever (45 mins+)
> to
> 
> > > > > > start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> 
> > > > > > regain some spare time. :-)
> > > > > BIOS Bug.  Almost certainly.  All we do is return to the BIOS.
> > > > > Unless there is something we don't reset to it's original state?  Some
> > > > > bits of test code (Returning ealier to the BIOS) could identify if
> > > > > whatever it is has changed yet, so it should be trackable.
> > > > Thanks; that's confirmed what I thought would be the best debug strategy.
> > > > It's certainly a BIOS or hardware-specific problem; it will happen on a
> > > > batch of machines of the same hardware type.  We tried looking at Windows
> > > > 98's idea of a diagnostic boot log, but gave up when we found it contained
> 
> > > > only six (unhelpful) lines.
> > > I thought of one other possibility to try.  We might be stomping BIOS tables
> 
> > > if etherboot is loading to high.  Setting RELOCADDR lower might be worth
> > > a shot.
> > Will try, thanks.
> > > Which vesion of etherboot does the crawl show up with?
> > 5.0.7.  I did send a floppy of 5.1 to be tried, but it wouldn't even load
> > up.  I won't find out any more until one of the problematic machines gets
> > delivered to me for testing.
> 
> Now that I've finally got one of the said problematic machines, I've found
> the problem.  gateA20_unset() is not called before returning to the BIOS.
> On this machine (and some others), if the BIOS is set to "Fast Gate A20"
> then this is sufficient to cause Windows 98 to take around 45 minutes to
> boot up.
> 
> We call gateA20_unset() on some exit paths but not all.  The proper
> solution would probably be to have a static inline void eb_exit(int) that
> calls gateA20_unset() (and maybe some other last-minute tidy-ups) before
> doing an exit().  All existing calls to exit() should then be replaced
> with calls to eb_exit().  However, I'm not sure that I completely
> understand all the places where exit() is currently used in Etherboot, so
> I'm not confident in doing this.  For example, in main.c we have:
>                 case 255:
>                         exit(0);
>                         state = -1;
>                         break;
> i.e. code following an exit(), which is puzzling me.

A sanity check in case the code ever gets there.  It won't but...
 
> Thoughts?

I hadn't picked up on this as a problem before, but it makes
sense that someone should have trouble with the a20 line settings. 

This is tricky.  We cannot reenable the a20 line on all paths out of
etherboot.  Anything with a 32bit entry point expects the a20 line
to be already enabled.  

But probably for all code with a 16bit entry we need to do this,
along with the case when we return to the BIOS.  Ken is this correct?
I wonder if this explains the DOS failures.

The really trick part is we need to be very careful where
we reenable the a20 line.  For 5.0.x it isn't a problem to
do it whenever as we live below 1MB.  For 5.1.x doing at the wrong
time could kill us.  So for 5.1.x we need to ensure the renabling
of a20 is in the trampoline that calls 16bit code.

BIOS calls do not have a problem with the a20 line enabled do they?

Eric