freebsd stable - Jan 2008 - panic: vm_fault: fault on nofualt entry, addr: 81423000

I have an HP dc5750 workstaion and I get the following when I tryand boot
it with ACPI enabled. This happens almost instantly, just after the
processors are detected. I am running 7.0 these days, but I had the same
issue under 6.3 (which I reported in PR 117918, though without
the panic line, which I could not get our of 6.3). I just tested again with
the latest 7.0 prerelease from this morning (as I saw some ACPI changes)
plus the latest HP BIOS update (v02.31), but the problem still exists.

I know there were problems with these machines under amd64 (the "missing
BIOS smap" probkem in PR 111952), but this appears to be a different
issue. Is there anything useful I can do to get a trace out at the
point it panics ? It doesnt dump anything into /var/crash when it
reboots, preseumably because the panic is far too ealy on in the
boot process ?

-pcf.

following up my own email here, but I have compiled the kernel
debugger into my kerenal, and much to my surprise it dooes actualy
drop into the debugger when it panics.

so, what can I do from there to help sort this out ? a quick backtrace
shows the following call sequence:

	madt_probe
	apic_init
	mi_startup
	beging

Which surprises me as I was expecting to see something inside an acpi call.
I am not sure where to go from here though - I know nothing about this bit
of the kernel, and it's quite a shallow learning curve unfortunately.

-pete.

On Thursday 17 January 2008 07:39:54 pm Pete French
wrote:
> > MADT is the ACPI table that enumerates APICs.  Do you have the offset
of
> > madt_probe()?
> 
> I am sujre I can get it for you - do I need to do anything special
> in DDB, or is it just the numbers in the bt that you are after ?
> I can make this panic very easily and do whatever is necessary to
> get info out.
Just the stack trace offsets.

-- 
John Baldwin

> Just the stack trace offsets.
is all the info you need here?

http://toybox.twisted.org.uk/~pete/acpi_panic.jpg

> If you are using RSDT, then RsdtPhysicalAddress is what you care about
> rather than XsdtPhysicalAddress.
O.K., I have this now - RsdtPhysicalAddress is 0x7fec7f40 on
return from madt_map_table

-pete.

On Monday 21 January 2008 08:00:33 am Pete French wrote:
> > If you are using RSDT, then RsdtPhysicalAddress is what you care about
> > rather than XsdtPhysicalAddress.
> 
> O.K., I have this now - RsdtPhysicalAddress is 0x7fec7f40 on
> return from madt_map_table
Can you print out the table header length in the madt_map_table() routine?

-- 
John Baldwin