Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Sep 2010 18:42:12 +0200
From:      Marius Strobl <marius@alchemy.franken.de>
To:        =?unknown-8bit?Q?St=E5le?= Kristoffersen <staale@kristoffersen.ws>
Cc:        freebsd-current@freebsd.org
Subject:   Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm
Message-ID:  <20100924164212.GO46946@alchemy.franken.de>
In-Reply-To: <20100720115528.GA88965@putsch.kolbu.ws>
References:  <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> <20100720101736.GD4706@alchemy.franken.de> <20100720115528.GA88965@putsch.kolbu.ws>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, Jul 20, 2010 at 01:55:28PM +0200, Stle Kristoffersen wrote:
> 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.
> 

FYI, that panic is fixed with r213105.

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100924164212.GO46946>