Does the e1000e driver from our Sourceforge site work correctly for you? It's available at http://e1000.sf.net
I'm not that anything is wrong either but at least we would know that that the 2 driver versions are doing something differently or not. Cheers, John ----------------------------------------------------------- "...that your people will judge you on what you can build, not what you destroy.", B. Obama, 2009 >-----Original Message----- >From: Craig Johnston [mailto:agsp...@gmail.com] >Sent: Tuesday, December 22, 2009 2:29 PM >To: e1000-devel@lists.sourceforge.net >Subject: [E1000-devel] How to force fiber link up when >connected in simplex mode > >For some complex security related reasons, we have a system where we >are broadcasting data packets from one machine to another via a >simplex fiber optic link. For the simplex link, we run a single fiber >from the Tx of the source to the Rx of the sink. We are using RHEL5.3 >on both ends of the connection, with the E1000e driver. The quad-NICs >in the source and sink computers use an Intel 82571EB controller with >a fiber optic transceiver. > >In order to trick the source interface into thinking it had link, we >jumpered a short FO cable from the Tx of an unused interface on the >source NIC (the donor) to the Rx of the transmitting interface. The >sink receiver is perfectly happy with seeing just the Rx signal. > >This worked fine until we recently upgraded our RHEL5.3 kernel from >2.6.18-128 to 2.6.18-164. Since then, the donor interface >continuously bounces its transmitter up and down (autoneg?). Every >time the donor bounces, the source interface looses link and bounces >with it, and the sink interface follows in turn. We notice that there >are a number of E1000e driver updates in the new kernel that have >likely changed this behavior. > >I'm not suggesting that this is a bug, as it is probably the way it is >supposed to work, but we are looking for a work-around that will allow >us to operate as we did before. We have tried various things like >turning off auto negotiation, but have not found a way around this. >We would like a method to either force the source interface to be up >even in the absence of a Rx signal, or to get the donor interface to >stop bouncing its Tx signal (like in the good old days). > >Any tips or tricks would be appreciated. > >Craig > >--------------------------------------------------------------- >--------------- >This SF.Net email is sponsored by the Verizon Developer Community >Take advantage of Verizon's best-in-class app development support >A streamlined, 14 day to market process makes app distribution >fast and easy >Join now and get one step closer to millions of Verizon customers >http://p.sf.net/sfu/verizon-dev2dev >_______________________________________________ >E1000-devel mailing list >E1000-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/e1000-devel > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
