Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm

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