Re: Packet-corruption with re(4)
On Apr 29, 2008, at 2:08 PM, Jeremy Chadwick wrote: I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/ 1000 GT or PT. Realtek has a well-known history of issues. Just wanted to tell you guys that so far a em(4) seems to have fixed the problem. -- Peter Ankerstål [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, 2008-04-29 at 22:58 +0200, Torfinn Ingolfsen wrote: > On Tue, 29 Apr 2008 05:08:34 -0700 > Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > I'd recommend staying away from Realtek NICs. Pick up an Intel > > Pro/1000 GT or PT. Realtek has a well-known history of issues. > > I hear that story very often, so often that I almost think it's a fairy > tale. :-) > Most of the times the "RealTek NIC" story is told, it isn't backed up > with any references to evidence. Draw your own conclusions. Well, my latest encounter with "Netgear GA311 Rev. A1 (RTL8169S-32) Gigabit Ethernet" falls neatly into the "fairy tale" category -- it has jittery bit in the chip ID register and will advertise itself as 8129 or 8169 depending on the phase of the moon. While it is not fair to judge the whole product line based on the single specimen, it took me some time to figure it out, and, on top of that, I have wasted time of some people, valuable to the FreeBSD project, who were kind enough to review submitted PR and close it. I am not planning on buying more of these to get representative statistics, though ;) The card in question was purchased as the replacement for the 'fxp', which was sitting in that system for a long while, so I think I am in my right to blame the card and not the system. -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, 29 Apr 2008, Jeremy Chadwick wrote: I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/1000 GT or PT. Realtek has a well-known history of issues. Just a note about the Intel Pro/1000 GT: it is on-sale[1] at NewEgg with free shipping. I just bought my third one to replace an on-board NIC (Marvell Yukon 88E8056) with auto-negotiation problems and an inability to take advantage of jumbo frames at the same time as checksum offloading. Sean 1. http://www.newegg.com/Product/Product.aspx?Item=N82E16833106121 -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, Apr 29, 2008 at 10:58:55PM +0200, Torfinn Ingolfsen wrote: > On Tue, 29 Apr 2008 05:08:34 -0700 > Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > I'd recommend staying away from Realtek NICs. Pick up an Intel > > Pro/1000 GT or PT. Realtek has a well-known history of issues. > > I hear that story very often, so often that I almost think it's a fairy > tale. :-) > Most of the times the "RealTek NIC" story is told, it isn't backed up > with any references to evidence. Draw your own conclusions. First, I'd check out the BUGS section of the re(4) and rl(4) manpages. Second, I'd look at some of the CVS commit messages for said drivers; you'll find a plethora of bugs which aren't mentioned in the manpages either: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c Third, have you tried reading any of their technical/designer docs for their ICs? They're horrible. Very hard to read, and lack concise descriptions. There's a lot of missing data. > I can only tell in my experience (several motherboards from > different manufacturers) with integrated RealTek NICs, both 10/100 and > 10/100/1000), RealTek NICs have mostly been working as advertised, > without trouble. And in my experiences, Realtek PHYs are absolutely horrible when it comes to auto-negotiation. I've only had the "pleasure" of dealing with Realtek trash on Windows, where occasionally you'll find a Changelog that comes with the driver set. They "play around" with auto-neg methodologies in the code quite often. If you go through the -stable archives, you'll see Realtek is continually complained about from an end-user perspective. The state of affairs is sad, since many consumer motherboard vendors use Realtek exclusively (I'm looking at you, Gigabyte). It's sad that most (not all) consumer boards lack Intel PHY/NICs these days. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, 29 Apr 2008 05:08:34 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > I'd recommend staying away from Realtek NICs. Pick up an Intel > Pro/1000 GT or PT. Realtek has a well-known history of issues. I hear that story very often, so often that I almost think it's a fairy tale. :-) Most of the times the "RealTek NIC" story is told, it isn't backed up with any references to evidence. Draw your own conclusions. I can only tell in my experience (several motherboards from different manufacturers) with integrated RealTek NICs, both 10/100 and 10/100/1000), RealTek NICs have mostly been working as advertised, without trouble. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, 29 Apr 2008 13:18:10 +0200 Peter Ankerstål <[EMAIL PROTECTED]> wrote: > Hi, > > Im using a built in re(4) card and it seems like its causes data- > corruption as soon as it gets some load (or after a few hours online) IIRC, this is a known issue with if_re and 7.0-R. It is fixed in 7.0-stable, but I don't remember the date. You can find patches here: http://people.freebsd.org/~yongari/re/ In my case, the problem raised its ugly head after some (unknown) amount of data had been transferred. HTH -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, Apr 29, 2008 at 02:30:27PM +0200, Peter Ankerstål wrote: > > On Apr 29, 2008, at 2:08 PM, Jeremy Chadwick wrote: >>> >> >> tcpdump reporting "bad cksum" can occur due to TX/RX checksum >> offloading. Do you not see this message normally, but only when the >> problem begins? >> >> Have you tried turning off TX/RX offloading to see if the erroneous >> behaviour goes away? >> >> Have you tried disabling RFC1323 to see if that's actually what's >> responsible for the stalls you're seeing? sysctl net.inet.tcp.rfc1323=0 >> >> I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/1000 >> GT or PT. Realtek has a well-known history of issues. >> > > Now Ive tried: > ninja# sysctl net.inet.tcp.rfc1323=0 > net.inet.tcp.rfc1323: 1 -> 0 > ninja# ifconfig re0 -rxcsum -txcsum -tso -lro > > The problem remains, but when I have -rxcsum/tx tcpdump does not say > anything > about bad checksums but it send out the same ack over and over. > and it seems like bigger files are the most effected (images rather then > html-files) Okay, so the problem is likely not with checksums, but more of a problem with network I/O suddenly stopping for no apparent reason. Have you tried disabling MSI/MSI-X via /boot/loader.conf to see if that makes any difference? I wonder if somehow interrupts are no longer firing for the re(4) card. Try putting these in loader.conf and rebooting: hw.pci.enable_msi="0" hw.pci.enable_msix="0" Otherwise, I think Pyun YongHyeon might have some better ideas. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Apr 29, 2008, at 2:08 PM, Jeremy Chadwick wrote: tcpdump reporting "bad cksum" can occur due to TX/RX checksum offloading. Do you not see this message normally, but only when the problem begins? Have you tried turning off TX/RX offloading to see if the erroneous behaviour goes away? Have you tried disabling RFC1323 to see if that's actually what's responsible for the stalls you're seeing? sysctl net.inet.tcp.rfc1323=0 I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/ 1000 GT or PT. Realtek has a well-known history of issues. Now Ive tried: ninja# sysctl net.inet.tcp.rfc1323=0 net.inet.tcp.rfc1323: 1 -> 0 ninja# ifconfig re0 -rxcsum -txcsum -tso -lro The problem remains, but when I have -rxcsum/tx tcpdump does not say anything about bad checksums but it send out the same ack over and over. and it seems like bigger files are the most effected (images rather then html-files) I know, I have em in all other machines.. :/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet-corruption with re(4)
On Tue, Apr 29, 2008 at 01:18:10PM +0200, Peter Ankerstål wrote: > Im using a built in re(4) card and it seems like its causes data-corruption > as soon as it gets some load (or after a few hours online) > > The machine is running FreeBSD 7.0R: > > FreeBSD ninja 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Wed Apr 16 22:49:15 CEST > 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NINJA amd64 > > (using a RELENG_7 kernel updated today) > > > If I download alot of files with wget or something everything works fine > for a while until the download just stalls and tcpdump reports "bad cksum" > > 13:04:25.839408 IP (tos 0x0, ttl 64, id 23912, offset 0, flags [DF], proto > TCP (6), length 1500, bad cksum 0 (->f40a)!) host1.http > host2.53895: . > 115065:116513(1448) ack 1421 win 8326 2174233192> > and so on > again and again until the connection times out. tcpdump reporting "bad cksum" can occur due to TX/RX checksum offloading. Do you not see this message normally, but only when the problem begins? Have you tried turning off TX/RX offloading to see if the erroneous behaviour goes away? Have you tried disabling RFC1323 to see if that's actually what's responsible for the stalls you're seeing? sysctl net.inet.tcp.rfc1323=0 I'd recommend staying away from Realtek NICs. Pick up an Intel Pro/1000 GT or PT. Realtek has a well-known history of issues. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Packet-corruption with re(4)
Hi, Im using a built in re(4) card and it seems like its causes data- corruption as soon as it gets some load (or after a few hours online) The machine is running FreeBSD 7.0R: FreeBSD ninja 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Wed Apr 16 22:49:15 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NINJA amd64 (using a RELENG_7 kernel updated today) If I download alot of files with wget or something everything works fine for a while until the download just stalls and tcpdump reports "bad cksum" 13:04:25.839408 IP (tos 0x0, ttl 64, id 23912, offset 0, flags [DF], proto TCP (6), length 1500, bad cksum 0 (->f40a)!) host1.http > host2.53895: . 115065:116513(1448) ack 1421 win 8326 and so on again and again until the connection times out. re0: port 0xb800-0xb8ff mem 0xff9ff000-0xff9f irq 19 at device 0.0 on pci3 re0: Using 2 MSI messages miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:60:74:be:e3 re0: [FILTER] re0: [FILTER] [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet A strange thing is that encrypted data seems to work better than plaintext. https works for a longer time (after boot) then http for example. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
