panic: vm_fault: fault on nofualt entry, addr: 81423000
Pete French
petefrench at ticketswitch.com
Mon Jan 28 10:03:46 PST 2008
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.
More information about the freebsd-stable
mailing list