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