From owner-freebsd-hardware Mon Jan 13 13:30: 5 2003 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A08437B401; Mon, 13 Jan 2003 13:30:03 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4961043EB2; Mon, 13 Jan 2003 13:30:02 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id IAA27161; Tue, 14 Jan 2003 08:29:54 +1100 Date: Tue, 14 Jan 2003 08:30:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin Cc: Walter , Subject: RE: can't boot/install freebsd from cdrom/floppy - serverworks g In-Reply-To: Message-ID: <20030114080356.J14218-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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