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 [EMAIL PROTECTED]
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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
