Date: Tue, 10 Feb 2009 01:49:09 -0500 (EST) From: Charles Sprickman <spork@bway.net> To: Scott Long <scottl@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: 7.1 Panic on degraded disk w/mpt Message-ID: <alpine.OSX.2.00.0902100135290.37588@toasty.nat.fasttrackmonkey.com> In-Reply-To: <49911C68.6030203@samsco.org> References: <alpine.OSX.2.00.0902100104170.37588@toasty.nat.fasttrackmonkey.com> <49911C68.6030203@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Feb 2009, Scott Long wrote: > Charles Sprickman wrote: >> (posted on -stable already, no takers - added info: full dmesg, crash info >> from panic when array finished rebuilding, some comments on dmesg) >> >> Howdy, >> >> I dug around and can't find a PR on this, and the only other report I saw >> was in this mailing list post that has no replies: >> >> http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html >> >> The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: >> >> mpt0: <LSILogic SAS/SATA Adapter> port 0xec00-0xecff mem >> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 8.0 on pci2 >> mpt0: MPI Version=1.5.13.0 >> >> The panic is repeatable by forcing the array into a degraded state. When >> the array finishes rebuilding, the box also panics. >> >> Here's my best shot at getting info out of kgdb (panic on array going to >> degraded state): > > I wonder if the MPT card is temporarily detaching and then reattaching > the logical drive when the rebuild completes. IIRC, just before the panic there is a bunch of CAM debug splattered across the monitor. I can run down to the garage and snap a few pics of the monitor after detaching a drive. > The info you posted is inconclusive here. CAM (the FreeBSD SCSI layer) > has had some problems handling device detaches, but we've been very > fortunate to have someone examining and fixing this recently. Yeah, I was looking at the commit log for cam_xpt.c and someone has been very busy... > Would it be possible for you to upgrade to the most recent 8-CURRENT > tree, and re-run your test? If not, I'll see about generating a > patchset against 7.1. Can I get away with just updating the kernel, or is there a simple way to build a live-cd? I don't want to screw with userland, but I'd boot a kernel if that's not too rough - but I suppose my 7.1 kgdb would not know what to do with the dump, right? On the bright side, the controller is not getting so scrambled by the panic that it can no longer write the crashdump. That's a positive! I'm going to go panic it again, I'm getting curious about the messages before the panic... Thanks, Charles > Scott >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.OSX.2.00.0902100135290.37588>