Date: Fri, 18 Jan 2008 12:57:29 -0500 From: John Baldwin <jhb@freebsd.org> To: Pete French <petefrench@ticketswitch.com> Cc: freebsd-stable@freebsd.org Subject: Re: panic: vm_fault: fault on nofualt entry, addr: 81423000 Message-ID: <200801181257.29253.jhb@freebsd.org> In-Reply-To: <E1JFuO2-0000PF-KE@dilbert.ticketswitch.com> References: <E1JFuO2-0000PF-KE@dilbert.ticketswitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 18 January 2008 11:48:10 am 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;
> >
> > 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 ?
That doesn't matter actually.
> > 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.
Hmm, ok.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801181257.29253.jhb>