Re: NIC Questions for 6.1 Release
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.17content-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.17content-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.16r2=1.91.2.17 (colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91.2.16r2=1.91.2.17f=h) to branchpoint 1.91 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91r2=1.91.2.17 (colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.91r2=1.91.2.17f=h) next main 1.92 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92r2=1.91.2.17 (colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92r2=1.91.2.17f=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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Questions for 6.1 Release
Alex Zbyslaw wrote: 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. Sorry for the hideous http links in previous email. What *I* saw before I sent it was not what I got. sigh Also, download the RELENG_6 versions of the files if you try this approach. Downloading the HEAD versions would be riskier and more likely to fail. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Questions for 6.1 Release - Obtaining changes not in RELEASE
On Sep 13, 2006, at 4:03 AM, 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 ... 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.17content-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.17content- 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.16r2=1.91.2.17 (colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ if_bge.c.diff?r1=1.91.2.16r2=1.91.2.17f=h) to branchpoint 1.91 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ if_bge.c.diff?r1=1.91r2=1.91.2.17 (colored http:// www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff? r1=1.91r2=1.91.2.17f=h) next main 1.92 http://www.freebsd.org/ cgi/cvsweb.cgi/src/sys/dev/bge/if_bge.c.diff?r1=1.92r2=1.91.2.17 (colored http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/bge/ if_bge.c.diff?r1=1.92r2=1.91.2.17f=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 Alex, Excellent and detailed information. I read the handbook and Complete FreeBSD but couldn't grasp the relationship between CURRENT, STABLE, and RELEASE and the cvsup tags definitively. This is important when buying new hardware running ahead of RELEASE changes (e.g. the Broadcom 5704). Last time (a then leading edge server with a U320 Adaptec controller), I manually updated the driver source just to get it to production and made my source out of sync and then feared cvsuping further. I think you've given me, in a nutshell, how to do this more responsibly. Let me take a shot at it for posterity. 1. Take the machine to STABLE via RELENG_6, if it tests reliably, go production and freeze 2. security patch through the .asc file patches until RELEASE 6.2 3. cvsup to RELEASE 6.2 aka RELENG_6_2 (when available and if needed hardware changes were indeed incorporated) 4. given no hardware additions, continue to cvsup on RELENG_6_2_0 for Security Patches
Re: NIC Questions for 6.1 Release - Obtaining changes not in RELEASE
Chris wrote: Excellent and detailed information. I read the handbook and Complete FreeBSD but couldn't grasp the relationship between CURRENT, STABLE, and RELEASE and the cvsup tags definitively. This is important when buying new hardware running ahead of RELEASE changes (e.g. the Broadcom 5704). Last time (a then leading edge server with a U320 Adaptec controller), I manually updated the driver source just to get it to production and made my source out of sync and then feared cvsuping further. I think you've given me, in a nutshell, how to do this more responsibly. Let me take a shot at it for posterity. RELENG = The official release versions; as well tested as things come. Only get security patches. CURRENT = The very bleeding edge. Updated often. Not recommended for any critical machine. STABLE = Changes that have run well in CURRENT, fix problems or improve performance etc, and are things which will form part of the next RELEASE. Bugs and other issues much less likely than CURRENT. So developed software generally goes from CURRENT (when tested) - STABLE - next RELENG. But, not all software in CURRENT automatically goes to STABLE. CURRENT (right now) is what will be RELENG_7_0, and not all changes there will be suitable for 6. 1. Take the machine to STABLE via RELENG_6, if it tests reliably, go production and freeze 2. security patch through the .asc file patches until RELEASE 6.2 3. cvsup to RELEASE 6.2 aka RELENG_6_2 (when available and if needed hardware changes were indeed incorporated) 4. given no hardware additions, continue to cvsup on RELENG_6_2_0 for Security Patches for server life-cycle This should work fine. In step 4, you can consider upgrading from RELENG_6_2 to RELENG_6_3 etc etc, obviously testing. The more critical a machine, however, the less likely you are to want to do that. If you have any kind of farm, then keeping identical hardware and using one machine as a test bed for any upgrades is also a possible scenario. The farm can be as small as two machines - one a backup for the other, but also usable for testing upgrades. I think it would be technically possible (if unlikely), that a security patch for STABLE might not apply cleanly if you are not running the latest STABLE. In such a case, you might again have to bite the bullet and update to the latest STABLE and test again. This is only likely to happen if the bug is some kind of kernel internal, and even then only if some other code for it in STABLE has changed since you did your upgrade. As I say, I think this would be unlikely. Depending on what the machine in question actually does, how it is firewalled etc, it might be that you don't even bother to apply a security patch. (No doubt some will shout when I say that), but you have to analyse what risk the security whole actually poses to *your machine*. You could always seek advice here if such an issue arises, I think a light is clicking on. Thanks VERY much, You're welcome. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
NIC Questions for 6.1 Release
I've had nightmares with my AMD65 Tyan quad that were most likely caused by the Broadcom built-in NICs. There are a lot of folks who've reported problems not only on FreeBSD, but also Windows and Linux. The issues seem to be negotiation problems and then packet loss if negotiation is disabled. I found that if you include a bad cable in the mix, FreeBSD 6.0 STABLE gave unannounced hard hangs and FreeBSD 6.1 RELEASE would panic. With the cable replaced, the system finally stayed up but I found that it would just tend to drop off the net occasionally for a few seconds here and there. Too often to really be usable. I'm bringing that server back in to rebuild it on p6 in hopes of getting it stable enough to finally go into production. I have to verify that the bge driver problems have been fixed since the May release (if they are fixable) but have been unable to determine if changes have been made. Is there any single source where one can go to see what has been changed on the various components of the OS. The notes, errata, hardware.txt, UPDATING, and many other normal places one looks doesn't really provide this this level of detail. I can research if someone has an idea where you would research? On the other hand, any of you have inside information on the broadcom itself, is it hopeless, and would going to the Intel PRO/1000 MT fix my problems with more surety? These are coming out of the boot as: bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 The computer is a Tyan s4884 quad opteron (duals). Thanks, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Questions for 6.1 Release
On Sep 12, 2006, at 12:01 PM, Peter A. Giessel wrote: On 2006/09/12 10:52, Chris seems to have typed: These are coming out of the boot as: bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 The computer is a Tyan s4884 quad opteron (duals). I have a Tyan S2882G3NR-D with: bge0: Broadcom BCM5704C Dual Gigabit Ethernet, ASIC rev. 0x2003 mem 0xfc9c-0xfc9c,0xfc9b-0xfc9b irq 24 at device 9.0 on pci2 running on the AMD64 version of FreeBSD: FreeBSD 6.1-RELEASE-p2 #4: Sun Jul 2 22:27:35 AKDT 2006 (dual Opteron 246's) Its been stable since the update to 6.1 (went from 6.0 directly to 6.1-p2). This is encouraging. I will forego the cost of the Intel NICs and just go to 6.1-p6. Thank you very much. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Questions for 6.1 Release
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/ Especially for changes to limited components like a specific ethernet driver, it quite easy to see if anything has changed recently, as well as the comments in the commit logs. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Questions for 6.1 Release
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. Thanks for all this input, it's pretty embarrassing to idle such a cool server for 6 months ;-), Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
