Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jan 2003 17:58:02 +0100
From:      Walter Jontofsohn <wjontofs@berkom.de>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        freebsd-hardware@freebsd.org
Subject:   Re: can't boot/install freebsd from cdrom/floppy - serverworks g
Message-ID:  <200301231758.02390.wjontofs@berkom.de>
In-Reply-To: <20030114080356.J14218-100000@gamplex.bde.org>
References:  <20030114080356.J14218-100000@gamplex.bde.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 bootstr=
ap
> > > loader works, then i tried from 5.0rc3 - i got
> > >
> > > fatal trap 10: trace trap while in vm86 mode
> > > instruction pointer=3D0xf000:0xf842
> > > stack pointer  =3D 0x0:0xff8
> > > frame pointer  =3D 0x0:0x0
> > > code segment   =3D base 0x0, linit 0x0, type 0x0
> > >                        =3D DPL 0, pres 0, def32 0, gran 0
> > > processor eflags =3D interupt enabled, vm86 IOPL =3D 0
> > > current process        =3D 0 ()
> > > trap number   =3D 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.

this means 'set hw.hasbrokenint12' ? if yes, the  result is unfortunately=
 the=20
same as above, if no, how should i do this ?
Further down you write, that the loader doesen't get the correct memsize,=
 is=20
it possible/useful to hand over the memory size (or is this for vm86=20
special?)

best regards,

Walter Jontofsohn


>
> > 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?200301231758.02390.wjontofs>