Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2003 08:30:33 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        Walter <wjontofs@berkom.de>, <freebsd-hardware@FreeBSD.ORG>
Subject:   RE: can't boot/install freebsd from cdrom/floppy - serverworks g
Message-ID:  <20030114080356.J14218-100000@gamplex.bde.org>
In-Reply-To: <XFMail.20030113143538.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Jan 2003, John Baldwin wrote:

> On 13-Jan-2003 Walter wrote:
> > i've problems installing freebsd on System with ServerWorks GC SL -Chipset,
> > Pentium 4, LSI Logic MPT (53c1030) SCSI-Controller
> >
> > Booting with floppy kern.flp from 4.7-release, not even the bootstrap loader
> > works, then i tried from 5.0rc3 - i got
> >
> > fatal trap 10: trace trap while in vm86 mode
> > instruction pointer=0xf000:0xf842
> > stack pointer  = 0x0:0xff8
> > frame pointer  = 0x0:0x0
> > code segment   = base 0x0, linit 0x0, type 0x0
> >                        = DPL 0, pres 0, def32 0, gran 0
> > processor eflags = interupt enabled, vm86 IOPL = 0
> > current process        = 0 ()
> > trap number   = 10
> > panic: trace trap
> > Uptime: 1s
> >
> > I thought probably  a hardware failure,
> >  but i tried to install Linux Redhat 8.0, without problems ?!
> >
> > Any hints ?

Try setting hw.hasbrokenint12 in the loader.

> You have a buggy BIOS it seems.  I'm not sure why you are getting
> that kernel trap though.  That is a really weird trap.

int 0x12 is reported to be broken for some new BIOSes.  I think the
bug is just that getmemsize() uses vm86_intcall(0x12, ...) before
enough is initialized for vm86_intcall(0x12, ...) to work.  It's not
clear what is needed for it to work, but getmemsize() clearly doesn't
do enough in RELENG_4 -- it doesn't map pages into the vm86 page table.
Old BIOSes implement int 0x12 by just returning the result of reading
the word at 0x40:0x13 or thereabouts.  I'm not sure how even that much
worked (do we map the first page specially?).  Newer BIOSes may well
do much more complicated things.  Hopefully there is a standard that
prevents them arbitrarily using things that don't work in vm86 mode.

Rev.1.544 has some too-large changes which attempt to fix this
automatically, but it caused panics and was replaced by simpler changes
and a non-automatically set loader flag in rev.1.549.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030114080356.J14218-100000>