From owner-freebsd-hackers Tue Oct 5 11:52:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt011n66.san.rr.com (dt011n66.san.rr.com [204.210.13.102]) by hub.freebsd.org (Postfix) with ESMTP id 86EC0153A6 for ; Tue, 5 Oct 1999 11:52:34 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n66.san.rr.com (8.9.3/8.8.8) with ESMTP id LAA43552; Tue, 5 Oct 1999 11:51:53 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 5 Oct 1999 11:51:53 -0700 (PDT) From: Doug X-Sender: doug@dt011n66.san.rr.com To: Luoqi Chen Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: zalloci/pv_entry problem (Was: Weird sockname errors with -current and apache) In-Reply-To: <199910042352.TAA09480@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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