panic: vm_fault: fault on nofualt entry, addr: 81423000
John Baldwin
jhb at freebsd.org
Fri Jan 18 12:31:02 PST 2008
On Friday 18 January 2008 01:02:04 pm Pete French wrote:
> > So it appears to be dying here:
> >
> > (gdb) l *madt_probe+0x119
> > 0xc06e7c69 is in madt_probe (/usr/src/sys/i386/acpica/madt.c:241).
> > 236 if (xsdt == NULL) {
> > 237 if (bootverbose)
> > 238 printf("MADT: Failed to map
XSDT\n");
> > 239 return (ENXIO);
> > 240 }
> > 241 count = (xsdt->Length -
sizeof(ACPI_TABLE_HEADER)) /
> > 242 sizeof(UINT64);
> > 243 for (i = 0; i < count; i++)
> > 244 if
(madt_probe_table(xsdt->TableOffsetEntry[i]))
> > 245 break;
>
> Turns out that it isn't - it's in the other branch of the if using the
> RSDT instead of the XSDT. Not sure why the debugger was giving
> misleading information. I added prints to find out which path it was
> taking and to print out some values after the line
> "rsdt = madt_map_table(rsdp->RsdtPhysicalAddress, 1, ACPI_SIG_RSDT);"
>
> The value of rsdtl is 0x800e7610, but the value of rsdp->XsdtPhysicalAddress
> is zero! So I guess that is where the panic is comming from. So where
> now ? Is there an equivalent patch to the one you emailed
> earlier for this branch of the if ?
The patch would be the same, it tried to fix an issue where if the table is
longer than the space we are borrowing to map things we could end up with
problems. I.e. the changes weren't in the RSDT/XSDT path at all, but in the
common code used to map tables. If you are using RSDT, then
RsdtPhysicalAddress is what you care about rather than XsdtPhysicalAddress.
--
John Baldwin
More information about the freebsd-stable
mailing list