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