NIC Questions for 6.1 Release

[Alex Zbyslaw]

Chris wrote:

>
> On Sep 12, 2006, at 3:12 PM, Alex Zbyslaw wrote:
>
>> Chris wrote:
>>
>>> Is there any single source where one can go  to see what has been  
>>> changed on the various components of the OS.
>>
>> Go to the source :-)
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/
>>
> Wow! That's an excellent resource and the bge driver does have  
> numerous changes that all dance around or on the same issues. It  
> appears they've been being addressed for months. Supporting that, two  
> people have responded and said both a Tyan and several IBMs are  
> working perfectly with the Broadcom.
>
> Based on the 6.1-RELEASE-p6 AMD64 system I did yesterday (a different  
> server), I didn't see any of these changes on the source date for  
> if_bge.c. I'm guessing this has to do with how I cvsup and the fact  
> that I remain tracking only 6.1-RELEASE. I used:
>
> *default release=cvs tag=RELENG_6_1
>
> in the supfile and these changes are not pulled under that tag. How  
> does one approach that, set the tag to RELENG_6 which does grab  
> these. From the handbook it seems to recommend not moving forward  
> from a "RELEASE" for a production type of implementation. How does  
> one grab specific changes to a driver without actually cvsupping to  
> that entire revision or am I missing something really basic and I  
> should be using the RELENG_6 tag for my production servers? It really  
> looks like that's the version of the bge driver I should be using.

If you click on if_bge.c (which I guess you did to see all the 
comments), you'll see above each comment a "Branch: " which tells you 
where the changes have been committed.  E.g.

> Revision *1.91.2.17* 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c?rev=1.91.2.17&content-type=text/x-cvsweb-markup> 
> / (*download* 
> <http://www.freebsd.org/cgi/cvsweb.cgi/%7Echeckout%7E/src/sys/dev/bge/if_bge.c?rev=1.91.2.17&content-type=text/plain>) 
> - annotate 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c?annotate=1.91.2.17> 
> - [select for diffs] 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c?r1=1.91.2.17>, 
> /Thu Sep 7 08:49:10 2006 UTC/ (6 days, 2 hours ago) by /oleg/
> Branch: *RELENG_6 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c?only_with_tag=RELENG_6> 
> *
> Changes since *1.91.2.16: +24 -5 lines*
> Diff to previous 1.91.2.16 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91.2.16&r2=1.91.2.17> 
> (colored 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91.2.16&r2=1.91.2.17&f=h>) 
> to branchpoint 1.91 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91&r2=1.91.2.17> 
> (colored 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91&r2=1.91.2.17&f=h>) 
> next main 1.92 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92&r2=1.91.2.17> 
> (colored 
> <http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92&r2=1.91.2.17&f=h>) 
>
>
>MFC rev. 1.140
>Properly lock ifmedia callbacks. This should prevent concurrent access to PHY.
>Following issues should be resolved:
>- random watchdog timeouts (caused by concurrent phy access)
>- some link state issues
>- non working TX if media type was set explicitly
>
>PR:		kern/98738 <http://www.FreeBSD.org/cgi/query-pr.cgi?pr=98738>
>
which looks like one you'd want!  You'll see the tag is RELENG_6 so yes 
you will need to cvsup to this (aka 6-STABLE) to get those changes.  
Presumably the changes will make it to 6.2-RELEASE, so you could switch 
to tracking that when it comes out.  I would be wary of actively 
tracking a production server with STABLE.  If you upgrade to STABLE now 
and it works, just leave it unless there are security patches.

At least one change is to HEAD/Main which is aka 7-CURRENT.  That would 
be risky for a production box.

Alternatively you could just try downloading the two files and copying 
them over your existing ones (after backing them up!) and just try and 
see if a make buildkernel will compile them.  If the changes don't rely 
on anything outside of these two files, you'd likely be fine.  Of 
course, keep a copy of your current working kernel in e.g. 
/boot/kernel.works.

--Alex