Date: Sun, 18 Jul 2010 16:34:50 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen <staale@kristoffersen.ws> To: =?iso-8859-1?Q?St=E5le?= Kristoffersen <staale@kristoffersen.ws> Cc: freebsd-current@freebsd.org, Marius Strobl <marius@alchemy.franken.de> Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm Message-ID: <20100718143450.GA29150@putsch.kolbu.ws> In-Reply-To: <20100716103125.GA73878@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2010-07-16 at 12:31, Ståle Kristoffersen wrote: > On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: > > On 2010-07-15 at 18:00, Marius Strobl wrote: > > > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > > > Upgraded to from stable to current yesterday and very quickly received a > > > > panic. It did however not dump it's core, so I was unable to debug it. > > > > Today it did panic again, and I took a picture: (Sorry about the bad > > > > quality) > > > > > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > > > > > And from the backtrace: > > > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > > > > > What revision were you using? > > > > Not sure exactly what revision I was using, is there an easy way to figure > > that out? I ran cvsupdate around 13:00 CEST yesterday. > > > > > Does using current as of r209598 make a difference? > > > > Downgrading now... > > And it crashed again, with current from r209598... It still keeps on crashing :/ I grabbed the output of show alllocks: http://folk.uio.no/stalk/mpt/IMAG0047.jpg To me it looks like maybe there is a race condition or something that makes TAILQ_REMOVE-call in mpt_scsi_tmf_reply_handler() work on an element that has been removed, but this is an un-educated guess ;) I do not understand enough of the driver to follow the flow of the requests around the driver. -- Ståle Kristoffersen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100718143450.GA29150>