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

Ståle Kristoffersen staale at
Tue Jul 20 11:55:31 UTC 2010

On 2010-07-20 at 12:17, Marius Strobl wrote:
> On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote:
> > On 2010-07-18 at 14:20, Marius Strobl wrote:
> > > > > Downgrading now...
> > > > 
> > > > And it crashed again, with current from r209598...
> > > > 
> > > 
> > > Ok, this at least means that your problem isn't caused by the recent
> > > changes to mpt(4) as the pre-r209599 version only differed from the
> > > 8-STABLE one in a cosmetic change at that time.
> > 
> > I have another data-point, I cvsup'ed to the latest current again, and
> > rebuilt without INVARIANT and WITNESS, and now it seems to survive the
> > timeouts.
> That's more or less expected as the sanity check issuing the panic
> just isn't compiled in then. However, my understanding was that with
> STABLE you don't get the timeouts in the first place, or do you see
> them there also?

I got the timeouts with STABLE as well, that was the reason for me to
try out CURRENT. I'm sorry I didn't mention that earlier.

My main concern is to get rid of the timeouts, but a panic on one can't be
right. How can I debug this further? I can get timeout fairly consistent by
putting a bit of load on the drives. If it would help I can also provide
remote access.

I'm trying to update the firmware on some of the drives now to see if that
helps with the timeouts.

Ståle Kristoffersen

More information about the freebsd-current mailing list