From owner-freebsd-questions@FreeBSD.ORG Mon Apr 3 10:09:10 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9653516A401 for ; Mon, 3 Apr 2006 10:09:10 +0000 (UTC) (envelope-from freebsd@fidei.co.uk) Received: from ivy.southportcomputers.co.uk (ivy.southportcomputers.co.uk [82.195.155.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CC9E43DA1 for ; Mon, 3 Apr 2006 10:08:31 +0000 (GMT) (envelope-from freebsd@fidei.co.uk) Received: from [192.168.0.101] (brokenbiscuits.force9.co.uk [212.159.76.2]) (authenticated bits=0) by ivy.southportcomputers.co.uk (8.13.6/8.13.4) with ESMTP id k33A8Jfp082261 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Apr 2006 11:08:25 +0100 (IST) (envelope-from freebsd@fidei.co.uk) Message-ID: <4430F448.8060307@fidei.co.uk> Date: Mon, 03 Apr 2006 11:09:12 +0100 From: cw User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88/1368/Mon Apr 3 05:06:54 2006 on ivy.southportcomputers.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on ivy.southportcomputers.co.uk Subject: Helping interpreting crash X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 10:09:10 -0000 Hi folks, My FreeBSD server (6.0-RELEASE #0) crashed out the other night. I have a custom kernel in place with debugging on so can get the info out the dump in /var/crash Thing is, I'm not sure how to interpret it. I can see all the stuff about ip and the network but I don't know if it means that is the culprit and the handbook only goes into how to get the data out of the dump. So could anyone possibly have a look at below (or tell me of somewhere I can go to get the right info..bearing in mind I don't know all that much about the kernel) and let me know what's up? Thanks, Colin. cd /usr/obj/usr/src/sys/IVY kgdb kernel.debug /var/crash/vmcore.1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x58 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0551fcb stack pointer = 0x28:0xde9fbb18 frame pointer = 0x28:0xde9fbb34 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 = 687 (python) trap number = 12 panic: page fault Uptime: 2d12h7m56s Dumping 510 MB (2 chunks) chunk 0: 1MB (160 pages) ... ok chunk 1: 510MB (130416 pages) 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc0551fcb 0xc0551fcb is in ip_ctloutput (/usr/src/sys/netinet/ip_output.c:1208). 1203 if (error) 1204 break; 1205 1206 switch (sopt->sopt_name) { 1207 case IP_TOS: 1208 inp->inp_ip_tos = optval; 1209 break; 1210 1211 case IP_TTL: 1212 inp->inp_ip_ttl = optval; (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc04ccb72 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc04cce08 in panic (fmt=0xc05fc04b "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc05dedb8 in trap_fatal (frame=0xde9fbad8, eva=88) at /usr/src/sys/i386/i386/trap.c:831 #4 0xc05deb23 in trap_pfault (frame=0xde9fbad8, usermode=0, eva=88) at /usr/src/sys/i386/i386/trap.c:742 #5 0xc05de781 in trap (frame= {tf_fs = -1067646968, tf_es = -1024393176, tf_ds = 40, tf_edi = 0, tf_esi = 0, tf_ebp = -559957196, tf_isp = -559957244, tf_ebx = -559956848, tf_edx = -559956592, tf_ecx = 0, tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1068163125, tf_cs = 32, tf_eflags = 66183, tf_esp = -559957204, tf_ss = 8}) at /usr/src/sys/i386/i386/trap.c:432 #6 0xc05ce86a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0551fcb in ip_ctloutput (so=0x8, sopt=0xde9fbc90) at /usr/src/sys/netinet/ip_output.c:1208 #8 0xc056016f in tcp_ctloutput (so=0xc2f376f4, sopt=0xde9fbc90) at /usr/src/sys/netinet/tcp_usrreq.c:1036 #9 0xc05062c8 in sosetopt (so=0xc2f376f4, sopt=0xde9fbc90) at /usr/src/sys/kern/uipc_socket.c:1553 #10 0xc050b525 in kern_setsockopt (td=0xc2f1dd80, s=14, level=8, name=8, val=0xde9fbd90, valseg=UIO_USERSPACE, valsize=0) at /usr/src/sys/kern/uipc_syscalls.c:1331 #11 0xc050b456 in setsockopt (td=0xc2f1dd80, uap=0x8) at /usr/src/sys/kern/uipc_syscalls.c:1287 #12 0xc05df0cf in syscall (frame= {tf_fs = 171507771, tf_es = 174850107, tf_ds = -1078001605, tf_edi = -1077955292, tf_esi = -1077955284, tf_ebp = -1077955268, tf_isp = -559956636, tf_ebx = 708242808, tf_edx = 154827904, tf_ecx = -1077955988, tf_eax = 105, tf_trapno = 0, tf_err = 2, tf_eip = 673615827, tf_cs = 51, tf_eflags = 658, tf_esp = -1077955344, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:976 #13 0xc05ce8bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *sopt $1 = {sopt_dir = SOPT_SET, sopt_level = 0, sopt_name = 3, sopt_val = 0xbfbfb52c, sopt_valsize = 4, sopt_td = 0xc2f1dd80} As a sidenote, I recently upgraded sendmail to 8.13.6 using the ports tree with a few commands I picked out of the web. Whilst it appears that 8.13.6 is still on the server, it has somehow lost its ability to use sasl2 which was compiled into it as follows: **Added to Makefile SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf FORCE_PKG_REGISTER=yes **Also uncommented lines about tls, smtps and sasl2 **Make command make DESTDIR="" PREFIX=/usr PIDDIR=/var/run DESTETC=/etc/mail DESTEXEC=/usr/libexec DESTRUN=/var/run DESTBIN=/usr/sbin install As a result I have had to recompile sendmail to get support back. (I'm aware this probably isn't the best way of upgrading sendmail, but by the time I realised that it was too late..)