Re: Procedure to replace a NIC - RESOLVED?

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

 



Steven Stromer wrote:
Robert L Cochran wrote:
I noticed on the Realtek site that there is no downloadable driver for the 2.6 kernel.


http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1&famid=4&series=2003072&Software=True

Download the source code. Unzip the tarball.

There is a C program in the src directory that has to be corrected
before it will compile:

http://gentoo-wiki.com/HARDWARE_RTL8168

From the r1000_v1.04 directory:

su
make
depmod -a

The module will build and install correctly with no changes to any of
the Makefiles.

Probably you will find the tulip driver has been erroneously loaded. Get
rid of it:

rmmod tulip

change to the correct /lib/modules.../net directory then

insmod r1000.ko

This should get the Realtek working.

One last bit of advice -- it took me about 15 minutes of Googling to
locate the links above. That was with time to sip coffee. I got my
Realtek 8168 gigabit adapter for PCIe running as soon as I did the
insmod, and I'm using it now to send this email. Why not try Google a
little more in the future?

Bob Cochran


Steven --

The r8169 driver sounds like it might have its roots based on the 2.4
kernel. I would remove it (rmmod it) and change modprobe.conf to read

alias eth0 r1000

and reboot.

It would be useful to examine your dmesg output. I don't know how else
you have changed your network scripts. If my suggestion does not fix
your problem, send me your dmesg output as a text file attachment. You
can plug a USB flash drive in your machine and then

dmesg > /put the name of your usb drive here/dmesg.txt

I have several other things to do today, and may not be able to look
over your output till tonight, but I'll review it.
Bob


Bob,

Thank you for your help with my problem. I had changed modprobe.conf to read 'alias eth0 r1000' when I last reported no success, so that hasn't resolved the problem. I rmmod'ed the r8169 driver, but this seems to remove it only until the system is rebooted. dmesg returns some interesting output that may point us to the problem, but I am not able to understand it fully. The pertinent part is as follows:

PCI: Found IRQ 11 for device 0000:00:0f.0
PCI: Sharing IRQ 11 with 0000:00:07.5
PCI: Sharing IRQ 11 with 0000:00:0d.2
eth0: Identified chip type is 'RTL8169S/8110S'.
eth0: r10001.04, the Linux device driver for Realtek Ethernet Controllers at 0xc800, 00:40:f4:ee:2f:ff, IRQ 11
BUG: soft lockup detected on CPU#0!
<c043dad5> softlockup_tick+0x90/0xa1 <c0423d50> update_process_times+0x35/0x57 <c0406134> timer_interrupt+0x60/0x98 <c043db72> handle_IRQ_event+0x23/0x4c
 <c043dc17> __do_IRQ+0x7c/0xd1  <c0405035> do_IRQ+0x63/0x80
 =======================
 <c04036f2> common_interrupt+0x1a/0x20  <c040d556> delay_tsc+0xb/0x13
<c04d8125> __delay+0x9/0xa <e88160bd> R1000_WRITE_GMII_REG+0x36/0x3c [r1000] <e8817208> r1000_init_one+0x69f/0x892 [r1000] <c053d851> __driver_attach+0x0/0x8b <c04dfc3b> pci_device_probe+0x36/0x57 <c053d78d> driver_probe_device+0x45/0x9a
 <c0419231> __cond_resched+0x17/0x28  <c053d8b4> __driver_attach+0x63/0x8b
 <c053d21f> bus_for_each_dev+0x37/0x59  <c053d6ee> driver_attach+0x16/0x18
 <c053d851> __driver_attach+0x0/0x8b  <c053cf25> bus_add_driver+0x6f/0x10d
<c04dfddf> __pci_register_driver+0x5b/0x7d <c0433a69> sys_init_module+0x134f/0x14b2
 <c0423c25> __mod_timer+0x0/0x94  <c0402cb3> syscall_call+0x7/0xb
Realtek RTL8169/8110 Family Gigabit Ethernet Network Adapter
Driver version:1.04
Released date:2006/07/07
Link Status:Linked
Link Speed:1000Mbps
Duplex mode:Full-Duplex
I/O Base:0xC800(I/O port)
IRQ:11

I am trying to research possible causes of the 'BUG: soft lockup detected on CPU#0!', but the lines here are causing me nightmares! on the other hand, there is much more recognition of the card in the final lines than before the switch to the r1000 driver. If you need the rest of the dmesg output, please let me know. I tried to parsse it down to what I thought to be the essentials.

Thanks again for your help!

Steven


An update...

This problem was occurring on a fresh install of FC5, so I decided that it would take less time to reinstall than any other solution, as I NEEDED this NIC working. When I reinstalled FC5 with the NIC in the machine, it configured without a hitch. I know that this was a cop-out to resolving the problem, but I needed to get on with my life. It also shows that this is not a simple 'plug and play' situation, as a warning for others who have limited experience with handling such a situation. If you return to the beginning of this thread, I was led to believe that having the right driver as a module available to the kernel was the only item I would have to check on (which was evidently the case, based on the successful reinstall), and that if this was the case, the install would go flawlessly; three sleepless nights later, I know better. When I get the chance, I will try to figure out what files weren't updating properly. Thanks again for all the attempts to help me, with special thanks to Bob Cochran!

Steven


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux