I have been having a great time :-) debugging a device driver,
and have run into a really fun way to panic. With one type
of traffic, [something] happens and the kernel drops into
DDB, just the way I want.
Well, actually DDB seems to get trapped in some kind of loop
that spews messages faster than a human can read them. When
I finally got a piece of a clue, I booted with serial console
and captured the following (also an endless loop):
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014ed6b
stack pointer = 0x10:0xc02b1360
frame pointer = 0x10:0xc02b1388
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net tty bio cam
kernel: type 12 trap, code=0
Stopped at
The PC seems to have died in the DDB, that's odd (or maybe not?)
ts7# nm /kernel | grep c014ed
c014ed38 T linker_ddb_search_symbol
c014edbc T linker_ddb_symbol_values
Now looking back at the panic message, it looks like the stack has
pushed into the "frame pointer". Is this an actual problem, or
just some side effect of the page fault?
Should I start spending my time looking for kernel stack hogs in
the device driver? I can very easily add code to log ESP & EBP;
would that be productive?
Is there a maximum size for a softc? Maybe I'm accidentally ignoring
some "code of the west" and am getting punished for it? (It wouldn't
be the first time).
Helpful flames gratefully accepted :-)
Thanks,
-Richard
-------------------------------------------
Richard Hodges | Matriplex, inc.
<title> | 769 Basque Way
[EMAIL PROTECTED] | Carson City, NV 89706
775-886-6477 | www.matriplex.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
