From owner-freebsd-current Mon Sep 30 7:41:26 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E61E737B401 for ; Mon, 30 Sep 2002 07:41:23 -0700 (PDT) Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2F043E6E for ; Mon, 30 Sep 2002 07:41:20 -0700 (PDT) (envelope-from iwasaki@jp.FreeBSD.org) Received: from localhost (iwa@tasogare.imasy.or.jp [202.227.24.5]) by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id g8UEetY95291; Mon, 30 Sep 2002 23:40:55 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Mon, 30 Sep 2002 23:40:44 +0900 (JST) Message-Id: <20020930.234044.43000637.iwasaki@jp.FreeBSD.org> To: bde@zeta.org.au Cc: current@FreeBSD.ORG Subject: Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation From: Mitsuru IWASAKI In-Reply-To: <20020930115717.J43806-100000@gamplex.bde.org> References: <20020930.070003.70227125.iwasaki@jp.FreeBSD.org> <20020930115717.J43806-100000@gamplex.bde.org> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > > Index: sys/i386/i386/machdep.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > > retrieving revision 1.532 > > diff -u -r1.532 machdep.c > > --- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 -0000 1.532 > > +++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -0000 > > @@ -1269,8 +1269,12 @@ > > /* > > * Perform "base memory" related probes & setup > > */ > > - vm86_intcall(0x12, &vmf); > > - basemem = vmf.vmf_ax; > > + if (bootinfo.bi_basemem != 0) { > > + basemem = bootinfo.bi_basemem; > > + } else { > > + vm86_intcall(0x12, &vmf); > > + basemem = vmf.vmf_ax; > > + } > > if (basemem > 640) { > > printf("Preposterous BIOS basemem of %uK, truncating to 640K\n", > > basemem); > > The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't > start using it again now. It already uses the 0x15/0xe820 call for > everything except basemem (except when the this call fails, it falls > back to 0x15/0xe801). Maybe the bug has something to do with the > kernel using the 0x12 call without checking whether the call succeeded. > > When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel > falls back to an 0x15/0x88 call for determining extmem ... except this > is ifdefed out and replaced by looking at the rtc values. Maybe the > unreliability of the 0x15/0x88 call has something to do with not > checking if the call succeeded. Yes, I think the best way to determine base mem size in getmemsize() is to try 0x15/0xe820 call first, then fall back to 0x12 call. But I'm not sure whether it's OK to call vm86_datacall(0x15) before determining base mem size... > The patch makes no difference for booting directly from boot2 ... except > memsize() in boot2 also fails to check for errors, so it returns garbage > values. Yes I know that :-) But booting kernel directly from boot2 is not working at all for several years, so my understanding is that /boot/loader is necessary to boot kernel. > I think the basemem == 0 case should just work, so the systems with a > broken INT 0x12 should at worst lose 640K of memory, no matter whether > basemem is set to 0 because INT 0x12 fails or because it actually > returns 0. Hmmm, actually no. I know that some machines get panic with fatal trap 12 if we do 0x12 call. The worst case is getting panic, not losing 640K memory. And it seems that today's Linux don't have 0x12 calling any more, so I didn't see any problem on the machines. Now I have some ideas on this issue; - 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?) - 0x15/0xe820 call in locore.s before calling init386(). - specify the size by loader tunable (e.g. hw.basememsize). Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message