|Summary:||[boot] BTX 1.02 crashes on boot|
|Product:||Base System||Reporter:||Renato <renato.camarao>|
|Component:||i386||Assignee:||freebsd-i386 (Nobody) <i386>|
|Severity:||Affects Only Me||CC:||chance.fulton, imp, mobrien118, pi, zarychtam|
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. 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.
Comment 1 Mark Linimon 2010-10-01 01:21:25 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-i386 reclassify.
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 2011-06-09 12:02:14 UTC
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 <firstname.lastname@example.org>
Comment 4 Guido Falsi 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 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 <email@example.com>
Comment 5 Guido Falsi 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 <firstname.lastname@example.org>
Comment 6 Guido Falsi 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 <email@example.com>
Comment 7 Guido Falsi 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 0xe820. This BIOS function is, I think, doing something nasty which locks up the system. -- Guido Falsi <firstname.lastname@example.org>
Comment 8 Guido Falsi 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 difference. On the 8005Pro the BIOS works with the cr 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 <email@example.com>
Comment 9 Guido Falsi 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 <firstname.lastname@example.org>
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? -Scott
Comment 11 Eitan Adler 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 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 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 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 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 Version: 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 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').