Date: Fri, 20 Oct 2006 11:07:29 +0200 From: Danny Braniss <danny@cs.huji.ac.il> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: CyberSans AirBort <cybersans@gmail.com>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: bug on BTX Message-ID: <E1GaqLh-000NMr-Hq@cs1.cs.huji.ac.il> In-Reply-To: Your message of Fri, 20 Oct 2006 03:06:59 %2B0100 .
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1GaqLh-000NMr-Hq>