|
Rudi,
Sounds like a module conflict/misconfiguration, but anyway glad its working back. have you upgrade this system with the latest kernel build. I am guessing both onboard NICs are the same brand, take a look at messages and see if the card give me problems in the future. make sure you look for packet drops or errors that may hinder a bad NIC in the near future. Put your admin hat on a design a good plan to tackle this issue so you don't sweet it in the near future. Two cents.
>>> Rudi Ahlers <Rudi@xxxxxxxxxxx> 1/10/2011 6:18 AM >>> On Mon, Jan 10, 2011 at 12:08 PM, Rudi Ahlers <Rudi@xxxxxxxxxxx> wrote: > On Mon, Jan 10, 2011 at 11:49 AM, compdoc <compdoc@xxxxxxxxxxxx> wrote: >> I love realtek - the resources they use tend not to conflict with other >> cards or hardware, they don't use much cpu time, the drivers are mature, and >> they don't cost much. What could be better? There does seem to be at least >> one onboard realtek chipset that can have driver issues, but I use the 8169 >> without problems. >> >> But hardware does fail. And any brand of nic can fail in odd ways. I'm >> guessing you've swapped it out? > > Yes, the NIC might have failed, but how do I tell? lspci still shows > it as active. > > >> >> Bios settings can change if the on-board battery is dead and the system >> loses power. (It can set to defaults) But bios settings rarely affect nics - >> you're more likely to see boot problems from a change in drive boot >> sequence. > > I already checked, BIOS settings didn't change :) > >> >> I don't suppose you have a vpn on your lan? I noticed you use the >> 192.168.1.x address range, which is one of the most common ranges in the >> world. If someone connects to your vpn from home or workplace, and if they >> use the same range, and if theres a bridge, addresses are going to >> conflict. > > This is purely cause the ADSL router in the office is on the > 192.168.1.0 subnet, so it's less hassle when it needs to be swapped > out to get it back up again. No VPN. > > >> >> If you delete your ifcfg-eth0 or ifcfg-eth1 files, centos will recreate them >> if it sees the nics at boot. But it tends to enable eth0 and disable eth1 or >> higher. You should have backups of your originals for that reason... > > I've already tried that, but eth0 doesn't automatically get detected. > > >> >> I bet you wish you had a tcp/ip based kvm switch system about now... >> > > Yes, I supposed I could take one from a client server, or open a > sealed one, but it's not really necessary. For now I put in another > D-Link and got the server up that way, but would prefer to use the > onboard one since I had to take everything out of the 1U chassis, > which doesn't support more than 1 additional NIC. > >> >> _______________________________________________ >> > > This is really weird, after I installed the 2nd D-Link card and booted up the server everyone could work again. But I noticed and eth2 being loaded as well, which could only make sense if the onboard NIC was in fact still working. And it was. So I took out the D-Link, deleted eth2, rebooted and it worked again as normal. Why would this happen, or have happened in the first place? Why would a NIC just loose it's drivers like that? -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos |
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
