Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jun 2006 17:17:33 +0200
From:      Stanislaw Halik <sthalik@tehran.lain.pl>
To:        freebsd-stable@freebsd.org
Subject:   Re: trap 12: supervisor write, page not present on 6.1-STABLE Tue May 16 2006
Message-ID:  <20060628151733.GA787@tehran.lain.pl>
In-Reply-To: <20060628101405.I50845@fledge.watson.org>
References:  <20060627045310.GA6324@tehran.lain.pl> <20060627140946.J273@fledge.watson.org> <20060627134134.GA23337@tehran.lain.pl> <20060628101405.I50845@fledge.watson.org>

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

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 28, 2006, Robert Watson wrote:

>>>> 6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
>>>> experienced people, suggest me if it's a hardware problem or is it an
>>>> error inside the OS?
>>> This is a known bug in the TCP code; a large set of outstanding changes=
=20
>>> is present in 7.x that will fix the problem when merged.  However, I=20
>>> recently had push-back on merging the larger batch of changes, so am=20
>>> looking at merging a workaround that will also correct the problem=20
>>> without the larger set of architectural changes.  I hope to have a chan=
ce=20
>>> to look at that in detail this weekend.
>> I'm glad to know that it isn't either unknown or hardware-related. Thank=
=20
>> you for your prompt reply!
> Per my earlier e-mail, I had hoped to merge a larger set of changes from=
=20
> HEAD that resolve the underlying problem here (that inpcb's can be detach=
ed=20
> from a socket while the socket is still in use), but right now I'm=20
> deferring merging those changes as they are somewhat risky (as they are=
=20
> large).  Instead, I've produced a candidate work-around patch, now attach=
ed=20
> to kern/97095.  This does not fix the underlying problem, but seeks to=20
> narrow the window for the race to be exercised by avoiding caching a=20
> volatile pointer across user memory copying, which under load can result =
in=20
> blocking I/O.  I would be quite interested in knowing if this resolves th=
e=20
> problem in practice -- if so, it's a definite short-term merge candidate =
to=20
> reduce the symptoms of this problem until the proper fix can be merged.

> http://www.watson.org/~robert/freebsd/netperf/20060628-ip_ctloutput.diff

Thank you for the patch. I'll let you know in few days if the crash
occurs again. It's quite reproducible (crashed yesterday in the same
code path).

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFEop2NadU+vjT62TERAgMCAJ0dnVFFEKy4jKHDl1zF0TAOKaaHhACeJGYs
XiAUiw8xgibEaCpGRSjKaHI=
=kaWo
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--



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