Multiple stability issues with r208557, r208809 on amd64

[Garrett Cooper]

On Tue, Jun 8, 2010 at 5:37 PM, Garrett Cooper <yanefbsd at gmail.com> wrote:
> On Tue, Jun 8, 2010 at 4:59 PM, Xin LI <delphij at gmail.com> wrote:
>> Do you mean between the two revisions or something?  I 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 at delta] /usr/src> svn log -r 208557
>> ------------------------------------------------------------------------
>> r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lines
>>
>> Grammar nits.
>>
>> Submitted by:   b. f. <bf1783 googlemail com>
>>
>> ------------------------------------------------------------------------
>> [delphij at delta] /usr/src> svn diff -c 208557
>> Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml
>> ===================================================================
>> --- release/doc/en_US.ISO8859-1/relnotes/article.sgml   (revision 208556)
>> +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml   (revision 208557)
>> @@ -327,7 +327,7 @@
>>       based on <filename>libarchive</filename>, have replaced the GNU
>>       Binutils versions of these utilities.</para>
>>
>> -    <para>BSD-licensed version of &man.bc.1; and &man.dc.1; has
>> +    <para>BSD-licensed versions of &man.bc.1; and &man.dc.1; have
>>       replaced their GNU counterparts.</para>
>>
>>     <para role="merged">&man.chflags.1; now supports a
>> <option>-v</option> flag for
>> @@ -378,7 +378,7 @@
>>       disable the use of TCP options.</para>
>>
>>     <para>&man.nc.1;'s <option>-o</option> switch has been deprecated.
>> -      It will be removed in future release.</para>
>> +      It will be removed in a future release.</para>
>>
>>     <para>The &man.ping6.8; utility now returns <literal>2</literal>
>>       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