Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jun 2011 11:45:07 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Guido Falsi <mad@madpilot.net>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: BTX loader problem on specific hardware
Message-ID:  <201106131145.08185.jhb@freebsd.org>
In-Reply-To: <20110613152653.GA82909@megatron.madpilot.net>
References:  <20110609152820.GC57263@megatron.madpilot.net> <201106091543.16028.jhb@freebsd.org> <20110613152653.GA82909@megatron.madpilot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, June 13, 2011 11:26:53 am Guido Falsi wrote:
> On Thu, Jun 09, 2011 at 03:43:15PM -0400, John Baldwin wrote:
> > On Thursday, June 09, 2011 11:28:20 am Guido Falsi wrote:
> > > Hi!
> > > 
> > > I'm having a problem with BTX hanging on an HP 6005 Pro PC.
> > > 
> > > I have filed a followup to an existing PR about this exact problem:
> > > 
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=151122
> > > 
> > > All the information there looks correct and stands true.
> > > 
> > 
> > Hmm, these are not so easy to debug.  You can try putting a 'foo: jmp foo'
> > instruction in various places as a sort of 'while (1)' loop.  The first test I 
> > would do is to put it earlier in btxld before the messages that BTXLDR_VERBOSE 
> > logs to see if when it hangs the cursor stays at its current location rather 
> > than jumping back up.  If that works out then you can start moving the 'foo: 
> > jmp foo' later until you find a point where it hangs and moves the cursor 
> > (which means it hung in between your previous 'jmp foo' and the one you most 
> > recently added).  I would start by walking down through btxldr.S.  If it makes 
> > it all the way through that, start walking through the BTX init code.
> > 
> > Oddly enough, BTX had to run at least once so that boot2 could find the loader 
> > and kick off the btxldr.S.
> 
> I found something performing the tests you suggested. I finally found out
> that it's loader triggering the lockup at it's very start.
> 
> System locks up in the first part of bios_getmem() when BIOS "int
> 0x15 function 0xe820" is called.
> 
> I noticed this is used here to get the memory map info from the
> BIOS. And this is not the first time there are memory map problems
> with HP BIOSes. :(
> 
> I'm trying to understand how to disassemble the bios code for that
> function, but I'm having some problems, do someone have any pointers to
> some how-to or help?

Ouch.  Well, these can be a PITA to disassemble.  ndisasm from the devel/nasm
port is a good x86 disassembler that you can use.  You will need to use dd
on /dev/mem to extract INT 15's entry point from the IDT.  For example:

# dd if=/dev/mem bs=4 iseek=0x15 count=1 | hd
1+0 records in
1+0 records out
4 bytes transferred in 0.000021 secs (190650 bytes/sec)
00000000  59 f8 00 f0                                       |Y...|
00000004

On this machine that gives a pointer of 0xf000:f859 which is a raw physical
address of '0xff859'.  You can then grab a block of that to disassemble like
so:

# dd if=/dev/mem bs=1 iseek=0xff859 count=100 | ndisasm -
00000000  EB00              jmp short 0x2
00000002  80FC87            cmp ah,0x87
00000005  7503              jnz 0xa
00000007  E94CF9            jmp word 0xf956
....

In this case I'd then need to look at what was at 0xff956, etc.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106131145.08185.jhb>