Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jun 2009 13:14:56 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        pluknet <pluknet@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: 6.2 sporadically locks up
Message-ID:  <200906161314.56449.jhb@freebsd.org>
In-Reply-To: <a31046fc0906160803n284604bcs741e6b038079ed12@mail.gmail.com>
References:  <a31046fc0906160323s3e4ec60bxb585bb29f9f3a02a@mail.gmail.com> <200906160830.29721.jhb@freebsd.org> <a31046fc0906160803n284604bcs741e6b038079ed12@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 June 2009 11:03:34 am pluknet wrote:
> 2009/6/16 John Baldwin <jhb@freebsd.org>:
> As for allpcpu, I often see the picture, when one CPU runs the "irq17:
> bce1 aacu0" thread
> and another one runs arcconf. I wonder if that might be a source of
> bad locking or races, or..
> The arcconf utility uses ioctl that goes into aac/aacu(4) internals.

I wondered about that.  I would ask emaste@ as he has worked with arcconf. =
 I
do think he has mentioned problems with arcconf locking up aac(4) controlle=
rs
in the past.

> > Perhaps DDB in 6.2 doesn't know to
> > look in stoppcbs[]. =A0Hmm, looks like 6.2 only does that if you are us=
ing
> > KDB_STOP_NMI. =A0Are you using that kernel option? =A0If not, you proba=
bly want
> > to.
>=20
> No, I'm not. Will that add an additional visible overhead on a running sy=
stem?

No, it actually allows the kernel to more reliably stop other CPUs during a
panic, etc.  It's enabled in GENERIC as 'STOP_NMI' in 7.0 and later.

=2D-=20
John Baldwin



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