Re: how to recreate eth0 - Realtek 8169sc [SOLVED]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux