On Sat, 23 Jan 1999, Matthew Dillon wrote:
>
> :I made it happen again by doing the same installworld but this time I
> :caught it in the debugger. I'll leave the machine up for a while in case
> :someone has some idea of how to debug it. The stacktrace looks like this:
> :
> :#0 Debugger () at ../../alpha/alpha/db_interface.c:260
> :#1 0xfffffc000036c2c0 in panic () at ../../kern/kern_shutdown.c:444
> :#2 0xfffffc00004942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
> :#3 0xfffffc00003a1b54 in allocbuf () at ../../kern/vfs_bio.c:1791
>
> The panic message should be printing the address of the vm_page_t that
> it caught.
>
> From the debugger, dump that vm_page_t with 'print'.
>
> print *0xADDRESS
>
> Do about 8 print's bumping the address by 4 ( in hex ) for each.
>
> It would be even better if we could figure out the contents and type
> of the underlying object.
I have full symbols:
(gdb) fr 2
#2 0xfffffc00004942fc in vm_page_alloc () at ../../vm/vm_page.c:1041
1041 panic("found dirty cache page %p", m);
(gdb) l
1036 */
1037
1038 if (qtype == PQ_CACHE) {
1039 #if !defined(MAX_PERF)
1040 if (m->dirty)
1041 panic("found dirty cache page %p", m);
1042
1043 #endif
1044 vm_page_busy(m);
1045 vm_page_protect(m, VM_PROT_NONE);
(gdb) p m
$4 = (struct vm_page *) 0xfffffe0000108f40
(gdb) p *m
$5 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfffffc000052ecc8}, hnext = 0x0,
listq = {tqe_next = 0xfffffe0000090fe0, tqe_prev = 0xfffffe00000bb6b8},
object = 0xfffffe00050e2a10, pindex = 12, phys_addr = 88940544, queue = 172,
flags = 128, pc = 41, wire_count = 0, hold_count = 0, act_count = 5 '\005',
busy = 0 '\000', valid = 65535, dirty = 65535}
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
