On 6/20/2012 11:13 AM, Gregory P. Ennis wrote: >> Gregory P. Ennis wrote: >> <snip> >>> I have been chasing a problem with a pci-e TrendNet(TEG-ECTX) gigabit >>> card. After adding the card to a machine with a new Centos 6.2 install >>> and naming it 'eth4' it works well for 6 to 12 hours and then fails. >>> The failure is characterized by dropping its connection speed from 1000 >>> to 100 while not allowing any data to flow in or out. When this happens >>> a shutdown and reboot does not solve the problem, but shutting down and >>> then removing the power does solve the problem. >> <snip> >>> Some additional information that may be useful. The TrendNet card is >>> the second TrendNet card I have used. The first card had the same >>> symptoms, and I deduced the card was bad, and purchased another one. The >>> symptoms are the same with the second card. >> <snip> >> Several questions: do you have another machine on the same network? Does >> *it* show the problem, around the same time? >> >> And, finally, did you buy both TrendNet cards from the same vendor? Are >> their MACs close? If so, it could be the vendor got a bad batch, either >> OEM's fault, or the gorilla who un/loaded it during shipping. >> >> mark >> >> --------------------------------------------------------------------- >> >> Mark, >> >> I have several machines on that network, and only one machine is having >> the problem. The machine is being used as a mail server, web server, >> and gateway for the network. After this problem surfaced with the >> failure of the eth4 card (internal network), I created a gateway out of >> one of the other machines that is working without incident. >> >> I did purchase both TrendNet Cards from Fry's. Fry's was good about >> taking the first one back without question, but now that the second one >> has failed, I thought it best to look deeper. I don't have the previous >> card's MAC address, but my first thought was that this was a bad card >> too. Both the first and second cards did not appear to have any damage >> on the boxes or the card itself. Before I tried to get a third card >> from a different manufacturer I wanted to post things here to see if >> there was an obvious problem I am missing. >> >> Thanks for your help!!! >> >> Greg >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos > If you are having to fully 'cold boot' the system before it will work > again I can't help but wonder if it is a conflict between special > motherboard functions/settings and the card. I've seen this with some > high end video cards under Winders. I am totally speculating here and > have nothing to draw from, but wake on lan functions and such.... just > leaves me wondering. Do you have a different machine/motherboard around > where it wouldn't be hard to set up this testing? Maybe Googling a bit > on motherboard model and eth card model might give a helpful return? > > ------------------------------------------------------------------------ > > John, > > That is a good idea !!! > > I have appended the output of 'ethtool eth4' below. Is there a way to > change the wake setting from the command line as opposed to changing the > bios setting at boot. > > Greg > > Settings for eth4: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Supports auto-negotiation: Yes > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Advertised pause frame use: No > Advertised auto-negotiation: Yes > Link partner advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Link partner advertised pause frame use: No > Link partner advertised auto-negotiation: Yes > Speed: 1000Mb/s > Duplex: Full > Port: MII > PHYAD: 0 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: pumbg > Wake-on: pumbg > Current message level: 0x00000033 (51) > Link detected: yes > > I always disable wake on lan on the motherboard and so far have never had an issue. To me this 'feature' should never be on by default but most of my experience has shown the opposite. I suppose there is good use for this, but I sure don't have one. At the mb bios level, it just seems like another level of security to worry about with little info on 'knowing' the potential. I have no experience with disabling wake on lan on the cards themselves. If this is a mailserver, it seems it should never go to sleep... so if there is a switch to turn off wake on lan in the motherboard bios, I'd turn it off first and see if the issue goes away. If not, I'd hit the lan manufacture site to find this info as it would be specific to each. Or, it might be easier to just try a different manufacturer? -- John Hinton 877-777-1407 ext 502 http://www.ew3d.com Comprehensive Online Solutions