Date: Tue, 22 Oct 2002 00:35:12 +0900 (JST) From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> To: bde@zeta.org.au Cc: current@FreeBSD.ORG Subject: Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation Message-ID: <20021022.003512.15273101.iwasaki@jp.FreeBSD.org> In-Reply-To: <20021002.232145.29470044.iwasaki@jp.FreeBSD.org> References: <20020930.234044.43000637.iwasaki@jp.FreeBSD.org> <20021002214819.W362-100000@gamplex.bde.org> <20021002.232145.29470044.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
> >
> > Where does the panic occur? I checked that there is no problem here if
> > the result of INT 0x12 is ignored and basemem is set to 0.
>
> panic messages attached. It seems to be within BIOS routine after reti
> jumped from vm86_bioscall.
> Strangely, this panic can be recovered by continue command in DDB,
> FreeBSD continues its boot process after this. So, this panic problem
> is not serious for me :)
> OTOH, the same problem in boot program is very critical, completely stops
> with register dump...
FYI: On RELENG_4, this problem is critical too because this panic
isn't recoverable. This means that it's impossible to install onto
some newer machines.
> > > 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).
> >
> > I would first fix all the broken code that doesn't check for errors
> > and see if the problem goes away. Then recover any low memory not
> > reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c,
> > like libi386/biosmem.c does it (I think machdep.c intentionally skips
> > the low memory, while biosmem.c tries to find it).
>
> Cool. Thanks!
>
> Stopped at 0xf842:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xf842
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc03b5108
> stack pointer = 0x10:0xc0a68e90
> frame pointer = 0x10:0xc0a68e94
> code segment = base 0x0,limit 0xfffff, type 0x1b
> = DPL 0, press 1, def32 1, gran 1
> processor eflags = resume,IOPL = 0
> current process = 0 ()
> kernel:type 12 trap,code=0
> db> t
> Fatal trap 12: page fault while in kernel mode
I've recalled that FreeBSD used RTC to determine base memory size in
old days. I've tested this method on my machines and confirmed it's
working well.
I'll commit this coming weekend if no objections.
Thanks
Index: machdep.c
===================================================================
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- machdep.c 5 Oct 2002 14:36:14 -0000 1.541
+++ machdep.c 21 Oct 2002 15:27:02 -0000
@@ -1284,8 +1284,14 @@
/*
* Perform "base memory" related probes & setup
*/
- vm86_intcall(0x12, &vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)<<8)) > 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, &vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem > 640) {
printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
basemem);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021022.003512.15273101.iwasaki>