BTX loader hangs after version info

John Baldwin jhb at freebsd.org
Fri May 23 19:57:59 UTC 2008


On Friday 23 May 2008 09:26:45 am Kostik Belousov wrote:
> On Fri, May 23, 2008 at 08:29:09AM -0400, John Baldwin wrote:
> > On Friday 23 May 2008 07:53:11 am Kostik Belousov wrote:
> > > On Fri, May 23, 2008 at 01:22:55PM +1200, Mark Kirkwood wrote:
> > > > James Seward wrote:
> > > > >Hello,
> > > > >
> > > > >Two days ago I csup'd my desktop at home, which was running RELENG_7
> > > > >from about 7.0-RELEASE time, to bring it up-to-date (still on
> > > > >RELENG_7). I followed my usual buildkernel/world procedure (the usual
> > > > >one) which has worked fine all the way since 5.x. After installing
> > > > >kernel and restarting in single user, it was working fine. However,
> > > > >following installworld it will not boot.
> > > > >
> > > > >It stops immediately after "BTX loader 1.00 BTX version 1.02", but
> > > > >with the cursor on the line *above* the first "B". Nothing futher
> > > > >happens, but the system responds to Ctrl-Alt-Del.
> > > > >
> > > > >I have managed to start it using the install CD and csup'd back to a
> > > > >version just before the commit to BTX that moved it to 1.02 (March
> > > > >18th, I think). However, that version too hangs after "BTX loader 
1.00
> > > > >BTX version 1.01".
> > > > >
> > > > >My desktop is currently building RELENG_7_0 to see if that will work,
> > > > >but I won't know that until later as I'm at work and it is at home :)
> > > > >
> > > > >The install CD (BTX 1.00/1.01) boots fine. Nothing else changed on my
> > > > >system between the last successful boot and the unsuccessful one.
> > > > >
> > > > >Any suggestions/advice for what I can try next, or what I can do to
> > > > >help the troubleshooting process?
> > > > >
> > > > >My desktop is an Athlon64 but I am using i386, on an Asus A8V-E 
Deluxe
> > > > >board.
> > > >
> > > > FWIW - I am seeing this too, on a Supermicro P3TDDE. 7-STABLE src from
> > > > 28-Feb is fine, but Mar, Apr, May code all hangs after 
printing "loading
> > > > /boot/defaults/loader.conf" - presumably reading my /boot/loader.conf?
> > > >
> > > > Interestingly I can usually get it to boot by escaping to the loader
> > > > prompt and then just pressing return.
> > > >
> > > > Oddly some other machines (Supermicro P3TDER and Asus PRO31J Laptop)
> > > > behave normally with src from Mar->May.
> > > >
> > > > In all cases the canonical procedure from UPDATING was used 
(buildworld,
> > > > kernel, reboot single, mergemaster -p, installworld, delete-old,
> > > > mergemaster, reboot).
> > > >
> > > > I happy to help collect some debug info (how do you switch this on for
> > > > the loader?), tho the machine exhibiting the problem is my workstation
> > > > (of course)!
> > >
> > > Try to install new bootblock.
> > 
> > I would be wary of that as it might make things worse?  These problems are 
all 
> > from starting /boot/loader.  boot2 is still working fine and thus there is 
> > still the possiblity of using boot2 to load /boot/loader.old as a 
workaround.  
> > If you update boot2 and it breaks you can't fix that w/o booting off of 
some 
> > other media such as a CD.
> > 
> > Debugging these hangs is not easy to do remotely.  If you know assembly 
then 
> > there are some things you can play with.  For example, in the case where 
it 
> > hangs after printing out the BTX version (from btxldr.S) you could start 
> > adding debugging to btx.S to print out '.' characters in various places 
and 
> > see how many get printed out before it hangs.  However, doing this 
requires 
> > familiarity with assembly and is a lot easier with physical access to a 
box.
> 
> When I worked on my version of the realbtx, I sometimes experienced hangs 
when
> vm86 btx run before real-mode btx. I did not investigated it then, only 
noted
> the issue.

We could get a hang if a vm86 request was ever done with interrupts disabled 
for some reason.  I'll see if I can add some assertions to make BTX 
explicitly panic if that happens.

-- 
John Baldwin


More information about the freebsd-stable mailing list