Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
I think the problem is that the header for the FACP table crossed a page boundary so we had to map 2 pages to map the header, but the code assumes only 1 page is needed so when the second page was mapped, it overlapped with the page holding the XSDT. Here's a fix: Excellent, that fixes it on my machine! Preseumbaly this fix will also work on 6.3 which has the same problem. is it also likely to be required on amd64 - I notice there is a separate separate madt.c file for 64 it. If you want to close the PR's then they are kern/119716 and kern/117918 Now that it's booting with ACPI I can see that the box has some other issues, but will look into those when I get back to wrok (am currfenttly off sick - testing has to be done by emailing a colleague with prceise instructions, not the easiest way to debug a kernel) cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
That isn't page-aligned which is unexpected, though it should still work fine. I am wondering if the non page alignment is what is causing the trouble here. I discovered my printfs were causing panics themselves, so am re-doing a lot of my results as I have been generating some red herrings. I will have some more results to email you later, but it looks to me as if the problem of the first table entry results in unmapping part of the header, and hence access to the second tbale entry crashes. At least the address reported in the panic is one I can see was unmapped just before the panic. I am doing a full compile against the latest stable and will actually see if I can track this down in a lot more detail and send you the results, cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
o.k., done some investigative work, and I think i have actually tracke dodnw what is going wrong, though i do not know how to fix it. mapping the header calls madt_map_table, which in turn calls madt_map to do the actual mapping: madt_map called with pa 0x7fec7f40, offset 1, length 60 'off' becomes 3904, and the rounded length 4096 pmap_kenter_temporary called with pa 0x7fec7000, offset 1 gives va of 0x8142300 returns 0x81423f40 thus the header is ending up in page 0x8142300 if I read that correctly. this is importnat for later on. meanwhile, back at the table scanning code... rsdt mapped at 0x81423f40 table offset at 0x81423f64 count is 6 table offset address and their contents 0 0x81423f64 0x7fec7fe8 1 0x81423f68 0x7fec805c 2 0x81423f6c 0x7fec80c4 3 0x81423f70 0x7fec8127 4 0x81423f74 0x7fec8163 5 0x81423f78 0x7fec8195 so, it probes the first table, held at 0x7fec7fe8 as indicated by the address in 0x81423f64. this calls madt_map to map the table madt_map called with pa 0x7fec7fe8, offset 0, length 36 'off' becomes 4072, and the rounded length 8192 pmap_kenter_temporary called with pa 0x7fec7000, offset 0 pmap_kenter called with va 0x8142300, pa 0x7fec8000 gives va of 0x8142200 returns 0x81422fe8 code is looking for a signature of 'APIC', but this table has 'FACP', so a call is made to madt_unmap before returning madt_unmap called with data 0x81422fe8, length 36 'off' becomes 4072, and the rounded length 8192 pmap_kremove called with 0x81422000 pmap_kremove called with 0x81423000 the function then returns 0, and the loop goes round again to look at table entry 1. the address of the table is stored at 0x81423f68 as you can see from the list above, and it is when it tries to access that address that it panics. now preseumably the panic is correct - 0x81423f68 is in page 0x81423000, and didn't we just unmap that ? now I dont really understand this fully, but why is page 0x81423000 being touched at all ? shouldnt the mapped pages be 0x81421000 and 0x81422000 instead so they don't clash with the already mapped 0x81423000 ? The unmap function is quite correctly doing the reverse of the map function, but maybe theres something simply going wrong in the algorithm working out which pages to map ? cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Monday 28 January 2008 01:03:45 pm Pete French wrote:
o.k., done some investigative work, and I think i have actually tracke
dodnw what is going wrong, though i do not know how to fix it. mapping
the header calls madt_map_table, which in turn calls madt_map
to do the actual mapping:
madt_map called with pa 0x7fec7f40, offset 1, length 60
'off' becomes 3904, and the rounded length 4096
pmap_kenter_temporary called with pa 0x7fec7000, offset 1
gives va of 0x8142300
returns 0x81423f40
thus the header is ending up in page 0x8142300 if I read that correctly.
this
is importnat for later on. meanwhile, back at the table scanning code...
rsdt mapped at 0x81423f40
table offset at 0x81423f64
count is 6
table offset address and their contents
0 0x81423f64 0x7fec7fe8
1 0x81423f68 0x7fec805c
2 0x81423f6c 0x7fec80c4
3 0x81423f70 0x7fec8127
4 0x81423f74 0x7fec8163
5 0x81423f78 0x7fec8195
so, it probes the first table, held at 0x7fec7fe8 as indicated by
the address in 0x81423f64. this calls madt_map to map the table
madt_map called with pa 0x7fec7fe8, offset 0, length 36
'off' becomes 4072, and the rounded length 8192
pmap_kenter_temporary called with pa 0x7fec7000, offset 0
pmap_kenter called with va 0x8142300, pa 0x7fec8000
gives va of 0x8142200
returns 0x81422fe8
code is looking for a signature of 'APIC', but this table has 'FACP', so
a call is made to madt_unmap before returning
madt_unmap called with data 0x81422fe8, length 36
'off' becomes 4072, and the rounded length 8192
pmap_kremove called with 0x81422000
pmap_kremove called with 0x81423000
the function then returns 0, and the loop goes round again to look
at table entry 1. the address of the table is stored at 0x81423f68
as you can see from the list above, and it is when it tries to access
that address that it panics.
now preseumably the panic is correct - 0x81423f68 is in page 0x81423000,
and didn't we just unmap that ? now I dont really understand this fully,
but why is page 0x81423000 being touched at all ? shouldnt the mapped
pages be 0x81421000 and 0x81422000 instead so they don't clash with
the already mapped 0x81423000 ? The unmap function is quite correctly doing
the reverse of the map function, but maybe theres something simply going
wrong in the algorithm working out which pages to map ?
I think the problem is that the header for the FACP table crossed a page
boundary so we had to map 2 pages to map the header, but the code assumes
only 1 page is needed so when the second page was mapped, it overlapped with
the page holding the XSDT. Here's a fix:
Index: madt.c
===
RCS file: /usr/cvs/src/sys/i386/acpica/madt.c,v
retrieving revision 1.28
diff -u -r1.28 madt.c
--- madt.c 11 Sep 2007 22:54:09 - 1.28
+++ madt.c 28 Jan 2008 21:25:03 -
@@ -109,9 +109,11 @@
/*
* Code to abuse the crashdump map to map in the tables for the early
* probe. We cheat and make the following assumptions about how we
- * use this KVA: page 0 is used to map in the first page of each table
- * found via the RSDT or XSDT and pages 1 to n are used to map in the
- * RSDT or XSDT. The offset is in pages; the length is in bytes.
+ * use this KVA: pages 0 and 1 are used to map in the header of each
+ * table found via the RSDT or XSDT and pages 2 to n are used to map
+ * in the RSDT or XSDT. We have to use 2 pages for the table headers
+ * in case a header spans a page boundary. The offset is in pages;
+ * the length is in bytes.
*/
static void *
madt_map(vm_paddr_t pa, int offset, vm_offset_t length)
@@ -232,7 +234,7 @@
printf(MADT: RSDP failed extended checksum\n);
return (ENXIO);
}
- xsdt = madt_map_table(rsdp-XsdtPhysicalAddress, 1,
+ xsdt = madt_map_table(rsdp-XsdtPhysicalAddress, 2,
ACPI_SIG_XSDT);
if (xsdt == NULL) {
if (bootverbose)
@@ -246,7 +248,7 @@
break;
madt_unmap_table(xsdt);
} else {
- rsdt = madt_map_table(rsdp-RsdtPhysicalAddress, 1,
+ rsdt = madt_map_table(rsdp-RsdtPhysicalAddress, 2,
ACPI_SIG_RSDT);
if (rsdt == NULL) {
if (bootverbose)
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
Hmm, so that's fine. What pointer is returned by madt_map_table?
0x800e7610
I also put some prints in afterwards to try and see how far through
the loop it was getting:
count = (xsdt-Header.Length - sizeof(ACPI_TABLE_HEADER)) /
sizeof(UINT64);
printf(DEBUG: count is %d\n, count);
for (i = 0; i count; i++) {
printf(DEBUG: probing %d - offset %p\n,
i, xsdt-TableOffsetEntry[i]);
if (madt_probe_table(xsdt-TableOffsetEntry[i]))
break;
}
The output is interesting - I get count printed as 6, but then nothing
else, just the panic. Which leads me to believe that it is the access
to xsdt-TableOffsetEntry[0] which is causing the panic.
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Friday 25 January 2008 07:55:46 am Pete French wrote:
Hmm, so that's fine. What pointer is returned by madt_map_table?
0x800e7610
That isn't page-aligned which is unexpected, though it should still
work fine.
I also put some prints in afterwards to try and see how far through
the loop it was getting:
count = (xsdt-Header.Length - sizeof(ACPI_TABLE_HEADER)) /
sizeof(UINT64);
printf(DEBUG: count is %d\n, count);
for (i = 0; i count; i++) {
printf(DEBUG: probing %d - offset %p\n,
i, xsdt-TableOffsetEntry[i]);
if (madt_probe_table(xsdt-TableOffsetEntry[i]))
break;
}
The output is interesting - I get count printed as 6, but then nothing
else, just the panic. Which leads me to believe that it is the access
to xsdt-TableOffsetEntry[0] which is causing the panic.
Hmm, that is odd. The header.Length and the the actual table should all be
in the same page, so you shouldn't be getting a page fault. Can you add
some printfs to madt_map() to see what the final starting (pa, length) are
before the call to pmap_kenter_temporary() and then add a printf for each
iteration of the while loop showing the (pa, la, remaining length)?
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
Can you print out the table header length in the madt_map_table() routine? Sorry, just realised I never re[plied to this! It's 60, and the length matches with the following check in the table itself. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Thursday 24 January 2008 08:48:13 am Pete French wrote: Can you print out the table header length in the madt_map_table() routine? Sorry, just realised I never re[plied to this! It's 60, and the length matches with the following check in the table itself. Hmm, so that's fine. What pointer is returned by madt_map_table? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Friday 18 January 2008 09:31:44 am Pete French wrote:
Just the stack trace offsets.
is all the info you need here?
http://toybox.twisted.org.uk/~pete/acpi_panic.jpg
Yep.
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:
218 /*
219 * For ACPI = 2.0, use the XSDT if it is available.
220 * Otherwise, use the RSDT. We map the XSDT or RSDT at page 1
221 * in the crashdump area. Page 0 is used to map in the
222 * headers of candidate ACPI tables.
223 */
224 if (rsdp-Revision = 2 rsdp-XsdtPhysicalAddress != 0) {
225 /*
226 * AcpiOsGetRootPointer only verifies the checksum for
227 * the version 1.0 portion of the RSDP. Version 2.0 has
228 * an additional checksum that we verify first.
229 */
230 if (AcpiTbChecksum(rsdp, ACPI_RSDP_XCHECKSUM_LENGTH) !=
0) {
231 if (bootverbose)
232 printf(MADT: RSDP failed extended
checksum\n);
233 return (ENXIO);
234 }
235 xsdt = madt_map_table(rsdp-XsdtPhysicalAddress, 1,
XSDT_SIG);
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:
Index: madt.c
===
RCS file: /host/cvs/usr/cvs/src/sys/i386/acpica/madt.c,v
retrieving revision 1.19.2.4
diff -u -r1.19.2.4 madt.c
--- madt.c 5 Oct 2007 15:22:36 - 1.19.2.4
+++ madt.c 18 Jan 2008 15:01:40 -
@@ -164,7 +164,20 @@
}
length = header-Length;
madt_unmap(header, sizeof(ACPI_TABLE_HEADER));
+ if (length (MAXDUMPPGS - offset) * PAGE_SIZE) {
+ printf(MADT: %s is too long, truncating\n, sig);
+ length = (MAXDUMPPGS - offset) * PAGE_SIZE;
+ }
table = madt_map(pa, offset, length);
+ header = table;
+ if (header-Length != length) {
+ /*
+* If we truncated the table, fixup the length to
+* perpetuate the lie and skip the checksum.
+*/
+ header-Length = length;
+ return (table);
+ }
if (ACPI_FAILURE(AcpiTbVerifyTableChecksum(table))) {
if (bootverbose)
printf(MADT: Failed checksum for table %s\n, sig);
@@ -267,6 +280,10 @@
if (bootverbose)
printf(MADT: Found table at 0x%jx\n,
(uintmax_t)madt_physaddr);
+ if (madt_length MAXDUMPPGS * PAGE_SIZE) {
+ printf(MADT: Table is too large, ignoring\n);
+ return (ENXIO);
+ }
/*
* Verify that we can map the full table and that its checksum is
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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 ?
I wont have access to the machine over the weekend, but I can make more tests
on monday morning.
thanks for the help,
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
Just the stack trace offsets. is all the info you need here? http://toybox.twisted.org.uk/~pete/acpi_panic.jpg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
MADT is the ACPI table that enumerates APICs. Do you have the offset of madt_probe()? I startet copying down the hex, but it turned out to be a more accurate idea to get my colleague to take a photo with his camera phone. Panic and kdb 'bt' output can be found here: http://toybox.twisted.org.uk/~pete/acpi_panic.jpg if theres anything else you need me to do in kdb then pleae let me know, as this is very easy for me to reproduce during ther work day. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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. Ah, O.K., yes, looking at the patch thats obvious, sorry. I also just found a bug in my printf code - I wasnt printing the vlaue of of RsdtPhysicalAddress in the second part of the 'if' at all. Will fix that and re-test on monday. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
On Thursday 17 January 2008 07:38:32 am Pete French wrote: 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. MADT is the ACPI table that enumerates APICs. Do you have the offset of madt_probe()? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofualt entry, addr: 81423000
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. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
