Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Oct 1999 11:51:53 -0700 (PDT)
From:      Doug <Doug@gorean.org>
To:        Luoqi Chen <luoqi@watermarkgroup.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re:  zalloci/pv_entry problem (Was: Weird sockname errors with -current and apache)
Message-ID:  <Pine.BSF.4.10.9910051041320.43233-100000@dt011n66.san.rr.com>
In-Reply-To: <199910042352.TAA09480@lor.watermarkgroup.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Oct 1999, Luoqi Chen wrote:

> If you have a crash dump, could you look at the 4 longwords starting
> at address 0xc02698c0? It seemed to be an accouting problem. Do you
> by any chance use any kld module? zalloc() calls from within a module
> do not lock the vm_zone data structure, which is fine for UP but
> dangerous for SMP.

	Well the same machine crashed in the same place, so I can look at
the current crash for you:

Fatal trap 12: page fault while in kernel mode
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
fault virtual address   = 0x800018
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01d1107
stack pointer           = 0x10:0xdc98fe28
frame pointer           = 0x10:0xdc98fe34
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         = 41226 (httpd)
interrupt mask          = net tty bio cam  <- SMP: XXX
kernel: type 12 trap, code=0
Stopped at      zalloci+0x33:   movl    0(%edx),%eax

db> trace
zalloci(c02698c0,dc98fe58,c01f24c3,da07e7a4,91bb000) at zalloci+0x33
get_pv_entry(da07e7a4,91bb000,ffc246ec,0,dc98fe90) at get_pv_entry+0x4a
pmap_insert_entry(da07e7a4,91bb000,c0572b60,8206000) at
pmap_insert_entry+0x1f
pmap_copy(da07e7a4,dc8eeb64,80c6000,1f85000,80c6000) at pmap_copy+0x1a0
vm_map_copy_entry(dc8eeb00,da07e740,dc8327a8,dc861ed8) at
vm_map_copy_entry+0xdf
vmspace_fork(dc8eeb00,dc8e9ce0,dc8e9ce0,bfbfddbc,dc98ff30) at
vmspace_fork+0x1d3
vm_fork(dc8ea940,dc8e9ce0,14) at vm_fork+0x2f
fork1(dc8ea940,14,dc98ff48,dc8ea940,9) at fork1+0x621
fork(dc8ea940,dc98ff80,805b36c,30,bfbfddbc) at fork+0x16
syscall(c01e002f,2f,2f,bfbfddbc,30) at syscall+0x19e
Xint0x80_syscall() at Xint0x80_syscall+0x31

I _think_ I'm doing the long word check right, but it's not returning
anything:

db> x/l 0xc02698c0
db> x/l 0xdc98fe58
db> x/l 0xc01f24c3
db> x/l 0xda07e7a4
db> x/l 0x91bb000

There was also nothing for 0xffc246ec in the get_pv_entry line, and the 0
in that line looks like a bad thing to me. In the next line:

db> x/l 0xc0572b60
db> x/l 0x8206000

In vmspace_fork:

db> x/l 0xdc8e9ce0
db> x/l 0xbfbfddbc
db> x/l 0xdc98ff30

vm_fork:

db> x/l 0xdc8ea940
db> x/l 0xdc8e9ce0
db> x/l 0x14

fork1:
db> x/l 0xdc98ff80
db> x/l 0x805b36c
db> x/l 0x30

fork:
db> x/l 0xdc98ff80 

	One other thing that I thought of related to the SMP issue is that
these are Intel N440BX motherboards, and the BIOS has an option to set the
"Multi-Processor Specification" or some such that was set to 1.4, with the
other option being 1.1. Would it be better to set it to 1.1, or was my
assumption that FreeBSD would ignore that setting anyways correct?

	I put more DDB stuff from this crash at
http://doug.simplenet.com/DDB2.txt, let me know if there is anything else
I need to do. Remote GDB is an option here if you think that'd be a better
tool. I'll check to see if I'm getting dumps when the machine comes back.

Thanks,

Doug
-- 
"Stop it, I'm gettin' misty." 

    - Mel Gibson as Porter, "Payback"



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910051041320.43233-100000>