Svavar Örn Eysteinsson wrote: > I installed the new driver with your procedures below, and issued a > "modprobe e1000 TxDescriptorStep=4,4,4 > My dmesg logs finally showed parameters : > Good. I don't follow a lot of the network manager messages, but most importantly, the TXDescriptorStep parameter is applied on each of your 3 interfaces, and they all came up.. > > Then I issued a "ethtool -K eth0 tso off" > > Oct 7 16:43:56 localhost kernel: e1000: eth0: e1000_set_tso: TSO is > Disabled > > > Then I asked my collogue of mine to issue a fast, and large download > from one of my FTP servers. > As soon as he reached about 10 - 11 MB/s in transfer rate it looks > like the eth0 interface just goes down, and pops up somewhat again. > > I get these in my logs : > > Oct 7 16:55:36 localhost kernel: e1000: eth0: e1000_watchdog_task: > NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX > (I think this comes right after I execute my firewall script)
I'm a bit confused. I can see that the eth0 link goes down, and then up again - but when exactly ? Is it occurring after you execute the firewall script if the ftp data rate is already > 10MB/s ? Does the link bounce down & back if the firewall script isn't executed ? Does the link bounce if the firewall script is executed even if there's no traffic ? And are there no longer any "Detected Tx Unit Hang" messages in the log ? If the TX Hang messages are gone, the initial issue may already be resolved. Knowing the answer to these questions will help me to decide what to do next, and to more closely align my system for reproduction of the issue you are seeing. > > One thing I don't understand is, if the interface goes down and comes > right up after 1-2sec or so, why doesn't the firewall (netfilter) > rules hang in ? > Why do I have to relaunch interface config, and netfilter rules ? I don't know. Its possible (though unlikely) that if the one of the Gateway interfaces is DHCP served, it could come back up and be served a new IP address, which would break any existing connections. As I say this is not likely. I am running a NAT firewall now (with 82541PI on the 'private' side, and an 82572EI on the 'public' interface, in an attampt to repro this very issue, and see only a momentary interruption in continuous traffic streaming when I ifdown and then ifup either the public or private interfaces. Do you think it is possible that your firewall itself may be causing a problem ? If your firewall is simply a set of IPTables rules, we could try and run it (or something like it) here. > > At the end, I will defiantly try to replace my HP Procurve 2524 with > another one, but I don't think the Procurve is the problem.... Or what? > As today the port, and the interface are both configured with AutoNeg, > And Full Duplex… > I agree, the switch is probably not the problem here. > > As before, I had a another firewall server that had the old 3COM 3C905 > cards. > In time to time, I also got Tx Unit hangs on those cards, but the > internet link, and or netfilter rules, network configuration never > crashed. > It just keep going and going regard of those tx unit hangs. > > That was one of my main reasons I upgraded to INTEL e1000 cards. To > upgrade my old PC, 3com cards and to handle my 100MB fiber dark fiber > with ~200 devices connected in 3-4 networks doing NAT and pretty things. > > Correct me if I'm wrong, this Tx Unit hang problem on e1000 is what > most related to AMD, and or AMD chipset platforms ? > Yes, you are right. There are a lot of things that can cause a "TX Unit Hang", but I was hoping that this one was the one that we had already tied to older AMD platforms. > Today I found a old PC that only collects dust in my company. It has > the legendary Intel 440BX (same as in Cisco Pix) chipset and also 2x > SMP Intel Celeron 533 CPU's. > Would it be a problem solver to change my rusty AMD, VIA combination > in my current firewall to a rock solid 440BX with Intel CPU's ? I would hope so. > > I remember, that I never had any problems at all with PIII and or > Intel chipset mobos in the past. > > Thanks allot. > > In desperate need for help. :) > > Best regards, > > Svavar O > Reykjavik - Iceland > > > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
