Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Thu, Aug 02, 2007 at 05:20:38PM +0200, Michael Nottebrock wrote: On Tuesday, 31. July 2007, Pyun YongHyeon wrote: On Tue, Jul 31, 2007 at 01:31:59AM +0200, Michael Nottebrock wrote: On Monday, 30. July 2007, Pyun YongHyeon wrote: Thanks for reporting. I don't have these hardware models so I couldn't verify the issue. After reading the vendor's code I've made attached patch. I don't know whether it works or not, it's just guess work. Works fine here! Since HEAD is in code freeze I guess minimal patch would be more preferable. Would you try attached patch again? That one works, too. Patch committed to HEAD(if_re.c, rev. 1.95) Thanks for testing! -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Tuesday, 31. July 2007, Pyun YongHyeon wrote: On Tue, Jul 31, 2007 at 01:31:59AM +0200, Michael Nottebrock wrote: On Monday, 30. July 2007, Pyun YongHyeon wrote: Thanks for reporting. I don't have these hardware models so I couldn't verify the issue. After reading the vendor's code I've made attached patch. I don't know whether it works or not, it's just guess work. Works fine here! Since HEAD is in code freeze I guess minimal patch would be more preferable. Would you try attached patch again? That one works, too. Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org signature.asc Description: This is a digitally signed message part.
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Monday, 30. July 2007, Pyun YongHyeon wrote: Thanks for reporting. I don't have these hardware models so I couldn't verify the issue. After reading the vendor's code I've made attached patch. I don't know whether it works or not, it's just guess work. Works fine here! Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org signature.asc Description: This is a digitally signed message part.
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Tue, Jul 31, 2007 at 01:31:59AM +0200, Michael Nottebrock wrote:
On Monday, 30. July 2007, Pyun YongHyeon wrote:
Thanks for reporting. I don't have these hardware models so I couldn't
verify the issue. After reading the vendor's code I've made attached
patch. I don't know whether it works or not, it's just guess work.
Works fine here!
Since HEAD is in code freeze I guess minimal patch would be more
preferable. Would you try attached patch again?
--
Regards,
Pyun YongHyeon
Index: if_re.c
===
RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v
retrieving revision 1.92
diff -u -r1.92 if_re.c
--- if_re.c 24 Jul 2007 01:24:02 - 1.92
+++ if_re.c 31 Jul 2007 00:49:34 -
@@ -1300,6 +1300,28 @@
goto fail;
}
+ /* Take PHY out of power down mode. */
+ if (sc-rl_type == RL_8169) {
+ uint32_t rev;
+
+ rev = CSR_READ_4(sc, RL_TXCFG);
+ /* HWVERID 0, 1 and 2 : bit26-30, bit23 */
+ rev = 0x7c80;
+ if (rev != 0) {
+ /* RTL8169S single chip */
+ switch (rev) {
+ case RL_HWREV_8169_8110SB:
+ case RL_HWREV_8169_8110SC:
+ case RL_HWREV_8168_SPIN2:
+ re_gmii_writereg(dev, 1, 0x1f, 0);
+ re_gmii_writereg(dev, 1, 0x0e, 0);
+ break;
+ default:
+ break;
+ }
+ }
+ }
+
ifp-if_softc = sc;
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Various problems with re(4) on a PCIe 8168/8111B onboard NIC
After recently updating the windows drivers (I dual-boot Windows XP on the machine the NIC is in), I hit this problem: http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4) like it does the Linux drivers described in the above link. I already wrote the Realtek technical support about it since their own FreeBSD driver (a hacked rl(4) that does not support any of the chip's advanced features) does not manage to power up the PHY on its own either - neither does the motherboard's BIOS when trying to netboot. The other problem is that I have at least two applications misbehaving when rxcsum/txcsum is enabled: - The Linux Second Life client (yes, yes, I know, but it is nice for showing off GLX and it is really really good at generating network traffic) will cease to receive data after about a minute or so - turning off rcxsum/txcsum will mend it on the spot. - A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), cannot receive an ip address via DHCP. Interestingly, this even occurs if rxcsum/txcsum was already turned off before launching Qemu - to make it work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode. I realise that both of these make awful test cases, but so far they are the only applications I found to expose those problems. This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The kernel sources are up to date as of 2007-07-27. The NIC is re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfbfff000-0xfbff irq 36 at device 0.0 on pci3 / [EMAIL PROTECTED]:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org signature.asc Description: This is a digitally signed message part.
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Sunday, 29. July 2007, Kent Stewart wrote: Have you looked at /var/log/messages? I would be surprised if you have not had a number of Jul 27 00:55:32 ruby kernel: re0: watchdog timeout Jul 27 00:55:32 ruby kernel: re0: link state changed to DOWN Jul 27 00:55:35 ruby kernel: re0: link state changed to UP In fact I have and I haven't had any such messages (except link down/up when I switched rxcsum/txcsum, but that is expected - no watchdog timeouts at all). I also should mention that the interface never completely goes dead either. People have complained a long time ago and basically given up on getting it fixed. I saw that yongari@ has been busy trying to brush up re(4) recently, that's why I thought I'd pipe up. :) Cheers, -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org signature.asc Description: This is a digitally signed message part.
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Sunday 29 July 2007, Michael Nottebrock wrote: After recently updating the windows drivers (I dual-boot Windows XP on the machine the NIC is in), I hit this problem: http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4) like it does the Linux drivers described in the above link. I already wrote the Realtek technical support about it since their own FreeBSD driver (a hacked rl(4) that does not support any of the chip's advanced features) does not manage to power up the PHY on its own either - neither does the motherboard's BIOS when trying to netboot. The other problem is that I have at least two applications misbehaving when rxcsum/txcsum is enabled: - The Linux Second Life client (yes, yes, I know, but it is nice for showing off GLX and it is really really good at generating network traffic) will cease to receive data after about a minute or so - turning off rcxsum/txcsum will mend it on the spot. - A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), cannot receive an ip address via DHCP. Interestingly, this even occurs if rxcsum/txcsum was already turned off before launching Qemu - to make it work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode. I realise that both of these make awful test cases, but so far they are the only applications I found to expose those problems. This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The kernel sources are up to date as of 2007-07-27. The NIC is re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfbfff000-0xfbff irq 36 at device 0.0 on pci3 / [EMAIL PROTECTED]:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00. Have you looked at /var/log/messages? I would be surprised if you have not had a number of Jul 27 00:55:32 ruby kernel: re0: watchdog timeout Jul 27 00:55:32 ruby kernel: re0: link state changed to DOWN Jul 27 00:55:35 ruby kernel: re0: link state changed to UP People have complained a long time ago and basically given up on getting it fixed. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
Michael Nottebrock schreef: After recently updating the windows drivers (I dual-boot Windows XP on the machine the NIC is in), I hit this problem: http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4) like it does the Linux drivers described in the above link. I also noticed this and the workaround as explained in the gentoo-wiki works. I already wrote the Realtek technical support about it since their own FreeBSD driver (a hacked rl(4) that does not support any of the chip's advanced features) does not manage to power up the PHY on its own either - neither does the motherboard's BIOS when trying to netboot. I have done the exact same thing and was surprised to receive a response. Attached to this response was a beta-version of their (rl) driver. After a quick test it seemed to have fixed the problem. I have been trying to fix the issue in re(4) by looking at the changes in the beta-driver but have not had any success so far (due to lack of knowledge i guess). I put the beta driver up here: http://www.timkapel.nl/~laurens/rtl_bsd_drv_v174beta3.tgz The other problem is that I have at least two applications misbehaving when rxcsum/txcsum is enabled: - The Linux Second Life client (yes, yes, I know, but it is nice for showing off GLX and it is really really good at generating network traffic) will cease to receive data after about a minute or so - turning off rcxsum/txcsum will mend it on the spot. - A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), cannot receive an ip address via DHCP. Interestingly, this even occurs if rxcsum/txcsum was already turned off before launching Qemu - to make it work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode. I realise that both of these make awful test cases, but so far they are the only applications I found to expose those problems. This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The kernel sources are up to date as of 2007-07-27. The NIC is re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfbfff000-0xfbff irq 36 at device 0.0 on pci3 / [EMAIL PROTECTED]:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Sun, Jul 29, 2007 at 01:27:36PM -0700, Kent Stewart wrote: On Sunday 29 July 2007, Michael Nottebrock wrote: After recently updating the windows drivers (I dual-boot Windows XP on the machine the NIC is in), I hit this problem: http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects re(4) like it does the Linux drivers described in the above link. I already wrote the Realtek technical support about it since their own FreeBSD driver (a hacked rl(4) that does not support any of the chip's advanced features) does not manage to power up the PHY on its own either - neither does the motherboard's BIOS when trying to netboot. The other problem is that I have at least two applications misbehaving when rxcsum/txcsum is enabled: - The Linux Second Life client (yes, yes, I know, but it is nice for showing off GLX and it is really really good at generating network traffic) will cease to receive data after about a minute or so - turning off rcxsum/txcsum will mend it on the spot. - A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4), cannot receive an ip address via DHCP. Interestingly, this even occurs if rxcsum/txcsum was already turned off before launching Qemu - to make it work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous mode. I realise that both of these make awful test cases, but so far they are the only applications I found to expose those problems. This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28 14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The kernel sources are up to date as of 2007-07-27. The NIC is re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xd800-0xd8ff mem 0xfbfff000-0xfbff irq 36 at device 0.0 on pci3 / [EMAIL PROTECTED]:0:0: class=0x02 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00. Have you looked at /var/log/messages? I would be surprised if you have not had a number of Jul 27 00:55:32 ruby kernel: re0: watchdog timeout Jul 27 00:55:32 ruby kernel: re0: link state changed to DOWN Jul 27 00:55:35 ruby kernel: re0: link state changed to UP People have complained a long time ago and basically given up on getting it fixed. You should not see the watdog errors on re(4). If you still see the watchdog timeout errors, please let me know. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Various problems with re(4) on a PCIe 8168/8111B onboard NIC
On Sun, Jul 29, 2007 at 10:48:01PM +0200, Laurens Timmermans wrote:
Michael Nottebrock schreef:
After recently updating the windows drivers (I dual-boot Windows XP on the
machine the NIC is in), I hit this problem:
http://gentoo-wiki.com/HARDWARE_RTL8168#Troubleshooting which affects
re(4) like it does the Linux drivers described in the above link.
I also noticed this and the workaround as explained in the gentoo-wiki
works.
I already wrote the Realtek technical support about it since their own
FreeBSD driver (a hacked rl(4) that does not support any of the chip's
advanced features) does not manage to power up the PHY on its own either -
neither does the motherboard's BIOS when trying to netboot.
I have done the exact same thing and was surprised to receive a
response. Attached to this response was a beta-version of their (rl)
driver. After a quick test it seemed to have fixed the problem.
I have been trying to fix the issue in re(4) by looking at the changes
in the beta-driver but have not had any success so far (due to lack of
knowledge i guess).
I put the beta driver up here:
http://www.timkapel.nl/~laurens/rtl_bsd_drv_v174beta3.tgz
Thanks for reporting. I don't have these hardware models so I couldn't
verify the issue. After reading the vendor's code I've made attached
patch. I don't know whether it works or not, it's just guess work.
The PHY registers used in the patch are reserved one in my datasheet,
so I don't know what it really does on the hardware.
Btw, according to vendor's driver it seems that there are newer
hardware revisions marked as 8168C and 8168CP. These models seems to
need special handling in PHY area. All datasheet I got shows them as
reserved ones. :-(
The other problem is that I have at least two applications misbehaving
when rxcsum/txcsum is enabled:
- The Linux Second Life client (yes, yes, I know, but it is nice for
showing off GLX and it is really really good at generating network
traffic) will cease to receive data after about a minute or so - turning
off rcxsum/txcsum will mend it on the spot.
- A Fedora Core 4 running in Qemu, networked with bridge(4) and tap(4),
cannot receive an ip address via DHCP. Interestingly, this even occurs if
rxcsum/txcsum was already turned off before launching Qemu - to make it
work, I have to cycle rxcsum/txcsum once. Might be related to promiscuous
mode.
I realise that both of these make awful test cases, but so far they are
the only applications I found to expose those problems.
This is on FreeBSD kiste 6.2-STABLE FreeBSD 6.2-STABLE #4: Sat Jul 28
14:11:23 CEST 2007 root@:/usr/obj/usr/src/sys/KISTE-SMP i386. The
kernel sources are up to date as of 2007-07-27.
The NIC is re0: RealTek 8168/8111B PCIe Gigabit Ethernet port
0xd800-0xd8ff mem 0xfbfff000-0xfbff irq 36 at device 0.0 on pci3 /
[EMAIL PROTECTED]:0:0: class=0x02 card=0x81681849 chip=0x816810ec
rev=0x01
hdr=0x00.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Regards,
Pyun YongHyeon
Index: if_re.c
===
RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v
retrieving revision 1.93
diff -u -r1.93 if_re.c
--- if_re.c 27 Jul 2007 00:43:12 - 1.93
+++ if_re.c 30 Jul 2007 04:43:25 -
@@ -180,6 +180,10 @@
RealTek 8168/8111B PCIe Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN2,
RealTek 8168/8111B PCIe Gigabit Ethernet },
+ { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3,
+ RealTek 8168/8111B PCIe Gigabit Ethernet },
+ { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3P,
+ RealTek 8168/8111B PCIe Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169,
RealTek 8169 Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169S,
@@ -221,6 +225,10 @@
{ RL_HWREV_8100E, RL_8169, 8100E},
{ RL_HWREV_8101E, RL_8169, 8101E},
{ RL_HWREV_8168_SPIN2, RL_8169, 8168},
+#ifdef notyet
+ { RL_HWREV_8168_SPIN3, RL_8169, 8168C},
+ { RL_HWREV_8168_SPIN3P, RL_8169, 8168CP},
+#endif
{ 0, 0, NULL }
};
@@ -677,13 +685,20 @@
hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
- if (hwrev == RL_HWREV_8100E || hwrev == RL_HWREV_8101E ||
- hwrev == RL_HWREV_8168_SPIN1 || hwrev == RL_HWREV_8168_SPIN2) {
+ switch (hwrev) {
+ case RL_HWREV_8100E:
+ case RL_HWREV_8101E:
+ case RL_HWREV_8168_SPIN1:
+ case RL_HWREV_8168_SPIN2:
+ case RL_HWREV_8168_SPIN3:
+ case RL_HWREV_8168_SPIN3P:
CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1]));
