Dag-Erling Smorgrav writes:
db trace
Debugger(c027d5e1) at Debugger+0x45
panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
trap(18,10,10,d7345fa8,0) at trap+0x978
Andrew Gallatin [EMAIL PROTECTED] writes:
Where does witness_enter+0x355 map to, in terms of line numbers?
root@rsa /var/crash# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Andrew Gallatin [EMAIL PROTECTED] writes:
Where does witness_enter+0x355 map to, in terms of line numbers?
root@rsa /var/crash# gdb -k
[...]
Argh! Please ignore this, the machine gdb was running on had an old
source tree. I'll get a correct
On 19-Mar-01 Dag-Erling Smorgrav wrote:
SMP box with a bleeding-edge -CURRENT kernel, patched to avoid the
i586_bzero() problem:
panic: mutex_enter: recursion on non-recursive mutex process lock @
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
Debugger("panic")
That's a later
On Mon, 19 Mar 2001, John Baldwin wrote:
Hmmm. An eip of 0 is bad. This could be just another instance of the bzero
bug just in another place. You probably want to change the code that actually
sets *bzero to i586_bzero (and same for any other ops that use floating point).
The code in
On 20-Mar-01 Bruce Evans wrote:
On Mon, 19 Mar 2001, John Baldwin wrote:
Hmmm. An eip of 0 is bad. This could be just another instance of the bzero
bug just in another place. You probably want to change the code that
actually
sets *bzero to i586_bzero (and same for any other ops that
On Tue, 20 Mar 2001, Bruce Evans wrote:
On Mon, 19 Mar 2001, John Baldwin wrote:
Hmmm. An eip of 0 is bad. This could be just another instance of the bzero
bug just in another place. You probably want to change the code that actually
sets *bzero to i586_bzero (and same for any other
