From owner-freebsd-stable@FreeBSD.ORG Fri Oct 20 09:07:30 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D0B16A403; Fri, 20 Oct 2006 09:07:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 667BD43D45; Fri, 20 Oct 2006 09:07:30 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GaqLh-000NMr-Hq; Fri, 20 Oct 2006 11:07:29 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Bruce M. Simpson" In-reply-to: Your message of Fri, 20 Oct 2006 03:06:59 +0100 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Oct 2006 11:07:29 +0200 From: Danny Braniss Message-ID: Cc: CyberSans AirBort , freebsd-stable@freebsd.org, John Baldwin Subject: Re: bug on BTX X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2006 09:07:31 -0000 > Hi all, > > FYI, this change adds 32 bytes to btx leaving 139 bytes free, according > to btxld(8). As you probably all know, and just as a reminder, size in > boot2 is at a premium -- it can't go over 8192 bytes as this is the > boot-sector limit in the BSD disk-label. > > Dominic Marks wrote: > > John Baldwin wrote: > >> > >> Hmm, are you willing to test a change that should fix that? If so, > >> try http://people.freebsd.org/~jhb/patches/btx_crx.patch You'll need > >> to do a 'make clean && make && make install' in /sys/boot after > >> applying, and if the make install suceeeds, do a 'bsdlabel -B ad0s1' > >> (replace ad0s1 with the actual slice you boot from). I think it > >> should work (I think it was tested a while ago, but boot2 used to not > >> fit, now it does though). Be warned though that if it doesn't work, > >> you won't be able to boot from your disk. If that happens and you > >> have a 6.x disc 1 lying around, you can boot into rescue mode and > >> re-run 'bsdlabel' and move boot/loader.old to boot/loader on the root > >> partition to get your system back. Ideally you'd try this on a > >> system with data you don't care about (i.e., it's ok to just do a > >> reinstall if it is hosed). > > It would be a good thing to solve the real mode problem, as it would > enable FreeBSD to be booted from memory stick, USB CDROM, and within > QEMU without resorting to the current workarounds e.g. using GRUB or > skipping /boot/loader entirely to boot the kernel directly as I > currently do in QEMU virtualization. > > It's pretty important in the big scheme of things as it helps to bring > FreeBSD to a wider audience. Many people out there may well have run > into this without > > Indeed I recently ran into this myself. Certain 1U machines which I > acquired had problems booting from USB CDROM. I traced this back to the > USB BIOS trying to LGDT and causing a general protection fault in vm86 > mode. I worked around this by PXE booting them on a private VLAN with > most helpful assistance from dwhite@. > > The long term solution we've been discussing is to change btx to > trampoline into real mode before invoking certain INTs. I've been doing > some tests with QEMU and Etherboot; it looks like its PXE UNDI driver > sets up the NIC interrupt vector *before* BTX is called; it does not > call LIDT in any of its paths. Its PXE entry point does however call > LGDT to enter protected mode which of course kills BTX stone dead as > we're in vm86 mode at that point. > > Per my IRC discussions with jhb@ : given that BTX reflects the hardware > interrupts, we shouldn't need to reprogram the AT-PICs; indeed GRUB does > not. This was one of his concerns. We can probably get away with a > simple trampoline a la GRUB providing the INTs invoked by BTX or LOADER > don't attempt to rewrite or redirect interrupt vectors once we're up and > running. > > If time permits I may try to make the changes to BTX myself, however, I > am always happy to review patches and provide feedback with a view to > getting the problem solved going forward. > > Best, > BMS we encountered the same problem when trying to boot pxe the PCEngines/WRAP so if you need testers, i'm willing. danny