Re: bug on BTX
Hi all, Bruce M. Simpson wrote: 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. [...] 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] [...] Is there any progress in fixing FreeBSD bootloader to be able to boot from USB devices? Any patches available which can I test? Or are there any possible workaround to make FreeBSD bootable from USB flashdrive in any machine? (I can boot from USB flashdrive and USB DVD-RW on my home PC and notebook, but can not boot HP DL140 and Sun Fire X2100 servers ;[) Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
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 we encountered the same problem when trying to boot pxe the PCEngines/WRAP so if you need testers, i'm willing. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
Bruce M. Simpson wrote: [...] 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] I can confirm this problem. I can boot from DVD-RW in external enclosure (USB 2.0) on my desktop PC and few others I tested in the past, but can not boot any FreeBSD release on servers in collocation (from the same external DVD-RW). Tested with some Asus server boards and 1U Sun Fire X2100. But these machines can boot from another boot CD I have (Hirens Boot CD, RIP Linux, Ultimate Boot CD, OpenBSD) I'll be happy if this can be solved in some feature release of FreeBSD, because I managed many servers without internal CD/DVD drive. I do not understand this part of system well, but let me know if I can provide some more information about systems where I can boot well or where I can not boot FreeBSD from USB CD / DVD. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On Thursday 19 October 2006 22:06, Bruce M. Simpson wrote: 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. My other changes trim btx by 48 bytes. I actually plan on MFC'ing this stuff into 6.2. We actually have 100+ free bytes in boot2 right now anyways. 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. BTX currently uses different IDT offsets for the PICs, it puts them right next to each other instead of using 0x70-0x78 (IIRC) for the slave PIC. That can be adjusted though to make BTX use the same IDT offsets as the BIOS in which case we wouldn't have to touch the PIC at all. That would require a larger IDT though, and I'm not sure if the IDT is statically allocated in BTX (if so, it might result in a space problem), however reusing the BIOS IDT offsets would be preferable to re-programming the PICs on every mode switch. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
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]
Re: bug on BTX
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). Hi John. I tested the patch on my -CURRENT box, both with the BIOS DMA enabled and disabled and I can confirm it works successfully. Test system is was a Compaq EVO D510 CMT desktop. Thanks John, -- Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On Friday 22 September 2006 10:39, Dominic Marks wrote: CyberSans AirBort wrote: hello guys, sorry if i send email to wrong address. i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. like previous version, it stucks when booting from cd on the first installation. i have follow so many discussion around the internet, and they are blaming compaq BIOS, some of them give solution such as change hdd mode from extended DMA to max PIO, but it won't work. and for your information, this machine had no problem when installed with windows or linux. please guys, i hope there will be a fixed on 6.2 so that it will load, installed, and run on my compaq evo desktop Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. ** I can't remember the exact name of the option, but it is something along those lines. 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). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On Friday 22 September 2006 11:46, dick hoogendijk wrote: On 22 Sep Dominic Marks wrote: CyberSans AirBort wrote: i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. Because other OS's run the BIOS in real mode, and we run it in vm86 mode and we don't emulate enough instructions in vm86 mode for the Compaq/HP BIOS. See my other e-mail. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
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). Certainly. I'll try this out tomorrow and let you know how it goes. I have a machine running -CURRENT which can be used as guinea pig. Thanks John. -- Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
hello dominic. sorry for not updating. actually i have solve that matter. 1. changing the HDD from western digital to maxtor 2. change the BIOS DMA transfer inside the bios. and now it works and my freebsd running fine. thank you for your email. see ya cybersans Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. ** I can't remember the exact name of the option, but it is something along those lines. Enjoy, Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
CyberSans AirBort wrote: hello guys, sorry if i send email to wrong address. i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. like previous version, it stucks when booting from cd on the first installation. i have follow so many discussion around the internet, and they are blaming compaq BIOS, some of them give solution such as change hdd mode from extended DMA to max PIO, but it won't work. and for your information, this machine had no problem when installed with windows or linux. please guys, i hope there will be a fixed on 6.2 so that it will load, installed, and run on my compaq evo desktop Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. ** I can't remember the exact name of the option, but it is something along those lines. Enjoy, Dominic thank you cybersans ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On 22 Sep Dominic Marks wrote: CyberSans AirBort wrote: i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. -- dick -- http://nagual.nl/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 6.1 +++ Solaris 10 6/06 ++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
dick hoogendijk wrote: On 22 Sep Dominic Marks wrote: CyberSans AirBort wrote: i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. Agreed. A very low priority however since it is so easy to work around. Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On Fri, 22 Sep 2006 17:46:49 +0200 dick hoogendijk [EMAIL PROTECTED] wrote: Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. What about filing a PR http://www.freebsd.org/send-pr.html, so the problem gets documented and eventually fixed? -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
