From owner-freebsd-current Sat May 30 03:49:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA28224 for freebsd-current-outgoing; Sat, 30 May 1998 03:49:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from top.worldcontrol.com (surf52.cruzers.com [205.215.232.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA28217 for ; Sat, 30 May 1998 03:49:46 -0700 (PDT) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 26619 invoked by uid 100); 30 May 1998 10:50:37 -0000 Message-ID: <19980530035034.A26571@top.worldcontrol.com> Date: Sat, 30 May 1998 03:50:34 -0700 To: freebsd-current@FreeBSD.ORG Cc: toor@dyson.iquest.net Subject: Panic: SMP, CAM, Dyson SMP patches Mail-Followup-To: freebsd-current@freebsd.org, toor@dyson.iquest.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm running 3.0-CURRENT #2: Fri May 29 12:45:20 PDT 1998 with CAM, and Dyson's 26.may SMP patches. It panic'ed during a 'make -j 8 buildworld' pretty near the end. It did not panic during two 'make -j 4 buildworld's. I'm also quite suspicious of these silo overflow messages. They only occur with a kernel running the Dyson SMP patches. ... May 30 02:11:18 bls2 /kernel: sio1: 1 more silo overflow (total 33) May 30 02:32:16 bls2 /kernel: sio1: 1 more silo overflow (total 34) May 30 03:08:43 bls2 /kernel: sio1: 1 more silo overflow (total 35) Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0xffffff8e fault code = supervisor write, page not present instruction pointer = 0x8:0xf4c53c5b stack pointer = 0x10:0xf4c53c2c frame pointer = 0x10:0xf4c53c48 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 = 9871 (make) interrupt mask = <- SMP: XXX trap number = 12 panic: page fault mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 boot() called on cpu#1 syncing disks... regretably I had the kernel in DDB_UNATTENDED, rather than DDB and the system froze after syncing disks... Why am I not getting kernel crashdumps? I've set: savecore_enable="YES" # Save kernel crashdumps for debugging (or NO). dumpdev="/dev/da0s2b" # Device name to crashdump to (if enabled). in /etc/rc.conf. -- Brian Litzinger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message