Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jan 2008 16:48:10 +0000
From:      Pete French <petefrench@ticketswitch.com>
To:        jhb@freebsd.org
Cc:        freebsd-stable@freebsd.org
Subject:   Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
Message-ID:  <E1JFuO2-0000PF-KE@dilbert.ticketswitch.com>
In-Reply-To: <200801181003.24092.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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;
>
> where it reads 'xsdt->Length'.  xsdt was just mapped into a temporary part of
> KVA (used for kernel dumps) a few lines earlier:

O.K., that is interesting, because my source code doesnt look like thiat,
mine uses 'xsdt->Header.Length' instead of 'xsdt->Length' - is that
code above from 7.0 ?

> You can try adding some printfs to see what the values of 'rsdp->XsdtPhysicalAddress' and
> 'xsdt' after the call to madt_map_table() are.  Actually, try this perhaps:

Thanks for the patch - it didn;t help matters unfortunately, but I am
adding some printfs on xsdt itself and also rsdp->XsdtPhysicalAddress to
see what we get.

Will build a new kernel and let you know.

cheers,

-pete.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1JFuO2-0000PF-KE>