Bug 151122 - [boot] BTX 1.02 crashes on boot
Summary: [boot] BTX 1.02 crashes on boot
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: i386 (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-i386 (Nobody)
Depends on:
Reported: 2010-09-30 18:50 UTC by Renato
Modified: 2021-06-25 14:56 UTC (History)
6 users (show)

See Also:

output from dmidecode (21.54 KB, text/plain)
2019-01-10 21:01 UTC, Marek Zarychta
no flags Details
pciconf -lvbc output (8.51 KB, text/plain)
2019-01-10 21:08 UTC, Marek Zarychta
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Renato 2010-09-30 18:50:01 UTC
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.


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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-10-01 01:21:25 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-i386

Comment 2 gm.swdev 2011-05-25 22:43:03 UTC
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
Comment 3 Guido Falsi freebsd_committer 2011-06-09 12:02:14 UTC

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

Thanks in advance for any help!

Guido Falsi <mad@madpilot.net>
Comment 4 Guido Falsi freebsd_committer 2011-06-10 10:57:48 UTC
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

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>
Comment 5 Guido Falsi freebsd_committer 2011-06-13 13:49:06 UTC
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>
Comment 6 Guido Falsi freebsd_committer 2011-06-13 14:57:25 UTC
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>
Comment 7 Guido Falsi freebsd_committer 2011-06-13 16:36:04 UTC
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

This BIOS function is, I think, doing something nasty which locks up the system.

Guido Falsi <mad@madpilot.net>
Comment 8 Guido Falsi freebsd_committer 2011-06-17 15:46:39 UTC
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

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>
Comment 9 Guido Falsi freebsd_committer 2011-10-25 14:37:42 UTC
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>
Comment 10 scott.mraz 2013-09-27 20:38:07 UTC
This still appears to be broken in 9.1, has anyone an update on a work
around / resolution?

Comment 11 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:55 UTC
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
Comment 12 Marek Zarychta 2018-07-29 12:33:24 UTC
Still unresovled for 11.2 and 12-CURRENT. GRUB2 could be used to boot FreeBSD as a workarround.
Comment 13 Warner Losh freebsd_committer 2019-01-08 19:05:04 UTC
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.
Comment 14 Marek Zarychta 2019-01-10 09:44:23 UTC
(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.
Comment 15 Warner Losh freebsd_committer 2019-01-10 16:05:58 UTC
This is still a bug. I'll reopen this one (since there's a decent amount of information about it).
Comment 16 Warner Losh freebsd_committer 2019-01-10 16:12:13 UTC
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....
Comment 17 Marek Zarychta 2019-01-10 20:54:16 UTC
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
Comment 18 Marek Zarychta 2019-01-10 21:01:44 UTC
Created attachment 200998 [details]
output from dmidecode
Comment 19 Marek Zarychta 2019-01-10 21:08:43 UTC
Created attachment 200999 [details]
pciconf -lvbc output
Comment 20 Warner Losh freebsd_committer 2019-01-10 22:09:56 UTC
Ah, perfect.
Handle 0x0002, DMI type 1, 27 bytes
System Information
	Manufacturer: Hewlett-Packard
	Product Name: HP Compaq 6005 Pro MT PC

has what I need, I think.
Comment 21 chance fulton 2020-04-02 03:51:56 UTC
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.
Comment 22 mobrien118 2020-06-22 22:33:19 UTC
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.
Comment 23 Warner Losh freebsd_committer 2020-06-23 00:10:56 UTC
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').
Comment 24 Marek Zarychta 2021-06-25 14:56:09 UTC
(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.