I want to install FreeBSD on this machine (HP) and when I boot, it stops on message below: Attempting Boot From CD-ROM CD Loader 1.2 Building the boot loadar arguments Looking up /BOOT/LOADER... found Relocating the loader and the BTX Starting the BTX loader _ BTX loader 1.00 BTX version is 1.02 Note the cursos blinking upon the last phrase. Keyboard not answer my calls. I test too plugging a pendrive with FreeBSD without success, having the same results. For suspects from chipset and SATA controllers, i've changed some settings on BIOS (SATA emulator: RAID, IDE Native, IDE "Legado" and SATA) and all of changes has the same result. I've tested others FreeBSD (the LiveCD ones) and I make it boot, but the FreeBSD's version was 4.3 and I need the last one (8.1). I note that LiveCD's BTX version was 1.01. So I downloaded others old versions that has the same version and works too (every old FreeBSD's has the same BTX version 1.01). I tried to mix the loader of the old boot to the new boot, without success. The message was "BTX halted". I think that is not the right way to do this. Fix: To fix the problem is study the case and fix. I'm not developer, so I can't help you. How-To-Repeat: Just boot the newer versions of FreeBSD that has BTX loader 1.02 on HP Compaq 6005 Pro Microtower to view the message.
Responsible Changed From-To: freebsd-bugs->freebsd-i386 reclassify.
I have two of these systems. Updated the system BIOS to the latest from HP and still no luck. I'm a software developer and interested in at least helping troubleshoot this problem. George Morgan
Hi, I'm also getting this problem on the same hardware. I compiled a loader binary with BTXLDR_VERBOSE defined. I have no experience with ASm programming, and know very little about PC booting process internals, so I don't know if I'll be able to do much better about this. I'll anyway keep looking. For now I'm sending the output from the verbose loader when trying to boot with a USB umass device just in case someone can understand something from this: -------- Attempting Boot From USB Device _ BTX loader 1.00 Starting in protected mode (base mem=9f800) Arguments passed (esp=9e78c): <howto=80000000 bootdev=a050001e junk=0 0 0 bootinfo=df34> Relocated bootinfo (size=48) to 9f7b8 Relocated arguments (size=18) to 9f7a0 BTX version is 1.02 Relocated kernel (size=690) to 9000 Client base address is a000 Client format is ELF text segment: offset=1000 vaddr=0 filesz=2f8bc memsz=2f8bc data segment: offset=31000 vaddr=30000 filesz=5568 memsz=c7e0 Loading complete --------- This is the screen just after locking up. The cursor at this point goes in the second line(where the _ is) and keeps blinking there. (the first line is oviously from the BIOS, but I included it for completeness) Thanks in advance for any help! -- Guido Falsi <mad@madpilot.net>
I performed some more testing following suggestions from John Baldwin. Inserting simple loops in btxldr (foo: jmp foo) made the system hang anyway, even when adding the loop as first statement in btxldr. It looks like something times out, but this is just a conjecture. I tested booting the kernel directly from boot2, bypassing loader, as described in boot(8) and got this erro from BTX: / FreeBSD/x86 boot Default: 0:ad(0,a)/boot/loader boot: 0:da(0,a)/boot/kernel/kernel-_ int=00000006 err=00000000 efl=00010002 eip=23ec42c6 eax=0018e070 ebx=00000000 ecx=00000000 edx=a0500004 esi=ffff6000 edi=0018e070 ebp=000003fa esp=00210608 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff es:esp=d9 03 00 00 00 00 00 00-00 00 00 00 00 00 20 00 40 00 60 00 8d 64 24 00-55 4e 44 49 16 1d 00 00 BTX halted (-_ should be in the same spot. - is the spinning thing, _ is the cursor) After this I start thinking that real blame should go on boot2, loader being just a victim. I'm trying to figure out how boot2 works, but it's a whole new world to me. -- Guido Falsi <mad@madpilot.net>
More information I collected. I tested with old install CDs. 7.0 and 6.3 do work. 7.1 and 6.4 do show this problem. This is when BTX version bump to 1.02 was MFCed. -- Guido Falsi <mad@madpilot.net>
I started putting while(1) cycles through loader/main.c and found out the lockup happens in bios_getmem(). One of the BIOS routines called from in there is causing problems. -- Guido Falsi <mad@madpilot.net>
After more debugging I discovered That lockup is happening in loader when calling bios_getmem(). In there the system lockup just after calling BIOS int 0x15 function 0xe820. This BIOS function is, I think, doing something nasty which locks up the system. -- Guido Falsi <mad@madpilot.net>
By disassembling the BIOS function mentioned above in this PC and another HP one on which FreeBSD hass no problems I could find one main difference. On the 8005Pro the BIOS works with the cr[034] and MSR control registers, while in another BIOS the function is performed without touching those. Reading the history of BTX in cvs I see the old BTX 1.01 used to emulate such accesses through exceptions, the new one gives full control to the BIOS so I'm quite lost on why there should be such a regression. I have the disassebled code which modifies the CRs if nyone should need to look at it. (Not sure about policies for posting such things on gnats so I play it safe) -- Guido Falsi <mad@madpilot.net>
Just a quick followup to note the following: Problem still happens in 8.2 with a newer BIOS (1.15). Tested with 9.0-RC1(both with same BIOS as before(1.12) and the last one) and with this version of the system I get a reboot instead of a lockup. The point of lockup is the same, when calling BIOS int 0x15 function 0xe820. As an additional reference the hang/reboot happens in file /usr/src/sys/boot/i386/libi386/biosmem.c, line 63. svn of /usr/src is 226679, revision of the mentioned file is 200219. -- Guido Falsi <mad@madpilot.net>
This still appears to be broken in 9.1, has anyone an update on a work around / resolution? -Scott
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Still unresovled for 11.2 and 12-CURRENT. GRUB2 could be used to boot FreeBSD as a workarround.
We've done a lot with BTX since 9.x, so I'm going to close this bug as fixed. If there's still an issue with FreeBSD 11 or 12, please file a new bug and cc me so we can work through this issue. This specific bug has been fixed for other users.
(In reply to Warner Losh from comment #13) This specific to HP Compaq 6005 Pro bug hasn't been resolved yet. I am running FreeBSD 12 and 13 on this workstation thanks to GRUB2 boot loader. The workstation can be booted neither from official 12.0-RELEASE nor 11.2-RELEASE CD. This bug is relevant to old, almost depreciated hardware so IMHO it likely could be closed, but it's far from being fixed.
This is still a bug. I'll reopen this one (since there's a decent amount of information about it).
Can someone that has this problem add kenv of a booting system as an attachment to this bug. There's indications in this that the 15/E820 call here is the problem, and there's a quirk for distrusting the e820 call data for extmem. Maybe we can fix this with a quirk to just avoid the e820 call entirely since it's buggy for the environment we assume....
Rather modest kenv output when the kernel is loaded by Grub2, only device hints, vfs.root.mountfrom and a few another setting available. To gather more information I tried to boot this PC from FreeBSD 7.0-RELEASE CD (amd64) which was due to work but also failed to boot kernel getting the error: panic: No BIOS smap info from loader! Some time ago I have submitted dmesg output here: https://dmesgd.nycbug.org/index.cgi?do=view&id=3791
Created attachment 200998 [details] output from dmidecode
Created attachment 200999 [details] pciconf -lvbc output
Ah, perfect. Handle 0x0002, DMI type 1, 27 bytes System Information Manufacturer: Hewlett-Packard Product Name: HP Compaq 6005 Pro MT PC Version: has what I need, I think.
I'm trying to boot FreeBSD 11.2-RELEASE-P10 on this HP 6005 SFF machine as well. I can say it still hangs at the BTX loader. The specific release comes from Pfsense 2.4.5 and will not boot off of USB or from an SSD.
It is kind of crazy that this almost 10 year old bug hasn't been solved yet. Especially since this report provides very specific instruction level information on where the bug is occurring. Double especially since this affects a decent number of PCs. Triple especially since there are hundreds of forum posts around the internet of people experiencing this same issue on the same hardware and eventually resolving to "just give up". I have this PC and I'm trying to install FreeNAS-11.3-U3.2 on it and experiencing this bug. I'm happy to test a fix if anyone wants to give a fix a shot. Unfortunately, I'm not an OS dev, nor an I a BSD superuser (Linux, I'm pretty handy with) and I don't have too much time to pick up any of those hobbies. Anyway, just thought I would offer my help - this seems like one of those things that would be "cool" is it was fixed after all this time.
I've wanted to find some way to recreate this, maybe with a bouncer box access... These are all highly specific bugs (maybe more than one is in play too, since this should be read as no more specific than 'core dump').
(In reply to Warner Losh from comment #23) I still have PC working as my daily desktop affected by this bug. I am booting it with Grub2, but can help to provide what is required to help with fixing this.
FreeBSD 14.2 still not booting.. I tried cd, DVD, memstick. It hangs after BTX loader 1.00 BTX version is 1.02 message.
(In reply to Igor Zubkov from comment #25) I doubt it will ever be fixed. I think the PCs affected are relatively old now, unless it has reemerged in newer hardware.
So i think this big is for BIOSes that don't support packet mode. But without access to an affected machine, it will be hard to make progress.
Looking on ebay for a machine that matches the DMIDECODE output is no joy for me. I can find plenty of the AMD Athlon II or Phenom II, but none with a Penitum II in it. This is related to a rather major rewrite of the BTX loader / executive and the VM86 interface. That's beyond my x86 knowledge, at least what's paged into my head. So I'm doubtful I'd be able to find / fix this if I did a deep-dive looking for it.
(In reply to Warner Losh from comment #28) My HP Compaq 6005 Pro SFF has an Athlon II X2 and, as far as I understand, was never shipped with a Pentium II. I was very surprised that this bug is in the i386 branch, because it is incorrect. I think we need to move it to amd64. Maybe this way the bug can be fixed