I've seen this panic many times on my alpha SMP testbox. It seems that the vm
object returned by vm_map_lookup via the fs.first_object variable is actually
NULL, resulting in a NULL pointer deref when calling vm_object_pip_add() (note
object=0x0). I haven't seen this on UP or x86 before,
On Mon, Jul 16, 2001 at 02:39:17PM -0700, Matthew Jacob wrote:
On Mon, 16 Jul 2001, Wilko Bulte wrote:
On Mon, Jul 16, 2001 at 02:30:47PM -0700, Matthew Jacob wrote:
I've seen this panic many times on my alpha SMP testbox. It seems that the vm
object returned by vm_map_lookup via
On Mon, Jul 16, 2001 at 02:30:47PM -0700, Matthew Jacob wrote:
I've seen this panic many times on my alpha SMP testbox. It seems that the vm
object returned by vm_map_lookup via the fs.first_object variable is actually
NULL, resulting in a NULL pointer deref when calling
On Mon, 16 Jul 2001, Wilko Bulte wrote:
On Mon, Jul 16, 2001 at 02:30:47PM -0700, Matthew Jacob wrote:
I've seen this panic many times on my alpha SMP testbox. It seems that the vm
object returned by vm_map_lookup via the fs.first_object variable is actually
NULL, resulting in a NULL
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3a
fault code= supervisor write, page not present
instruction pointer = 0x8:0xc02c8cfe
stack pointer = 0x10:0xcd6d1d44
frame pointer = 0x10:0xcd6d1d5c
code segment = base 0x0,
Thus spake John Baldwin ([EMAIL PROTECTED]):
tf_eip = -1070822146, tf_cs = 8, tf_eflags = 66118,
tf_esp = -1069680480, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:405
#11 0xc02c8cfe in vm_object_pip_add (object=0x0, i=1)
I've seen this panic many times on my alpha SMP
