<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.
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.
Good deal.
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
Ah, but you should in your logs, or - if you're running 6.2 - possibly in /etc/udev/rules.d/70-persistant-net.rules.
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
<snip>
In that case, sounds like the OEM had a q/c problem.
mark
Mark,
That's interesting. Here are the log entries for the previous card as well as the eth4 that is currently installed.
# PCI device 0x10ec:0x8168 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b3:10:f6:81", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
# PCI device 0x10ec:0x8168 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b3:10:fc:6e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
Looks like addresses are close.
Greg