From owner-freebsd-current Wed Oct 2 7:22:16 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 1208237B401 for ; Wed, 2 Oct 2002 07:22:14 -0700 (PDT) Received: from tasogare.imasy.or.jp (tasogare.imasy.or.jp [202.227.24.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67BD43E6E for ; Wed, 2 Oct 2002 07:22:11 -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 g92ELqY10663; Wed, 2 Oct 2002 23:21:52 +0900 (JST) (envelope-from iwasaki@jp.FreeBSD.org) Date: Wed, 02 Oct 2002 23:21:45 +0900 (JST) Message-Id: <20021002.232145.29470044.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: <20021002214819.W362-100000@gamplex.bde.org> References: <20020930.234044.43000637.iwasaki@jp.FreeBSD.org> <20021002214819.W362-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, > > > 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