Date: Wed, 02 Oct 2002 23:21:45 +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: <20021002.232145.29470044.iwasaki@jp.FreeBSD.org> In-Reply-To: <20021002214819.W362-100000@gamplex.bde.org> References: <20020930.234044.43000637.iwasaki@jp.FreeBSD.org> <20021002214819.W362-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > > > 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. > > It mostly works. I submitted patches in a PR many years ago and still use > them. Great! I tried to find the PR, but couldn't find... Why isn't it committed yet? :-) > > 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... > > 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 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?20021002.232145.29470044.iwasaki>