From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 17:09:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCBD916A4CE; Thu, 12 Aug 2004 17:09:16 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B5A43D39; Thu, 12 Aug 2004 17:09:16 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i7CH98H8020875; Thu, 12 Aug 2004 10:09:12 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200408121709.i7CH98H8020875@gw.catspoiler.org> Date: Thu, 12 Aug 2004 10:09:08 -0700 (PDT) From: Don Lewis To: mb@imp.ch In-Reply-To: <20040812174229.G31181@cvs.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: rwatson@FreeBSD.org Subject: Re: SCHEDULE and high load situations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 17:09:16 -0000 On 12 Aug, Martin Blapp wrote: > > > Here is more information: (thanks robert for the help) > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x14 >> fault code = supervisor write, page not present >> instruction pointer = 0x8:0xc066a1c7 >> stack pointer = 0x10:0xe2626aa8 >> frame pointer = 0x10:0xe2626ab8 >> 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 = 27897 (mimedefang) >> > > db> where > unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892 > unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865 > uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179 > soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518 > kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477 > connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42 > syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 --- > > src/sys/kern/uipc_syscalls.c,v 1.199 > src/sys/kern/uipc_usrreq.c,v 1.135 > src/sys/kern/uipc_socket.c,v 1.207 > > (gdb) l *unp_connect2+0x2a > 0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892). > 887 UNP_LOCK_ASSERT(); > 888 > 889 if (so2->so_type != so->so_type) > 890 return (EPROTOTYPE); > 891 unp2 = sotounpcb(so2); > 892 unp->unp_conn = unp2; > 893 switch (so->so_type) { > 894 > 895 case SOCK_DGRAM: > 896 LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); Looks like unp is NULL here. My first suspicion would be the recent memory allocation changes that affected the type safety of various dynamically allocated data structures, though I'm not sure that fits the symptoms.