From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 1 17:42:59 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FBD137B401 for ; Tue, 1 Jul 2003 17:42:56 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 28D4043FE5 for ; Tue, 1 Jul 2003 17:42:55 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 88666 invoked by uid 1000); 2 Jul 2003 00:42:56 -0000 Date: Tue, 1 Jul 2003 17:42:56 -0700 (PDT) From: Nate Lawson To: Jack Patton In-Reply-To: <200307011459.aa18828@flag.60north.net> Message-ID: <20030701174149.X88547@root.org> References: <200307011459.aa18828@flag.60north.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-scsi@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/53566: IBM Eserver (245 || 345) + ServeRaid 5i ips driver panic X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 00:43:00 -0000 On Tue, 1 Jul 2003, Jack Patton wrote: > Nate Lawson said: > > Disable acpi and try again. Update your BIOS to hopefully get new ACPI > > code. There's some problem here with unitialized memory. It may be > > elsewhere though and ACPI is just stumbling onto it. > > Here's the result of booting with hint.acpi.0.disabled=1. We just got this > server recently. The server BIOS is at the latest version. I'm downloading a > BIOS/Firmware for the ServeRaid card itself now and will test it with that > applied. > > Memory modified after free 0xc18b5700(252) > panic: Most recently used by devbuf > > Debugger("panic") > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 > db> tr > Debugger(c05025bf,c05c5240,c0519512,c0b35ca4,100) at Debugger+0x54 > panic(c0519512,c0500e61,fc,c0c3ab74,c0c3ab60) at panic+0xcc > mtrash_ctor(c18b5700,100,0,549,c18b5700) at mtrash_ctor+0x5d > uma_zalloc_arg(c0c3ab60,0,101,c0327740,c0599ca8) at uma_zalloc_arg+0x194 > malloc(a8,c0556ac0,101,c05226b0,c0b35d6c) at malloc+0xd4 > device_get_children(c4321380,c0b35d58,c0b35d5c,c0325d82,c18bf700) at > device_get_ > children+0x47 > isa_probe_children(c4321380,c051c640,0,c0b35d98,c02e9a25) at > isa_probe_children+ > 0x2d > configure(0,b32000,b32c00,b32000,0) at configure+0x4b > mi_startup() at mi_startup+0xb5 > begin() at begin+0x2c > db> Nope, I was wrong. Looks like it is indeed our problem. At least this tr is easier to read. :) -Nate