On Sun, Mar 18, 2001 at 04:41:03PM +0100, Dag-Erling Smorgrav wrote:
> I finally caught a backtrace from one of those recurring stack smash
> panics. I've been getting a few of these every day for a couple of
> weeks now but never caught a dump; I caught this one by typing 'panic'
> immediately instead of trying to get a trace at the ddb prompt first.
I have a suggestion for what is happening, but I'm not sure exactly
what could cause it.
>From looking at the stack from the core I have found where the esp
and eip in the second trap frame are comming, from:
0xffff0000,
0xffffffff,
... another 100 bytes
0xc0293748, return address in pmap_zero_page (calling bzero)
0xc0801000, CADDR2
0x1000, PAGESIZE
0xc86dff38, pushed ebp
0xc0266b53 return address in vm_fault (calling pmap_zero_page)
Now, 108 bytes is exactly the amount that the i586_bzero shifts
the stack by if it uses the floating point registers and it needs
to preserve them. At the end it checks "PCPU(NPXPROC)" again and
if it is zero it doesn't bother popping the 108 bytes off the stack.
Presumably what is happening is i586_bzero begins and finds that
PCPU(NPXPROC) is not zero, so it decides to preserve the fpu
registers. Then something interrupts it, but doesn't restore
PCPU(NPXPROC). When i586_bzero returns it uses the first 8 bytes
of the fpu registers for its intstruction pointer and stack pointer
and goes boom.
I haven't tried to find out what is supposed to save and restore
PCPU(NPXPROC). In my trace the process in question had recently
been interrupted by the ata interrupt.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message