Date: Mon, 14 Jun 2010 14:59:10 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Xin LI <delphij@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Multiple stability issues with r208557, r208809 on amd64 Message-ID: <AANLkTilsJfceKrX2BofgH70YiBJ1txuBgszXXArYFF1A@mail.gmail.com> In-Reply-To: <AANLkTinXbfPfMQIBnP4UdRxM6zEDHy5OMhI5JCcyQDad@mail.gmail.com> References: <AANLkTimwNTFicmuXvMlTAuQpoJxGFzP870S3bJhyg6Rh@mail.gmail.com> <AANLkTimRkJUp7OzLRhGpivceIKWxA0gAVr8wLivLBRyB@mail.gmail.com> <AANLkTinXbfPfMQIBnP4UdRxM6zEDHy5OMhI5JCcyQDad@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 8, 2010 at 5:37 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> On Tue, Jun 8, 2010 at 4:59 PM, Xin LI <delphij@gmail.com> wrote:
>> Do you mean between the two revisions or something? =A0I committed
>> r208557 which doesn't seem likely to cause any runtime issue; 208809
>> is isp(4) change which is not part of your kernel...
>>
>> [delphij@delta] /usr/src> svn log -r 208557
>> ------------------------------------------------------------------------
>> r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lin=
es
>>
>> Grammar nits.
>>
>> Submitted by: =A0 b. f. <bf1783 googlemail com>
>>
>> ------------------------------------------------------------------------
>> [delphij@delta] /usr/src> svn diff -c 208557
>> Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- release/doc/en_US.ISO8859-1/relnotes/article.sgml =A0 (revision 2085=
56)
>> +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml =A0 (revision 2085=
57)
>> @@ -327,7 +327,7 @@
>> =A0 =A0 =A0 based on <filename>libarchive</filename>, have replaced the =
GNU
>> =A0 =A0 =A0 Binutils versions of these utilities.</para>
>>
>> - =A0 =A0<para>BSD-licensed version of &man.bc.1; and &man.dc.1; has
>> + =A0 =A0<para>BSD-licensed versions of &man.bc.1; and &man.dc.1; have
>> =A0 =A0 =A0 replaced their GNU counterparts.</para>
>>
>> =A0 =A0 <para role=3D"merged">&man.chflags.1; now supports a
>> <option>-v</option> flag for
>> @@ -378,7 +378,7 @@
>> =A0 =A0 =A0 disable the use of TCP options.</para>
>>
>> =A0 =A0 <para>&man.nc.1;'s <option>-o</option> switch has been deprecate=
d.
>> - =A0 =A0 =A0It will be removed in future release.</para>
>> + =A0 =A0 =A0It will be removed in a future release.</para>
>>
>> =A0 =A0 <para>The &man.ping6.8; utility now returns <literal>2</literal>
>> =A0 =A0 =A0 when the packet transmission was successful but no responses
>
> Hi Xin!
>
> Well, I hope that that wouldn't cause my machine to tank (otherwise it
> likes to be a grammar nazi too much :P)...
>
> What I was trying to identify is a general trend in terms of
> evaluation of different versions of CURRENT; somewhere after the code
> revision that I noted (r206173), the code appears to be regressing
> more and more to the point where CURRENT has become completely
> unusable to me in a development scenario, other than just a throwaway
> NFS rootfs, s.t. recent code changes need to be thoroughly inspected
> and the regression / multiple regressions needs to be root caused
> before 9.0-RELEASE, otherwise this will definitely gate multiple
> people from upgrading to newer versions of FreeBSD. This probably is
> somewhat related to the locking changes, and the fact that several
> drivers might have been broken before, but because there were
> safeguards around certain sections of code, or because it was
> operating at a slow enough rate, the system itself appeared sane and
> happy from the outside. But that's probably just useless conjecture
> anyhow...
>
> I realize that CURRENT is supposed to be relatively in flux and it's
> primarily for development and evaluation, but I thought that the whole
> point of having development branches was to avoid the scenario where
> the software itself was completely unusable on dev boxes so that
> several folks could work in parallel with [relatively] minor conflicts
> between each others' changes. Part of the reason why I've avoided
> passing along pkg_install patches -- I want to make sure that I do my
> job in testing things to a large degree so I don't break other
> peoples' machines unnecessarily (and I'm sure that the bulk majority
> of developers on the project feel the same as well).
Long story short, I downgraded to 8-STABLE (r209169), and the
issue appears to be occurring with ipfw whenever I push through a
non-trivial (but not large) number of packets on my bce(4) enabled
interface. I'll bring this up with the net@ folks.
If this keeps up, I might have to downgrade further down 8-STABLE
until I figure out the root cause :(...
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilsJfceKrX2BofgH70YiBJ1txuBgszXXArYFF1A>