Problem with Realtek NIC
Hello, I am experiencing weird problem with Realtek network card under FreeBSD. Recently (10 days ago) I cvsup-ed to RELENG_7, so that may be the cause of problem too (although I noticed this only last 2-3 days). Network card looses connectivity in some way after around 1 hour of being connected - in some way because I am able to ping gateway for example but large number of packets is dropped (like first 15 going through, then 40 without reply and so on). If I do ifconfig re0 down and after that ifconfig re0 up everything is restored to working state for another hour. I tested the same machine under windows and everything seems to work normaly. I tried ifconfig re0 -txcsum -rxcsum but that didn't have any effect. Data from dmesg re0: RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet port 0xc400-0xc4ff mem 0xfeaff800-0xfeaff8ff irq 20 at device 4.0 on pci2 re0: Chip rev. 0x1000 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211B media interface PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Any help would be greatly appreciated Regards, Ivan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On Sat, Feb 21, 2009 at 2:55 AM, Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Feb 20, 2009 at 05:25:26PM +0100, Fernando Apestegu?a wrote: Hi all, I copy here the mail I sent to freebsd-questions cause I didn't get any answers: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? I'm not sure you're suffering from MAC power saving issue of RealTek PCIe controller. Sometimes re(4) used to fail to wakeup the controller which in turn resulted in 'no driver' for the controller. If this is the case you can see MII without any phy! message in dmesg output. You are right, I see that message. r188358(cvs if_re.c 1.95.2.40) should fix the issue so please try latest 7-stable or copy if_re.c, if_rlreg.h and if_rl.c from HEAD/ 7-stable to your 7.1-RELEASE box and rebuild kernel. If you still see the same issue please let me know. I copied the files and restarted my computer 5 times and the NIC was present in all of them. I will watch this issue and I will let you know if I notice more problems. Thanks so much for your help. Btw, stable@ is more appropriate list for this type of issues. Even if I'm not using -STABLE? Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On Sun, Feb 22, 2009 at 06:15:55PM +0100, Fernando Apestegu?a wrote: On Sat, Feb 21, 2009 at 2:55 AM, Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Feb 20, 2009 at 05:25:26PM +0100, Fernando Apestegu?a wrote: Hi all, I copy here the mail I sent to freebsd-questions cause I didn't get any answers: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? I'm not sure you're suffering from MAC power saving issue of RealTek PCIe controller. Sometimes re(4) used to fail to wakeup the controller which in turn resulted in 'no driver' for the controller. If this is the case you can see MII without any phy! message in dmesg output. You are right, I see that message. r188358(cvs if_re.c 1.95.2.40) should fix the issue so please try latest 7-stable or copy if_re.c, if_rlreg.h and if_rl.c from HEAD/ 7-stable to your 7.1-RELEASE box and rebuild kernel. If you still see the same issue please let me know. I copied the files and restarted my computer 5 times and the NIC was present in all of them. Glad to hear that. I will watch this issue and I will let you know if I notice more problems. Thanks so much for your help. No problem. Btw, stable@ is more appropriate list for this type of issues. Even if I'm not using -STABLE? Yes, you're not using CURRENT. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On 2/23/09, Pyun YongHyeon pyu...@gmail.com wrote: On Sun, Feb 22, 2009 at 06:15:55PM +0100, Fernando Apestegu?a wrote: On Sat, Feb 21, 2009 at 2:55 AM, Pyun YongHyeon pyu...@gmail.com wrote: On Fri, Feb 20, 2009 at 05:25:26PM +0100, Fernando Apestegu?a wrote: Hi all, I copy here the mail I sent to freebsd-questions cause I didn't get any answers: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? I'm not sure you're suffering from MAC power saving issue of RealTek PCIe controller. Sometimes re(4) used to fail to wakeup the controller which in turn resulted in 'no driver' for the controller. If this is the case you can see MII without any phy! message in dmesg output. You are right, I see that message. r188358(cvs if_re.c 1.95.2.40) should fix the issue so please try latest 7-stable or copy if_re.c, if_rlreg.h and if_rl.c from HEAD/ 7-stable to your 7.1-RELEASE box and rebuild kernel. If you still see the same issue please let me know. I copied the files and restarted my computer 5 times and the NIC was present in all of them. Glad to hear that. I will watch this issue and I will let you know if I notice more problems. Thanks so much for your help. No problem. Btw, stable@ is more appropriate list for this type of issues. Even if I'm not using -STABLE? Yes, you're not using CURRENT. OK, I'll keep that in mind. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FBSD 7.0-p3 NIC driver problem (Realtek)
Hi all, I copy here the mail I sent to freebsd-questions cause I didn't get any answers: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On Fri, 20 Feb 2009, Fernando Apestegu?a wrote: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. Please identify the NIC more precisely with pciconf -lv | grep -B2 Ethernet It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? If you can do 'ifconfig re0' and then the NIC is active, see this: http://www.freebsd.org/cgi/query-pr.cgi?pr=130586cat= -Warren Block * Rapid City, South Dakota USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On Fri, Feb 20, 2009 at 7:15 PM, Warren Block wbl...@wonkity.com wrote: On Fri, 20 Feb 2009, Fernando Apestegu?a wrote: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. Please identify the NIC more precisely with pciconf -lv | grep -B2 Ethernet r...@pci0:2:0:0:class=0x02 card=0x2a6f103c chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? If you can do 'ifconfig re0' and then the NIC is active, see this: No, I can't. The re0 interface is not present. After executing the command it is still missing. Thanks for the help. Should you need more information or me doing some tests, just tell me. http://www.freebsd.org/cgi/query-pr.cgi?pr=130586cat= -Warren Block * Rapid City, South Dakota USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FBSD 7.0-p3 NIC driver problem (Realtek)
On Fri, Feb 20, 2009 at 05:25:26PM +0100, Fernando Apestegu?a wrote: Hi all, I copy here the mail I sent to freebsd-questions cause I didn't get any answers: Yesterday I updated to 7.1-p3 on AMD64 arch. Since then, the NIC is not detected anymore. ifconfig doesn't show it and I can't connect to the Internet. There were well-known issues with this NIC model before, (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-11/msg00299.html) but the weird thing is that it seemed to be fine with 7.1-RELEASE and newer till this -p3. It doesn't recognize the card in 4/5 boot sequences (really annoying). Anybody with this problem? I'm not sure you're suffering from MAC power saving issue of RealTek PCIe controller. Sometimes re(4) used to fail to wakeup the controller which in turn resulted in 'no driver' for the controller. If this is the case you can see MII without any phy! message in dmesg output. r188358(cvs if_re.c 1.95.2.40) should fix the issue so please try latest 7-stable or copy if_re.c, if_rlreg.h and if_rl.c from HEAD/ 7-stable to your 7.1-RELEASE box and rebuild kernel. If you still see the same issue please let me know. Btw, stable@ is more appropriate list for this type of issues. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: Dinesh et al: Did this problem ever get resolved? I'm tracking down a very similar bug with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. Dinish: What platform are you using? You said you had a 4x re(4) SBC, but never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network appliance. URL below. My platform is netbsd-3, but I just tried -current to see if recent rtl8169.c changes fix it. No dice. No dice with NetBSD -current either. FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 probes then fails the diagnostic function, then detatches. re1, re2, re3 all then sucsessfully probe on my system, but then they show no media status and tcpdump(8)/arp(8) show no activity. They're dead in the water. There has also been some mention of the errors below on NetBSD and OpenBSD probably because of the bitrot/driver drift: http://marc.theaimsgroup.com/?t=11165804011r=1w=2 http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a go. I see a 8139C+ fix was commited 5 weeks ago by [EMAIL PROTECTED] Based on some other threads I've been reading on 8139C+ Watchdog Timeouts and Diag failed, failing to attach related messages, I imagine FreeBSD has this covered. re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX re0: interrupting at irq 5 re0: Ethernet address 00:60:e0:e1:3e:31 re0: using 64 tx descriptors ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x00, model 0x, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re: diagnostic failed, failed to receive packet in loopback mode re0: attach aborted due to hardware diag failure ukphy0 detached Long ago re_diag() code was disabled by default(rev 1.68). So I think you should never see the diagnostic failed message on FreeBSD. The other odd thing I see from your demsg output is ukphy(4) attachment. If you boot system with bootverbose mode ukphy(4) would have printed PHY OID and model number. Please let me know the OID/model number. I guess it should use rlphy(4). (If you should use NetBSD you may need to define MIIVERBOSE to active verbose message.) -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Wed, Oct 18, 2006 at 10:55:11AM +0900, To Brian A. Seklecki wrote: On Tue, Oct 17, 2006 at 09:25:52PM -0400, Brian A. Seklecki wrote: Dinesh et al: Did this problem ever get resolved? I'm tracking down a very similar bug with an SBC - An Axiomtek SBC83672 Ver.C13.10.0. Dinish: What platform are you using? You said you had a 4x re(4) SBC, but never posted full dmesg(8). Mine is a Via C3/Samuel inside an OEM network appliance. URL below. My platform is netbsd-3, but I just tried -current to see if recent rtl8169.c changes fix it. No dice. No dice with NetBSD -current either. FreeBSD 6.1 panics at probe of re0 as you've posted. With NetBSD, re0 probes then fails the diagnostic function, then detatches. re1, re2, re3 all then sucsessfully probe on my system, but then they show no media status and tcpdump(8)/arp(8) show no activity. They're dead in the water. There has also been some mention of the errors below on NetBSD and OpenBSD probably because of the bitrot/driver drift: http://marc.theaimsgroup.com/?t=11165804011r=1w=2 http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=26025 I'm gonna grab a FreeBSD 7-current snapshot boot only ISO and give it a go. I see a 8139C+ fix was commited 5 weeks ago by [EMAIL PROTECTED] Based on some other threads I've been reading on 8139C+ Watchdog Timeouts and Diag failed, failing to attach related messages, I imagine FreeBSD has this covered. re0 at pci0 dev 16 function 0: RealTek 8139C+ 10/100BaseTX re0: interrupting at irq 5 re0: Ethernet address 00:60:e0:e1:3e:31 re0: using 64 tx descriptors ukphy0 at re0 phy 0: Generic IEEE 802.3u media interface ukphy0: OUI 0x00, model 0x, rev. 0 ^^ Oops, I've missed OID/model number showed on your message. Sorry. Since ukphy(4) showed bogus model number I have no idea what PHY hardware the NIC has. Would you show me pciconf -lv output? ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re: diagnostic failed, failed to receive packet in loopback mode re0: attach aborted due to hardware diag failure ukphy0 detached Long ago re_diag() code was disabled by default(rev 1.68). So I think you should never see the diagnostic failed message on FreeBSD. The other odd thing I see from your demsg output is ukphy(4) attachment. If you boot system with bootverbose mode ukphy(4) would have printed PHY OID and model number. Please let me know the OID/model number. I guess it should use rlphy(4). (If you should use NetBSD you may need to define MIIVERBOSE to active verbose message.) -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/16/06 20:37 Pyun YongHyeon said the following: If the media is set to 'none' you couldn't send anything from re(4) as recent changes checks whether the link is present(Receiver should work). ifconfig re0 media 10baset or 100baset always returns error, so there doesn't seem to be anyway of forcing the media type. Does old(working) version also show 'none' for media? Do you use manual media configuration instead of 'auto'? i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try with the patch you sent it to see if that works. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Thu, Aug 17, 2006 at 02:05:48PM +0800, Dinesh Nair wrote: On 08/16/06 20:37 Pyun YongHyeon said the following: If the media is set to 'none' you couldn't send anything from re(4) as recent changes checks whether the link is present(Receiver should work). ifconfig re0 media 10baset or 100baset always returns error, so there doesn't seem to be anyway of forcing the media type. Does old(working) version also show 'none' for media? Do you use manual media configuration instead of 'auto'? i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try I think disabling checksum offload wouldn't help either. re(4)/rlphy(4) should be taught to detect link status. with the patch you sent it to see if that works. -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
Dinesh Nair [EMAIL PROTECTED] writes: i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try with the patch you sent it to see if that works. If you can receive but not transmit (as I understood from other posts in the thread, though you never answered my question about tcpdump), disabling tx checksum offloading should be the *first* thing to try, especially as there is a known bug in some RealTek chipsets which will cause tx checksums to be computed incorrectly for short packets (such as ICMP echo replies, or TCP handshake frames). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 06:51:04PM +0800, Dinesh Nair wrote: On 08/14/06 17:22 Dinesh Nair said the following: i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4 onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE working on them, but the realtek NICs just don't seem to want to work. booting up led to a kernel trap with the following, based on a pointer from luigi rizzo, i disabled the check for the 8139C+ in /usr/src/sys/pci/if_rl.c to force the rl driver to bind to the card, and that seemed to do the trick in getting it to work. ifconfig still shows that the media is set to 'none' and a missing status line, but the box is pingable at the least. If the media is set to 'none' you couldn't send anything from re(4) as recent changes checks whether the link is present(Receiver should work). Does old(working) version also show 'none' for media? Do you use manual media configuration instead of 'auto'? -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 08:03:35PM +0800, Dinesh Nair wrote:
On 08/14/06 19:09 Pyun YongHyeon said the following:
really sucks and need much more CPU power to saturate the link.
So I don't think it's good idea to make rl(4) serve 8139C+.
perhaps, but re(4) doesn't work at the moment on this chipset, and i'd
rather have something which works, albeit a little poorly, than something
which doesn't.
Yes. What `ident /boot/kernel/if_re.ko` shows?
$FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.19 2006/08/07 02:38:07 yongari
Exp $
and the latest if_rlreg.c which i pulled down shows,
$FreeBSD: src/sys/pci/if_rlreg.h,v 1.51.2.7 2006/08/01 17:36:50 wpaul Exp $
i'm not using the loadable modules though, and am building the re(4) device
into the kernel directly.
the symptoms remain the same, i.e. IP traffic doesn't flow at all, though
'arp -an' does show the ethernet address of the other box attempting to
ping this.
the OP at
http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html
mentioned that it was working fine before breakage was introduced
relatively recently (~ 2 weeks ago), and thus something's changed in the
interim which is causing this to happen.
Here is guess work(I don't have 8139C+ based NICs).
Would you give it a try?
--
Regards,
Pyun YongHyeon
--- if_re.c.origThu Aug 3 09:15:19 2006
+++ if_re.c Thu Aug 17 11:25:31 2006
@@ -541,6 +541,10 @@
return (0);
}
rval = CSR_READ_2(sc, re8139_reg);
+ if (sc-rl_type == RL_8139CPLUS re8139_reg == RL_BMCR) {
+ /* 8139C+ uses different bit layout */
+ rval = ~(BMCR_LOOP | BMCR_ISO);
+ }
return (rval);
}
@@ -567,6 +571,10 @@
switch (reg) {
case MII_BMCR:
re8139_reg = RL_BMCR;
+ if (sc-rl_type == RL_8139CPLUS) {
+ /* 8139C+ uses different bit layout */
+ data = ~(BMCR_LOOP | BMCR_ISO);
+ }
break;
case MII_BMSR:
re8139_reg = RL_BMSR;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
working on them, but the realtek NICs just don't seem to want to work.
booting up led to a kernel trap with the following,
rlphy0: RealTek internal media interface on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re0: diagnostic failed, failed to receive packet in loopback mode
re0: attach aborted due to hardware diag failure
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0625d45
stack pointer = 0x28:0xc2420a50
frame pointer = 0x28:0xc2420a54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
looking through /usr/src/sys/dev/re/if_re.c, and reading this thread,
http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029373.html,
i've patched if_re.c to skip the re_diag() routine if the NIC is not a
Realtek 8169. the patch follows,
- CUT HERE -
--- if_re.c.origMon Aug 14 14:43:05 2006
+++ if_re.c Mon Aug 14 14:42:16 2006
@@ -1235,12 +1235,14 @@
ether_ifattach(ifp, eaddr);
/* Perform hardware diagnostic. */
- error = re_diag(sc);
+ if (sc-rl_type == RL_8169) {
+ error = re_diag(sc);
- if (error) {
- device_printf(dev, attach aborted due to hardware diag
failure\n);
- ether_ifdetach(ifp);
- goto fail;
+ if (error) {
+ device_printf(dev, attach aborted due to hardware diag
failure\n);
+ ether_ifdetach(ifp);
+ goto fail;
+ }
}
/* Hook interrupt last to avoid having to lock softc */
- CUT HERE -
with the patch applied, the kernel trap goes away and the box boots up.
however, though the link light comes on, the device is effectively
unuseable for ethernet traffic. nothing seems to go in or out of the device
with ping and other tcp/udp traffic failing. note the media state and the
missing status line from the ifconfig output.
any clue as to what's happenning here or to pointers/patches to fix this
would be much appreciated. i've got the box sitting beside me, so testing
patches et al would be highly possible.
dmesg, ifconfig and pciconf outputs are as follows:
re0: RealTek 8139C+ 10/100BaseTX port 0xe300-0xe3ff mem
0xed80-0xed8000ff irq 5 at device 16.0 on pci0
miibus0: MII bus on re0
rlphy0: RealTek internal media interface on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re1: RealTek 8139C+ 10/100BaseTX port 0xe400-0xe4ff mem
0xed801000-0xed8010ff irq 12 at device 17.0 on pci0
miibus1: MII bus on re1
rlphy1: RealTek internal media interface on miibus1
rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: Ethernet address: 00:60:e0:e1:21:d6
re2: RealTek 8139C+ 10/100BaseTX port 0xe500-0xe5ff mem
0xed802000-0xed8020ff irq 10 at device 18.0 on pci0
miibus2: MII bus on re2
rlphy2: RealTek internal media interface on miibus2
rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: Ethernet address: 00:60:e0:e1:21:d5
re3: RealTek 8139C+ 10/100BaseTX port 0xe600-0xe6ff mem
0xed803000-0xed8030ff irq 11 at device 19.0 on pci0
miibus3: MII bus on re3
rlphy3: RealTek internal media interface on miibus3
rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: Ethernet address: 00:60:e0:e1:21:d4
# ifconfig -a
re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=18VLAN_MTU,VLAN_HWTAGGING
inet 192.168.1.141 netmask 0xff00 broadcast 192.168.1.255
ether 00:60:e0:e1:21:d7
media: Ethernet autoselect (none)
re1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=18VLAN_MTU,VLAN_HWTAGGING
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
ether 00:60:e0:e1:21:d6
media: Ethernet autoselect (none)
re2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=18VLAN_MTU,VLAN_HWTAGGING
ether 00:60:e0:e1:21:d5
media: Ethernet autoselect (none)
re3: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500
options=18VLAN_MTU,VLAN_HWTAGGING
ether 00:60:e0:e1:21:d4
media: Ethernet autoselect (none)
# pciconf -l -v
[EMAIL PROTECTED]:16:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
[EMAIL PROTECTED]:17:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 05:22:23PM +0800, Dinesh Nair wrote:
i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4
onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE
working on them, but the realtek NICs just don't seem to want to work.
booting up led to a kernel trap with the following,
rlphy0: RealTek internal media interface on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re0: diagnostic failed, failed to receive packet in loopback mode
re0: attach aborted due to hardware diag failure
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0625d45
stack pointer = 0x28:0xc2420a50
frame pointer = 0x28:0xc2420a54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
Uptime: 1s
looking through /usr/src/sys/dev/re/if_re.c, and reading this thread,
http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029373.html,
i've patched if_re.c to skip the re_diag() routine if the NIC is not a
Realtek 8169. the patch follows,
- CUT HERE -
--- if_re.c.orig Mon Aug 14 14:43:05 2006
+++ if_re.c Mon Aug 14 14:42:16 2006
@@ -1235,12 +1235,14 @@
ether_ifattach(ifp, eaddr);
/* Perform hardware diagnostic. */
-error = re_diag(sc);
+if (sc-rl_type == RL_8169) {
+error = re_diag(sc);
-if (error) {
-device_printf(dev, attach aborted due to hardware diag
failure\n);
-ether_ifdetach(ifp);
-goto fail;
+if (error) {
+device_printf(dev, attach aborted due to hardware
diag failure\n);
+ether_ifdetach(ifp);
+goto fail;
+}
}
/* Hook interrupt last to avoid having to lock softc */
- CUT HERE -
with the patch applied, the kernel trap goes away and the box boots up.
however, though the link light comes on, the device is effectively
unuseable for ethernet traffic. nothing seems to go in or out of the device
with ping and other tcp/udp traffic failing. note the media state and the
missing status line from the ifconfig output.
any clue as to what's happenning here or to pointers/patches to fix this
would be much appreciated. i've got the box sitting beside me, so testing
patches et al would be highly possible.
Recent changes from wpaul disabled re_diag() routine by default so it
wouldn't trigger the panic you've seen anymore.
However I've seen one user reported re(4) breakage on stable.
http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html
Please try latest stable and show your results. If it still does not
work please let us know. I don't have 8139C+ based NICs so it would be
difficult for me to fix the issue. :-(
--
Regards,
Pyun YongHyeon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 17:22 Dinesh Nair said the following: i've got a single board computer with VIA C3 Samuel 2, 256MB RAM and 4 onboard Realtek 8139C+ NICs. I'm attempting to get FreeBSD 6.1-STABLE working on them, but the realtek NICs just don't seem to want to work. booting up led to a kernel trap with the following, based on a pointer from luigi rizzo, i disabled the check for the 8139C+ in /usr/src/sys/pci/if_rl.c to force the rl driver to bind to the card, and that seemed to do the trick in getting it to work. ifconfig still shows that the media is set to 'none' and a missing status line, but the box is pingable at the least. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 18:39 Pyun YongHyeon said the following: Recent changes from wpaul disabled re_diag() routine by default so it i disabled re_diag() in /usr/src/sys/dev/if_re.c, and that caused the kernel trap to go away, as per my original email. also, see my followup email (to myself) in which i disabled the check for the 8139C+, forcing it to be recognized by the rl driver and this seems to make it work. However I've seen one user reported re(4) breakage on stable. http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html that seems to be exactly the problem i initially observed as well. Please try latest stable and show your results. If it still does not work please let us know. I don't have 8139C+ based NICs so it would be i am on a recent stable, circa two weeks ago as well. have there been significant changes to the re driver since ? -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 06:55:58PM +0800, Dinesh Nair wrote: On 08/14/06 18:39 Pyun YongHyeon said the following: Recent changes from wpaul disabled re_diag() routine by default so it i disabled re_diag() in /usr/src/sys/dev/if_re.c, and that caused the kernel trap to go away, as per my original email. also, see my followup email (to myself) in which i disabled the check for the 8139C+, forcing it to be recognized by the rl driver and this seems to make it work. AFAIK 8139C+ provides 8139 compatible mode which doesn't use descriptor based transfer mechanism. As you know this mode really sucks and need much more CPU power to saturate the link. So I don't think it's good idea to make rl(4) serve 8139C+. However I've seen one user reported re(4) breakage on stable. http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html that seems to be exactly the problem i initially observed as well. Please try latest stable and show your results. If it still does not work please let us know. I don't have 8139C+ based NICs so it would be i am on a recent stable, circa two weeks ago as well. have there been significant changes to the re driver since ? Yes. What `ident /boot/kernel/if_re.ko` shows? -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/14/06 19:09 Pyun YongHyeon said the following: really sucks and need much more CPU power to saturate the link. So I don't think it's good idea to make rl(4) serve 8139C+. perhaps, but re(4) doesn't work at the moment on this chipset, and i'd rather have something which works, albeit a little poorly, than something which doesn't. Yes. What `ident /boot/kernel/if_re.ko` shows? $FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.19 2006/08/07 02:38:07 yongari Exp $ and the latest if_rlreg.c which i pulled down shows, $FreeBSD: src/sys/pci/if_rlreg.h,v 1.51.2.7 2006/08/01 17:36:50 wpaul Exp $ i'm not using the loadable modules though, and am building the re(4) device into the kernel directly. the symptoms remain the same, i.e. IP traffic doesn't flow at all, though 'arp -an' does show the ethernet address of the other box attempting to ping this. the OP at http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html mentioned that it was working fine before breakage was introduced relatively recently (~ 2 weeks ago), and thus something's changed in the interim which is causing this to happen. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
Dinesh Nair [EMAIL PROTECTED] writes:
the symptoms remain the same, i.e. IP traffic doesn't flow at all,
though 'arp -an' does show the ethernet address of the other box
attempting to ping this.
'tcpdump -n -e -i re0' shows nothing?
have you tried disabling rx / tx checksum offloading? ('ifconfig re0
-rxcsum -txcsum')
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Mon, Aug 14, 2006 at 08:03:35PM +0800, Dinesh Nair wrote: On 08/14/06 19:09 Pyun YongHyeon said the following: really sucks and need much more CPU power to saturate the link. So I don't think it's good idea to make rl(4) serve 8139C+. perhaps, but re(4) doesn't work at the moment on this chipset, and i'd rather have something which works, albeit a little poorly, than something which doesn't. Ok. Yes. What `ident /boot/kernel/if_re.ko` shows? $FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.19 2006/08/07 02:38:07 yongari Exp $ and the latest if_rlreg.c which i pulled down shows, $FreeBSD: src/sys/pci/if_rlreg.h,v 1.51.2.7 2006/08/01 17:36:50 wpaul Exp $ i'm not using the loadable modules though, and am building the re(4) device into the kernel directly. the symptoms remain the same, i.e. IP traffic doesn't flow at all, though 'arp -an' does show the ethernet address of the other box attempting to ping this. Ok, this is important thing. It means Rx part works as expected. Can you see tcpdump output on Tx side while ping command is in progress? the OP at http://lists.freebsd.org/pipermail/freebsd-stable/2006-August/027356.html mentioned that it was working fine before breakage was introduced relatively recently (~ 2 weeks ago), and thus something's changed in the interim which is causing this to happen. -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. Just realized that with ACPI disabled, this card does not work with FreeBSD 5.4 (at least in my machine), with ACPI enabled - it does. Hope this information will help somebody. With or without ACPI support, it doesn't chang anything here. Under RELENG_6 now, i always get the problem with these (lot of) kernel messages at boot time: - re0: 2 link states coalesced - re0: link state changed to DOWN - re0: link state changed to UP Note 1: It is a little better though, since the DHCP client can wait in foreground the link to come up then only continue the boot, making network related stuff relatively happy (ntpdate, ntpd, etc.). Note 2: Just try to disable APIC but leave ACPI enable (as this helped me in an other situation and for an other problem, see PR usb/74989)... this leads me to a LOR follow by a panic (try this 3 times) at boot time. So, it seems a very bad idea here :\ Thanks, -- -jpeg. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. Just realized that with ACPI disabled, this card does not work with FreeBSD 5.4 (at least in my machine), with ACPI enabled - it does. Hope this information will help somebody. I just replied to this on an other post. I have RTL8169S in my laptop, and have seen the same up/down/up/down etc. behavior that is noted in PR 80005. I am running 7-CURRENT about a day old. I switched from my custom kernel back to GENERIC and the problem went away, so I started adding things from my custom config file into GENERIC to see what finally broke it, and it turned out to be: options ACPI_DEBUG Just thought that I would mention it... Certainly, thanks... very interesting! Although it doesn't seems to be the problem, since i didn't set this kernel option. On the other hand, i am currently testing RELENG_6, not -CURRENT: maybe is this problem finally fixed on HEAD (i will give it a try in a near future, if i can). Thank you, -- -jpeg. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
On 2005-08-20T09:50:53+0400, Dmitry Mityugov wrote: On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. Just realized that with ACPI disabled, this card does not work with FreeBSD 5.4 (at least in my machine), with ACPI enabled - it does. Hope this information will help somebody. I have RTL8169S in my laptop, and have seen the same up/down/up/down etc. behavior that is noted in PR 80005. I am running 7-CURRENT about a day old. I switched from my custom kernel back to GENERIC and the problem went away, so I started adding things from my custom config file into GENERIC to see what finally broke it, and it turned out to be: options ACPI_DEBUG Just thought that I would mention it... re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0x1000 re0: RealTek 8169S Single-chip Gigabit Ethernet port 0x1000-0x10ff mem 0xd0008800-0xd00088ff irq 19 at device 8.0 on pci0 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S media interface on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 00:90:f5:32:35:9f re0: [GIANT-LOCKED] -- Mike Oliver [see complete headers for contact information] pgpYlryu57Wjo.pgp Description: PGP signature
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. Just realized that with ACPI disabled, this card does not work with FreeBSD 5.4 (at least in my machine), with ACPI enabled - it does. Hope this information will help somebody. -- Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements We live less by imagination than despite it - Rockwell Kent, N by E ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8100S on FreeBSD 5.4: no carrier.
I did some more research, it appears that the Abit AA8-DuraMax actually uses the RealTek RTL8100S chipset, not the 8169. The hardware compatibility list for 5.4 shows support for the 8110S chipset, but not my specific motherboard. Perhaps it is a new chip revision? I tried the patch by Dag-Erling Smørgrav from a similar thread ( http://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/011022.html ) but no luck. -j Julien Gabel wrote: Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
I recently installed FreeBSD 5.4 on an ABIT AA-8 DuraMax and all went
well. All hardware detected properly and everything was running great,
until I got to configuring my network. ifconfig shows my onboard
gigabit LAN as status: no carrier
I can successfully ping localhost and the IP that was assigned to re0
(192.168.1.31).
when I plug an ethernet cable from my FreeBSD box to my router, I get
status: no carrier. Oddly, when I plug an ethernet cable from my
FreeBSD box to my laptop's LAN port, I get status: active. The lights
on the ethernet jack indicate the same.
Additionally, if I manually set the media with the following command:
# ifconfig re0 media 10baseT/UTP mediaopt full-duplex
The status magically switches to active and I can use my ethernet!
I know that there are known problems with RealTek chipsets, but it is
listed in the 5.4 supported hardware list.
Bottom line is that the onboard LAN is detected, installed, and working
properly, but it seems as if the driver can't properly detect when a
cable is plugged into the jack.
I was hoping someone could help.
uname -a:
--
FreeBSD db.domain.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8
10:21:06 UTC 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
ifconfig:
--
re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=18VLAN_MTU,VLAN_HWTAAGGING
inet 192.168.1.31 netmast 0xff00 broadcast 192.168.1.255
inet6 ...
ether 00:50:8d:eb:e5:be
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
Relevant dmesg:
--
re0: RealTek 8169S Single-chip Gigabit Ethernet port 0xee00-0xeeff mem
0xfbfff000-0xfbfff0ff irc 16 at device 1.0 on pci1
miibus0: MII bus on re0
rgephy0: RTL8169S/8110S media interface on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
1000baseTX-FDX, auto
re0: Ethernet address: 00:50:8d:eb:e5:be
pciconf -lv:
--
[EMAIL PROTECTED]:1:0: class=0x02 card=0x1039147b chip=0x816910ec rev=0x10
hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RTL8169 Gigabit Ethernet Adapter
class = network
subclass = ethernet
pciconf -r pci1:1:0 0:0xff
--
816910ec 02b7 0210 2008
ee01 fbfff000
1039147b
00dc 40200110
f7c20001
Regrettably, i always encountered this problem. I spoke about that since
the middle of 2004, and didn't really receive feedback on this. I try a
lot of things but none worked better than the other.
To not forget about it, i filled a bug report on this particular problem,
see PR kern/80005 for more details.
The last thing i want to give another try is to upgrade to RELENG_6,
since i currently follow the RELENG_5 branch. But i am not *very*
confident about that...
Sorry not to have better answer to give you.
--
-jpeg.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: ... Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. -- Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements We live less by imagination than despite it - Rockwell Kent, N by E ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. Yes, i know it simply works for a lot of users. It doesn't mean that it is the case for all users... i am of those. -- -jpeg. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8169 on FreeBSD 5.4: no carrier.
I did some more research, it appears that the Abit AA8-DuraMax actually uses the RealTek RTL8100S chipset, not the 8169. The hardware compatibility list for 5.4 shows support for the 8110S chipset, but not my specific motherboard. Perhaps it is a new chip revision? I tried the patch by Dag-Erling Smørgrav from a similar thread ( http://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/011022.html ) but no luck. -j Dmitry Mityugov wrote: On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: ... Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8100S on FreeBSD 5.4: no carrier.
I just tried a clean install of 6.0 Beta 2, and still the same problem, but now with additional error messages: re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN Over and over and over, whenever the LED on the network jack blinks. Further research indicated that ACPI could be a problem, so I disabled it by adding hint.acpi.0.disabled=1 to /boot/device.hints. This produced a different error: re0: 2 link states coalesced re0: link state changed to DOWN re0: 2 link states coalesced re0: link state changed to DOWN Over and over on every LED blink. -j j snod wrote: I did some more research, it appears that the Abit AA8-DuraMax actually uses the RealTek RTL8100S chipset, not the 8169. The hardware compatibility list for 5.4 shows support for the 8110S chipset, but not my specific motherboard. Perhaps it is a new chip revision? I tried the patch by Dag-Erling Smørgrav from a similar thread ( http://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/011022.html ) but no luck. -j Dmitry Mityugov wrote: On 8/10/05, Julien Gabel [EMAIL PROTECTED] wrote: ... Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. IIRC, I have a RTL8169S-based D-Link gigabit network card at home and it works with FreeBSD just fine. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek RTL8100S on FreeBSD 5.4: no carrier.
Regrettably, i always encountered this problem. I spoke about that since the middle of 2004, and didn't really receive feedback on this. I try a lot of things but none worked better than the other. To not forget about it, i filled a bug report on this particular problem, see PR kern/80005 for more details. The last thing i want to give another try is to upgrade to RELENG_6, since i currently follow the RELENG_5 branch. But i am not *very* confident about that... Sorry not to have better answer to give you. I did some more research, it appears that the Abit AA8-DuraMax actually uses the RealTek RTL8100S chipset, not the 8169. The hardware compatibility list for 5.4 shows support for the 8110S chipset, but not my specific motherboard. Perhaps it is a new chip revision? I tried the patch by Dag-Erling Smørgrav from a similar thread ( http://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/011022.html ) but no luck. I just tried a clean install of 6.0 Beta 2, and still the same problem, but now with additional error messages: re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN Over and over and over, whenever the LED on the network jack blinks. Further research indicated that ACPI could be a problem, so I disabled it by adding hint.acpi.0.disabled=1 to /boot/device.hints. This produced a different error: re0: 2 link states coalesced re0: link state changed to DOWN re0: 2 link states coalesced re0: link state changed to DOWN Over and over on every LED blink. Same behaviour here: RELENG_5 or RELENG_6, with or without ACPI support. -- -jpeg. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Realtek RTL8169 on FreeBSD 5.4: no carrier
I recently installed FreeBSD 5.4 on an ABIT AA-8 DuraMax and all went well. All hardware detected properly and everything was running great, until I got to configuring my network. ifconfig shows my onboard gigabit LAN as status: no carrier I can successfully ping localhost and the IP that was assigned to re0 (192.168.1.31). when I plug an ethernet cable from my FreeBSD box to my router, I get status: no carrier. Oddly, when I plug an ethernet cable from my FreeBSD box to my laptop's LAN port, I get status: active. The lights on the ethernet jack indicate the same. Additionally, if I manually set the media with the following command: # ifconfig re0 media 10baseT/UTP mediaopt full-duplex The status magically switches to active and I can use my ethernet! I know that there are known problems with RealTek chipsets, but it is listed in the 5.4 supported hardware list. Bottom line is that the onboard LAN is detected, installed, and working properly, but it seems as if the driver can't properly detect when a cable is plugged into the jack. I was hoping someone could help. uname -a: -- FreeBSD db.domain.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 ifconfig: -- re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=18VLAN_MTU,VLAN_HWTAAGGING inet 192.168.1.31 netmast 0xff00 broadcast 192.168.1.255 inet6 ... ether 00:50:8d:eb:e5:be media: Ethernet autoselect (none) status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 Relevant dmesg: -- re0: RealTek 8169S Single-chip Gigabit Ethernet port 0xee00-0xeeff mem 0xfbfff000-0xfbfff0ff irc 16 at device 1.0 on pci1 miibus0: MII bus on re0 rgephy0: RTL8169S/8110S media interface on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:50:8d:eb:e5:be pciconf -lv: -- [EMAIL PROTECTED]:1:0: class=0x02 card=0x1039147b chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter class = network subclass = ethernet pciconf -r pci1:1:0 0:0xff -- 816910ec 02b7 0210 2008 ee01 fbfff000 1039147b 00dc 40200110 f7c20001 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 Release and Realtek
On Sun, 2004-12-19 at 00:42, [EMAIL PROTECTED] wrote: I'm running 5.3-Release amd64 on an Asus AV8 motherboard which includes Realtek ALC850 audio chipset. I'm unable to get the system to recognize the chipset. From the archives/man pages/manual I've : # kldload snd_driver kldload: can't load snd_driver: No such file or directory Modified /boot/loader.conf to use : sound_load=YES snd_driver_load=YES Have you tried 'kldload snd_via8233'. Worked for me. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.3 Release and Realtek
I'm running 5.3-Release amd64 on an Asus AV8 motherboard which includes
Realtek ALC850 audio chipset. I'm unable to get the system to recognize
the chipset. From the archives/man pages/manual I've :
# kldload snd_driver
kldload: can't load snd_driver: No such file or directory
Modified /boot/loader.conf to use :
sound_load=YES
snd_driver_load=YES
Recompiled the kernel with :
device sound
The last one resulted in /dev/sndstat showing up, but the contents show
no devices :
# cat /dev/sndstat
FreeBSD Audio Driver (newpcm)
Installed devices:
However I don't see any snd_* modules in /boot/kernel/*ko
I also noted that sys/dev/sound/pcm/ac97.c contains the following :
static const struct ac97_vendorid ac97vendorid[] = {
{ 0x414c4300, Realtek },
static struct ac97_codecid ac97codecid[] = {
{ 0x414c4790, 0x0f, 0, ALC850,0 },
At this point I'm at a loss as to where to go from here, or which kernel
module would support this chipset.
Other than that this system is a screamer. This is my first experience
with 5.3, AMD, and with the 64 bit port, so far I'm really impressed. I
saw reports that the Marvell Gig Ethernet wasn't working for some folks,
but it worked fine for me. I chose this motherboard as it was the only one
of about three that supported socket 939 and had the Via K8T800 chipset, I
was concerned about the reports of problems with the nVidia nForce
chipset. I would have liked to have had PCI-X, but that's only available
today with nVidia. The Promise SATA raid controller (one of two different
brand controllers onboard) worked just fine.
http://www.asus.com/products/mb/socket939/a8v-d/overview.htm
Chris
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 Release and Realtek
On Sun, 19 Dec 2004 05:42, [EMAIL PROTECTED] wrote: I'm running 5.3-Release amd64 on an Asus AV8 motherboard which includes Realtek ALC850 audio chipset. I'm unable to get the system to recognize the chipset. From the archives/man pages/manual I've : This is the AC97 chipset, the thing that you load the driver for is different. # kldload snd_driver kldload: can't load snd_driver: No such file or directory Try kldload snd_ich, failing that email the output of pciconf -lv Although snd_driver should work.. What does dmesg say after you've tried to load it? The last one resulted in /dev/sndstat showing up, but the contents show no devices : # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: However I don't see any snd_* modules in /boot/kernel/*ko Hmm, well that IS odd :) [inchoate 10:30] ~ ll /boot/kernel/snd*.ko | wc -l 25 Have you rebuilt your kernel? It may be that it failed part way through so you didn't get the sound driver modules built or installed. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpuY67ao8b9Z.pgp Description: PGP signature
Re: 5.3 Release and Realtek
On Sun, 19 Dec 2004 05:42, [EMAIL PROTECTED] wrote: I'm running 5.3-Release amd64 on an Asus AV8 motherboard which includes Realtek ALC850 audio chipset. I'm unable to get the system to recognize the chipset. From the archives/man pages/manual I've : This is the AC97 chipset, the thing that you load the driver for is different. I know, I found out later it's the VIA VT8237 chipset. The information from Asus makes the codec appear as the chipset. # kldload snd_driver kldload: can't load snd_driver: No such file or directory Try kldload snd_ich, failing that email the output of pciconf -lv Although snd_driver should work.. What does dmesg say after you've tried to load it? The problem was that none of the snd_* modules were built, and I did rebuild the kernel. Once I built the modules, I was able to load the drivers. I think you need to add device sound to get these modules to build automgically. So the snd_via8233 is the driver that works, and it's fine if you want basic functionality (stereo sound, record, etc.) This motherboard (Asus AV8) has 8 channel audio though. I stumbled across this site : http://www.opensound.com/freebsd.html I installed the demo FreeBSD driver (expires every three months) and it supports the card fully. It's only $30 to buy it, so if I end up doing multimedia stuff with this system then it's well worth the cost. It's so nice not having to resort to Linux everytime you want to do something cool This should resolve a bunch of unanswered posts I saw in the list archives. Thanks for the help. Here's the output of `cat /dev/sndstat` and mixer. # cat /dev/sndstat OSS/FreeBSD 3.99.1i (C) 4Front Technologies 1996-2004 License serial number: E0008 UNREGISTERED VERSION You can order the OSS license using the 'Order permanent OSS license' function of soundconf command. Alternatively use our ordering page at http://www.opensound.com/order.html. Drivers: ALL License will expire after: 02/2005 *** Unregistered version *** Build: 200411171937 Kernel: FreeBSD 5.3-RELEASE #2: Sun Dec 19 17:44:30 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM Card config: VIA 8233 AC97 audio controller at 0xd800 irq 22 Audio devices: 0: VT8233 (DUPLEX,GRC3) 1: VT8233 (shadow) (DUPLEX,GRC3) 2: OSS Virtual Mixer v2.5 Playback CH #0 (GRC3) 3: OSS Virtual Mixer v2.5 Playback CH #1 (GRC3) 4: OSS Virtual Mixer v2.5 Playback CH #2 (GRC3) 5: OSS Virtual Mixer v2.5 Playback CH #3 (GRC3) 6: OSS Virtual Mixer v2.5 Playback CH #4 (GRC3) 7: OSS Virtual Mixer v2.5 Playback CH #5 (GRC3) 8: OSS Virtual Mixer v2.5 Playback CH #6 (GRC3) 9: OSS Virtual Mixer v2.5 Playback CH #7 (GRC3) Synth devices: 0: OSS Virtual Synth v2.5 Midi devices: Mixers: 0: VT8233 (ALC850) 1: Virtual Mixer History: dsp5: OUT dsp6: OUT dsp7: OUT dsp8: OUT dsp9: OUT # mixer Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 0:0 Mixer line is currently set to 32:32 Mixer mic is currently set to 0:0 Mixer cd is currently set to 75:75 Mixer igainis currently set to 75:75 Mixer line1is currently set to 32:32 Mixer phin is currently set to 0:0 Mixer phoutis currently set to 0:0 Mixer videois currently set to 0:0 Recording source: line Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 Release and Realtek
On Mon, 20 Dec 2004 12:44, [EMAIL PROTECTED] wrote: The problem was that none of the snd_* modules were built, and I did rebuild the kernel. Once I built the modules, I was able to load the drivers. I think you need to add device sound to get these modules to build automgically. No, the modules are built regardless of the kernel options you use. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpNG2DW3P1yc.pgp Description: PGP signature
Re: 5.3 Release and Realtek
On Mon, 20 Dec 2004, Daniel O'Connor wrote: On Mon, 20 Dec 2004 12:44, [EMAIL PROTECTED] wrote: The problem was that none of the snd_* modules were built, and I did rebuild the kernel. Once I built the modules, I was able to load the drivers. I think you need to add device sound to get these modules to build automgically. No, the modules are built regardless of the kernel options you use. In this case they weren't, not sure why. I looked in /boot/kernel for snd* and there was nothing there. I did a `locate snd_*` and found them in /usr/src/sys/modules/sound. When I did a make install, they were all properly installed. It seems they just don't get built unless device sound is specified in the kernel conf. Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3 Release and Realtek
I think I found the answer, more testing will be required, but for now I see the sound card. The answer : # cd /usr/src/sys/modules/sound # make install # kldload snd_driver # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm1: VIA VT8237 at io 0xd800 irq 22 kld snd_via8233 (5p/1r/0v channels duplex) Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Looking for RealTek 8169-based NIC for testing
I've decided to pick up one of the projects I let lapse some time ago, which was to add support for the RealTek 8139C+ chipset to the rl(4) driver. The 8139C+ is, by default, backwards compatible with the 8139A/B/C/D/etc... but also supports a descriptor-based DMA mechanism, TCP/IP checksum offload, VLAN tagging and extraction, and TCP large send. RealTek also has an 8169 gigabit ethernet chipset with almost the same programming mechanism as the 8139C+, so I decided to support that too. However, while I have a sample 8139C+ NIC for testing, I don't have an 8169 gigE card. I can probably pick one up, but I don't know who sells cards with this chip on it. If anyone can positively identify a card that has uses this chip, i.e. from D-Link, Netgear, or whoever, I'd appreciate it if you could point it me at it. If it's something that can quickly be acquired from CompUSA, even better. Note: RealTek also has an 8110 LOM (Lan On Motherboard) chip, which I _think_ is register compatible with the 8169, however I don't want to buy a whole new motherboard. Ultimately, I may need to find someone who does have one of these so they can verify that the driver does in fact work with it though, so if you've got one, save this e-mail and watch for a call for testers. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
An address that works. Without further knowledge of your laptop, it is impossible for me to say. You will have to find this out by trial and error. Some folks like 0xf800, others like 0x4 and one uses 0xd4000, but the last one I don't recommend. 0xf800 seems to work on my StinkPad (still can't get the serial port to work though). You have to enable it using the PS2 'DOS' command (the Windows one won't work, for whatever reason). Once it's probably enabled/configured, it acts like any other normal serial port. (It's a pain to get it working right, since it involves dozens of reboots in order to understand what exactly the configuration *should* be. From memory, it wasn't as obvious as it could have been.) Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : In message: [EMAIL PROTECTED] : [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : : address wrong to not finding it at all (I believe it reports No : : station address in CIS!) and refusing to attach. : It always didn't find it, you just got lucky before. The no station : address in CIS means that it can't map the CIS. This means the 'it' : isn't dc, but rather 'cbb'. cbb's ability to map memory is kinda : flakey on some machines. You have one. You need to set : hw.cbb.start_memory to a value that makes your laptop happy. : : ...such as? An address that works. Without further knowledge of your laptop, it is impossible for me to say. You will have to find this out by trial and error. Some folks like 0xf800, others like 0x4 and one uses 0xd4000, but the last one I don't recommend. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
M. Warner Losh [EMAIL PROTECTED] writes: An address that works. Without further knowledge of your laptop, it is impossible for me to say. You will have to find this out by trial and error. Some folks like 0xf800, others like 0x4 and one uses 0xd4000, but the last one I don't recommend. 0xf800 seems to work on my StinkPad (still can't get the serial port to work though). It still complains about an invalid BAR number: 27(06). Plenty of ACPI errors too, but I don't really expect much from an IBM laptop. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : M. Warner Losh [EMAIL PROTECTED] writes: : An address that works. Without further knowledge of your laptop, it : is impossible for me to say. You will have to find this out by trial : and error. Some folks like 0xf800, others like 0x4 and : one uses 0xd4000, but the last one I don't recommend. : : 0xf800 seems to work on my StinkPad (still can't get the serial : port to work though). It still complains about an invalid BAR : number: 27(06). Plenty of ACPI errors too, but I don't really expect : much from an IBM laptop. Cool. I'm sorry you have to do these ugly hacks, and hope to get things working better soon. Maybe I should add a stinkpad to my wish list :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
M. Warner Losh [EMAIL PROTECTED] writes: Maybe I should add a stinkpad to my wish list :-) I'll trade you mine for a reasonably recent Dell or FujitsuSiemens laptop :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
On Mon, 31 Mar 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: 0xf800 seems to work on my StinkPad (still can't get the serial port to work though). It still complains about an invalid BAR number: 27(06). Plenty of ACPI errors too, but I don't really expect much from an IBM laptop. Thankfully, APM works great on the older Thinkpads. To enable the serial port you'll want to run the DOS 'ps2.exe' utility. You can use the 'smapi' kernel driver and the userland utility ftp://ftp.jurai.net/users/winter/smapi.tar.gz to see if its disabled (likely). I still haven't puzzled out how to enable the serial ports with my utility. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
Matthew N. Dodd [EMAIL PROTECTED] writes: Thankfully, APM works great on the older Thinkpads. for some definition of great which includes the APM BIOS suddenly deciding to suspend the laptop after 30 seconds even when the mains cord is plugged in. To enable the serial port you'll want to run the DOS 'ps2.exe' utility. I know. I did that. I get: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 drq 3 on acpi0 sio0: type 8250 or not responding DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
On Mon, 31 Mar 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: for some definition of great which includes the APM BIOS suddenly deciding to suspend the laptop after 30 seconds even when the mains cord is plugged in. You've got a 600 series right? What model and bios revision? (Find out with the 'vpd' driver or go into the BIOS setup.) I know. I did that. I get: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 drq 3 on acpi0 sio0: type 8250 or not responding It won't work at all with ACPI; don't use it. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
Matthew N. Dodd [EMAIL PROTECTED] writes: What model and bios revision? (Find out with the 'vpd' driver or go into the BIOS setup.) Yep, a 600E (2645BG). I don't know exactly what BIOS version I have, but I kept it fairly up to date until a fellow committer who shall remain nameless ran off with the floppy about a year and a half ago. If there's any way to flash the BIOS from Windows, I can try that. Regarding vpd, some documentation (at least in NOTES) would be nice. I shouldn't have to RTFS to understand what you're talking about. It won't work at all with ACPI; don't use it. don't use ACPI or don't use sio? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
On Tue, 1 Apr 2003, Dag-Erling [iso-8859-1] Smørgrav wrote: Regarding vpd, some documentation (at least in NOTES) would be nice. I shouldn't have to RTFS to understand what you're talking about. Build /sys/modules/bios/vpd, install/load it, read the kernel output. It also provides all the information via sysctl: # sysctl hw.vpd hw.vpd.machine.type.0: 2645 hw.vpd.machine.model.0: 8BU hw.vpd.build_id.0: INET36WW hw.vpd.serial.box.0: 78PLGM9 hw.vpd.serial.planar.0: J1B369624W5 It won't work at all with ACPI; don't use it. don't use ACPI or don't use sio? Don't use ACPI. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
M. Warner Losh [EMAIL PROTECTED] writes: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : address wrong to not finding it at all (I believe it reports No : station address in CIS!) and refusing to attach. It always didn't find it, you just got lucky before. The no station address in CIS means that it can't map the CIS. This means the 'it' isn't dc, but rather 'cbb'. cbb's ability to map memory is kinda flakey on some machines. You have one. You need to set hw.cbb.start_memory to a value that makes your laptop happy. ...such as? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
On Wednesday 26 March 2003 16:03, David Gilbert wrote: Given the price of this card ... and the fact that less-than-400Mhz CPU's are rather rare, and that this is only an issue for high bandwidth applications ... the rl cards might fit for you. Given the price of the card, you can almost always find a better one at roughly the same price. For instance, this one: dc0: Intel 21143 10/100BaseTX port 0xd800-0xd87f mem 0xf300-0xf30003ff irq 7 at device 11.0 on pci0 was FREE last Christmas, from Office Depot. It's a Belkin branded card and normally sells for $10 (at TigerDirect.com). -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
David Gilbert [EMAIL PROTECTED] writes: But ... I'm not sure that their performance is largely better than the rl's. The driver writer for the rl maligns the card in comments for requiring alignment (and thus copying). There are far worse hacks in the dc code ... with the comment that some dc implementations are worse than others. Not to mention the fact that over the past year or so people have been repeatedly picking the dc driver apart and putting it back together with some bits missing, so for some cards it has gone from working perfectly, to getting the MAC address wrong but working fine after you manually set it, to plainly refusing to attach to the card. My laptop is now practically reduced to a doorstop since -STABLE doesn't have Cardbus support and -CURRENT refuses to attach to the NIC. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : Not to mention the fact that over the past year or so people have been : repeatedly picking the dc driver apart and putting it back together : with some bits missing, so for some cards it has gone from working : perfectly, to getting the MAC address wrong but working fine after you : manually set it, to plainly refusing to attach to the card. My laptop : is now practically reduced to a doorstop since -STABLE doesn't have : Cardbus support and -CURRENT refuses to attach to the NIC. As far as I know, all the sizing and weirdness issues have been worked out with dc. Care to provide details on the card that isn't? Alternatively, wanna swap me one of my working cards for it? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
M. Warner Losh [EMAIL PROTECTED] writes: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : Not to mention the fact that over the past year or so people have been : repeatedly picking the dc driver apart and putting it back together : with some bits missing, so for some cards it has gone from working : perfectly, to getting the MAC address wrong but working fine after you : manually set it, to plainly refusing to attach to the card. My laptop : is now practically reduced to a doorstop since -STABLE doesn't have : Cardbus support and -CURRENT refuses to attach to the NIC. As far as I know, all the sizing and weirdness issues have been worked out with dc. Care to provide details on the card that isn't? It's an IBM branded Xircom card which used to work perfectly (except for some trouble with underruns which another nearly identical card didn't have... but I lost the dongle for that one). FRU 34L5309 if you want to look up the datasheet. About a year ago, subsequent to changes in the dc driver, -CURRENT started getting the MAC address wrong (but it would still attach, so I could set the correct MAC address manually). At some later point, some time between October 2002 and February 2003 (during which time I didn't run -CURRENT on the laptop due to insufficient disk space), it went from getting the MAC address wrong to not finding it at all (I believe it reports No station address in CIS!) and refusing to attach. I have a couple of 16-bit cards lying around, but oldcard couldn't even find the slots, let alone the cards I put in. I haven't tried 4.8 as it would be useless for me (I need the laptop for development work on -CURRENT). The only alternative left is SLIP, which would prevent me from using the laptop as a serial console since it only has one port - but it turns out 5.0-RELEASE is unable to use the serial port. That may be a BIOS problem though, the BIOS seems to regularly reset random configuration options (such as the IRDA, what IRDA? I don't need no stinking IRDA option) to factory defaults. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: : address wrong to not finding it at all (I believe it reports No : station address in CIS!) and refusing to attach. It always didn't find it, you just got lucky before. The no station address in CIS means that it can't map the CIS. This means the 'it' isn't dc, but rather 'cbb'. cbb's ability to map memory is kinda flakey on some machines. You have one. You need to set hw.cbb.start_memory to a value that makes your laptop happy. Yes, this sucks, but it is a symptom of the deeper problems with the dynamic allocation of resources in freebsd pci code. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [hackers] Re: Realtek
Hi Kirill! That's a real myth about Realtek :0) We're using them on all our FreeBSD machines for over 5 years without any problems. Driver is working fine. Speed and reliability is OK. So I for one can even offer to choose them instead of 3COM as in Russia you can easily get 2 from the 3 3COM cards that is not 3COM indeed :0) Not so for cheap Realteks :0) Good luck David Gilbert wrote: Kirill == Kirill Ponomarew [EMAIL PROTECTED] writes: Kirill Hi, On Thu, Mar 06, 2003 at 11:46:43AM -0300, Pablo Morales Kirill wrote: Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. Can someone give a good explanation of that or at least where can I find information about it? Kirill please read comments in /usr/src/sys/pci/if_rl.c It's worth noting that there's a scale to all this. The driver comments imply that the card will push 100Mb if you have enough power in the CPU ... defined as 400Mhz. Given the price of this card ... and the fact that less-than-400Mhz CPU's are rather rare, and that this is only an issue for high bandwidth applications ... the rl cards might fit for you. We use them extensively in workstations... even diskless. The reason being that with modern processors, they perform adequately ... and although they take up extra CPU ... CPUs are rather under-utilized resources in most workstations. Dave. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek
On Wednesday 12 March 2003 10:37, Doug Ambrisko wrote: Wes Peters writes: | Or you can cheat and use a SmartBits-2000 like I did. It can send | exactly 148,800 packets per second, with very precise timing of the | inter-packet Soon we should be getting an Ixia. That'll certainly do the trick. That is, if they actually manage to deliver it before the SmartBits people buy them up and kill them off; they've done that with at least one other competitor. | So it seems to keep up reasonably well, but this is misleading. Use | -l to force the packets out as quickly as the card can generate them: | | -bash-2.05b$ sudo ping -i 0.01 -c 5000 -l 5000 204.68.178.2 | ... | 64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms | 64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms | 64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms | | --- 204.68.178.2 ping statistics --- | 5000 packets transmitted, 95 packets received, 98% packet loss | round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms | | Wow. The receiving side handled the first 93 packets and then rolled | over, recovering for only the last packet. (Look at the icmp_seq | numbers.) FreeBSD behaves similarly, but try the test on your own. | ;^) I don't see any difference between the rl and fxp tests using the same originating machine and dest machine. The dest machine has both rl and fxp You won't, this is a problem endemic to the PCI bus. The problems with the RealTek chipset mostly have to do with CPU load doing real-world work, not silly-bugger tests. This *is* why anyone who thinks they can make a real, reliable router by cramming a couple of PCI cards into a FreeBSD box is deluded. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Wed, Mar 12, 2003 at 05:44:25PM +1100, Peter Jeremy wrote: ... Are you sure you were generating wire speed packets - this is about 200,000 packets/sec at Fast speed. ping -f runs at whatever rate 148,800kpps In order to get 200,000 pps, you're going to need 5-10 hosts generating traffic, each with a good NIC and connected to the test one is enough as long as it is sufficiently fast (750MHz and above in my experiments), you use a C program to call sendto() and generate UDP packets, and your network card can cope with the outgoing traffic (e.g. there is no way the 'fxp' can transmit over ~120kpps no matter how fast the CPU is; 'xl' and several 'dc' supported chips can do the job. Haven't tried other cards. Using polling on the sender side helps but it is not fundamental. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Wes Peters writes: | Or you can cheat and use a SmartBits-2000 like I did. It can send exactly | 148,800 packets per second, with very precise timing of the inter-packet Soon we should be getting an Ixia. | So it seems to keep up reasonably well, but this is misleading. Use -l to | force the packets out as quickly as the card can generate them: | | -bash-2.05b$ sudo ping -i 0.01 -c 5000 -l 5000 204.68.178.2 | ... | 64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms | 64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms | 64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms | | --- 204.68.178.2 ping statistics --- | 5000 packets transmitted, 95 packets received, 98% packet loss | round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms | | Wow. The receiving side handled the first 93 packets and then rolled | over, recovering for only the last packet. (Look at the icmp_seq | numbers.) FreeBSD behaves similarly, but try the test on your own. ;^) I don't see any difference between the rl and fxp tests using the same originating machine and dest machine. The dest machine has both rl and fxp the rl0 results (ping -i 0.01 -c 5000 -l 5000 IP): PING 192.168.99.2 (192.168.99.2): 56 data bytes 64 bytes from 192.168.99.2: icmp_seq=0 ttl=64 time=0.499 ms 64 bytes from 192.168.99.2: icmp_seq=1 ttl=64 time=0.467 ms 64 bytes from 192.168.99.2: icmp_seq=2 ttl=64 time=0.461 ms 64 bytes from 192.168.99.2: icmp_seq=3 ttl=64 time=0.458 ms 64 bytes from 192.168.99.2: icmp_seq=4 ttl=64 time=0.484 ms 64 bytes from 192.168.99.2: icmp_seq=5 ttl=64 time=0.502 ms 64 bytes from 192.168.99.2: icmp_seq=6 ttl=64 time=0.500 ms 64 bytes from 192.168.99.2: icmp_seq=7 ttl=64 time=0.498 ms 64 bytes from 192.168.99.2: icmp_seq=8 ttl=64 time=0.514 ms 64 bytes from 192.168.99.2: icmp_seq=9 ttl=64 time=0.508 ms 64 bytes from 192.168.99.2: icmp_seq=10 ttl=64 time=0.503 ms 64 bytes from 192.168.99.2: icmp_seq=11 ttl=64 time=0.519 ms 64 bytes from 192.168.99.2: icmp_seq=12 ttl=64 time=0.514 ms 64 bytes from 192.168.99.2: icmp_seq=13 ttl=64 time=0.512 ms 64 bytes from 192.168.99.2: icmp_seq=14 ttl=64 time=0.523 ms 64 bytes from 192.168.99.2: icmp_seq=15 ttl=64 time=0.520 ms 64 bytes from 192.168.99.2: icmp_seq=16 ttl=64 time=0.516 ms 64 bytes from 192.168.99.2: icmp_seq=17 ttl=64 time=0.525 ms 64 bytes from 192.168.99.2: icmp_seq=18 ttl=64 time=0.522 ms 64 bytes from 192.168.99.2: icmp_seq=19 ttl=64 time=0.519 ms 64 bytes from 192.168.99.2: icmp_seq=20 ttl=64 time=0.532 ms 64 bytes from 192.168.99.2: icmp_seq=21 ttl=64 time=0.527 ms 64 bytes from 192.168.99.2: icmp_seq=22 ttl=64 time=0.523 ms 64 bytes from 192.168.99.2: icmp_seq=23 ttl=64 time=0.535 ms 64 bytes from 192.168.99.2: icmp_seq=24 ttl=64 time=0.531 ms 64 bytes from 192.168.99.2: icmp_seq=25 ttl=64 time=0.529 ms 64 bytes from 192.168.99.2: icmp_seq=26 ttl=64 time=0.540 ms 64 bytes from 192.168.99.2: icmp_seq=27 ttl=64 time=0.535 ms 64 bytes from 192.168.99.2: icmp_seq=28 ttl=64 time=0.532 ms 64 bytes from 192.168.99.2: icmp_seq=29 ttl=64 time=0.541 ms 64 bytes from 192.168.99.2: icmp_seq=30 ttl=64 time=0.538 ms 64 bytes from 192.168.99.2: icmp_seq=31 ttl=64 time=0.533 ms 64 bytes from 192.168.99.2: icmp_seq=32 ttl=64 time=0.540 ms 64 bytes from 192.168.99.2: icmp_seq=33 ttl=64 time=0.553 ms 64 bytes from 192.168.99.2: icmp_seq=34 ttl=64 time=0.548 ms 64 bytes from 192.168.99.2: icmp_seq=35 ttl=64 time=0.544 ms 64 bytes from 192.168.99.2: icmp_seq=36 ttl=64 time=0.180 ms 64 bytes from 192.168.99.2: icmp_seq=37 ttl=64 time=0.175 ms 64 bytes from 192.168.99.2: icmp_seq=38 ttl=64 time=0.185 ms 64 bytes from 192.168.99.2: icmp_seq=39 ttl=64 time=0.180 ms 64 bytes from 192.168.99.2: icmp_seq=40 ttl=64 time=0.206 ms 64 bytes from 192.168.99.2: icmp_seq=41 ttl=64 time=0.204 ms 64 bytes from 192.168.99.2: icmp_seq=42 ttl=64 time=0.214 ms 64 bytes from 192.168.99.2: icmp_seq=43 ttl=64 time=0.208 ms 64 bytes from 192.168.99.2: icmp_seq=44 ttl=64 time=0.221 ms 64 bytes from 192.168.99.2: icmp_seq=45 ttl=64 time=0.218 ms 64 bytes from 192.168.99.2: icmp_seq=46 ttl=64 time=0.228 ms 64 bytes from 192.168.99.2: icmp_seq=47 ttl=64 time=0.225 ms 64 bytes from 192.168.99.2: icmp_seq=48 ttl=64 time=0.236 ms 64 bytes from 192.168.99.2: icmp_seq=49 ttl=64 time=0.233 ms 64 bytes from 192.168.99.2: icmp_seq=50 ttl=64 time=0.242 ms 64 bytes from 192.168.99.2: icmp_seq=51 ttl=64 time=0.160 ms 64 bytes from 192.168.99.2: icmp_seq=52 ttl=64 time=0.156 ms 64 bytes from 192.168.99.2: icmp_seq=53 ttl=64 time=0.166 ms 64 bytes from 192.168.99.2: icmp_seq=54 ttl=64 time=0.161 ms 64 bytes from 192.168.99.2: icmp_seq=55 ttl=64 time=0.185 ms 64 bytes from 192.168.99.2: icmp_seq=56 ttl=64 time=0.199 ms 64 bytes from 192.168.99.2: icmp_seq=57 ttl=64 time=0.196 ms 64 bytes from 192.168.99.2: icmp_seq=58 ttl=64 time=0.193 ms 64 bytes from
Re: Realtek
5000 packets transmitted, 94 packets received, 98% packet loss round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms So I'm not see much difference. are you sure it's not because of this: 'ping: sendto: No buffer space available'? 12.03.2003; 18:56:02 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
[EMAIL PROTECTED] writes: [ Charset ISO-8859-1 unsupported, converting... ] |5000 packets transmitted, 94 packets received, 98% packet loss |round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms | So I'm not see much difference. | | are you sure it's not because of this: | 'ping: sendto: No buffer space available'? No such messages appeared. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
| are you sure it's not because of this: | 'ping: sendto: No buffer space available'? No such messages appeared. I forgot that I hooked it up to 10Mbit hub for now, so nevermind 8) are you piping it through 'less'? you won't see this message in 'less' output what's the value of your 'kern.ipc.nmbclusters'? `sysctl kern.ipc.nmbclusters`: kern.ipc.nmbclusters: 4560 (FreeBSD 4.6.2-RELEASE) I'll test 'rl' vs 'xl' later on 100Mbit/s. 12.03.2003; 20:16:35 [SorAlx] http://cydem.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Wes Peters writes: | On Monday 10 March 2003 08:47, Doug Ambrisko wrote: | Hmm, I thought I had said benchmark in your environment. We have a | closed box that is sort-of a router and a bridge. So your only inputs | is really network traffic. That is what we tune the box for. So it | would be interesting to see you kill it in 1s. Again our issue is PCI | bus. | | Flood it with wire speed 64-byte packets and drive it into receive | interrupt livelock. Yup, the PCI bus is (most of) the problem here too. Can't reproduce it. Maybe they fixed it in the 8100L rev.? I tried a ping -f -s 22 to hit it with 64 byte packets. I also had traffic going to the onboard gig and it wasn't impacted (granted the source was a 100bit link tied to the gig link). I'm running variants of -stable (FreeBSD 4.7 and later) on this hardware. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Tue, Mar 11, 2003 at 11:20:36AM -0800, Doug Ambrisko wrote: Wes Peters writes: | Flood it with wire speed 64-byte packets and drive it into receive | interrupt livelock. Yup, the PCI bus is (most of) the problem here too. Can't reproduce it. Maybe they fixed it in the 8100L rev.? I tried a ping -f -s 22 to hit it with 64 byte packets. I also had traffic going to the onboard gig and it wasn't impacted (granted the source was a 100bit link tied to the gig link). Are you sure you were generating wire speed packets - this is about 200,000 packets/sec at Fast speed. ping -f runs at whatever rate the remote end returns the packets at (or 100pps) - since it (mostly) waits for a response before sending another packet, you will never see livelock. In order to get 200,000 pps, you're going to need 5-10 hosts generating traffic, each with a good NIC and connected to the test system via a decent switch. You also need a proper network benchmarking tool - netperf (ports/netperf) or similar rather than ping. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Luigi Rizzo wrote: At this price level, you can also consider the Intel PRO1000/MT (part number is PWLA8492MT) which has two Gig-E ports (copper), is well supported under FreeBSD by the Intel-supported em driver, and costs $174 (list price, if you shop eg. on yahoo you can find it cheaper than that). The good thing of this cart is that it works at Gig speed, and it is widely available so hopefully it won't disappear from the market by the time you place your order. No, the best thing about all GigE is that you don't need a twisty cable, It Just Works. They should do the same thing for the 100Mbit, IMO. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Terry Lambert writes: | No, the best thing about all GigE is that you don't need a twisty | cable, It Just Works. They should do the same thing for the 100Mbit, | IMO. 8-). They have started that. Via has atleast one auto-mdi/mdi-x nic chip. We'd like it if more companies start doing it but I wouldn't hold my breath. Caveat is that a Netgear auto mdi/mdi-x switch won't allways sync with the fxp0 in my laptop :-( So looks like we are in for another round of auto negotiation that doesn't always work. I do like the Intel gig cards, since you can get dual fiber and copper version. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Wes Peters writes: | On Friday 07 March 2003 09:16, Doug Ambrisko wrote: | You did something truly bizarre. I've tested similar cards on many | machines ranging from K6-2 400MHz to P4 2.4GHz and the RealTek | performance has always been at or near the bottom of the heap. On the | slower processors, the overhead of aligning packets shows heavily, but it | can be noticed on any system. Depends on what your systems is doing. We are PCI bus limited. | A number of the chips folded into the dc(4) driver are horrible and | perform right down there with the RealTek, but a few are fairly good. Agreed. We've tested the common 21143 and some clones. We also ran the tests a few times to the the dc(4) chip to get the TX delays right adjusted so they don't have FIFO under-runs since that adjustment kill performance. | The 3com 3c905s are generally quite good using the xl(4) driver, as are | the Intel EEPro's using fxp. I've read of others struggling with both | but never encountered this myself. I tend to be quite conservative about | throwing random versions of FreeBSD at systems, though, and many of those | complaints come from people at various points on -stable, rather than a | known release point. We've had good success with the fxp(4) chips except for a strange bug on an onboard motherboard version. There seems to be a bug in the eeprom setting for it that I patch in the fxp(4) driver. Unfortunately I'm guess at the correction since we haven't been able to get the definition of that register. Since Intel sets to that value and makes our bug go away we just do it. Makes me nervous though. | So I'd say given a sufficiently fast CPU and memory the Realteks work | pretty darn good. | | For a sufficient engine RPM, that escort will do 85 MPH in first gear, | too. ;^) Yep, and if you never have to turn a corner and the engine can handle it then it is okay. Our '87 Porsche 911 can't turn in a normal sense very fast due to cronic understeer. However, with a rear-weight bias it spins very fast. So to turn fast you just spin the car into the direction you need, gas it to stop the spin and off you go. Side benefit it that you don't need to brake as much going into a corner since when you are going side ways you are braking so you just factor that in. Is a Porsche 911 a performance car? In the right hands it is otherwise it's going backwards out of a corner which can be an interesting feeling! Sounds like a Corvair. | To date we haven't had any trouble with them and we've shipped a bunch. | | Give me 1 second and I can easily bring any of your systems to their | knees, regardless of which cards you have installed. Everything is | relative. Were you watching the system load while performing your | testing? Was the cpu doing anything but routing? Is it required to for | your application? These and many others are all important questions, and | tend to have different answers for every application. For a desktop | workstation with undemanding network application requirements (email, web | browsing, occasional software updates) RealTek or any other card that | successfully attach to the network and correctly autonegotiate with your | hub (shudder) or switch is fine. Even a RealTek. ;^) Hmm, I thought I had said benchmark in your environment. We have a closed box that is sort-of a router and a bridge. So your only inputs is really network traffic. That is what we tune the box for. So it would be interesting to see you kill it in 1s. Again our issue is PCI bus. Now that the P4 Serverworks chipset is out we finally have a machine that holds the current gig with crypto records by a lot (faster then a couple of P4 Xeon machines we have). With a 32bit/33Mhz we are pegged at the PCI chipset limits. One of the challenges of testing crypto (IPsec) stuff is having clients that can keep up. I'be been told there is a paper in the works for HW crypto performance based on this and other HW. So results of this should be published. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Monday 10 March 2003 08:47, Doug Ambrisko wrote: Hmm, I thought I had said benchmark in your environment. We have a closed box that is sort-of a router and a bridge. So your only inputs is really network traffic. That is what we tune the box for. So it would be interesting to see you kill it in 1s. Again our issue is PCI bus. Flood it with wire speed 64-byte packets and drive it into receive interrupt livelock. Yup, the PCI bus is (most of) the problem here too. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Fri, Mar 07, 2003 at 01:17:50PM -0800, Doug Ambrisko wrote: The DFE-580 is EOL. That is their solution to their less then optimal card with no replacement coming according to our rep. We are using our own custom board with the Realtek 8100L parts. | any suggestions (with benchmark results ?) heartily welcome ! I need to find them however, you need to benchmark in your environment since CPU load etc can effect things. PHK found a 4 port fxp card that was priced pretty good. I don't know how successful he has with them. I have had good luck with the Adaptec Quartet 66 cards, under both Linux and FreeBSD. YMMV, though. They come as 64-bit/66Mhz cards, which definitely keeps the 4 pipes full (though they will also work on a 64-bit/33Mhz bus). They work great with Cisco FEC too. The card has a PCI-to-PCI bridge onboard with four Starfire controllers hanging off of the end of it. If you look around you can get them reasonably cheap. I think I paid around $300 for the last one I bought after doing some thorough pricewatch scouring. It's a bit pricier than you'll pay for say a D-Link card or something but it's also got higher quality ethernet controllers on it. Chances are if you really need a four-port card $300 is not that much to throw at it. HTH, Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: brandon is something special as an institution To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Fri, Mar 07, 2003 at 03:49:05PM -0600, Brandon D. Valentine wrote: ... I have had good luck with the Adaptec Quartet 66 cards, under both Linux and FreeBSD. YMMV, though. They come as 64-bit/66Mhz cards, which ... controllers on it. Chances are if you really need a four-port card $300 is not that much to throw at it. At this price level, you can also consider the Intel PRO1000/MT (part number is PWLA8492MT) which has two Gig-E ports (copper), is well supported under FreeBSD by the Intel-supported em driver, and costs $174 (list price, if you shop eg. on yahoo you can find it cheaper than that). The good thing of this cart is that it works at Gig speed, and it is widely available so hopefully it won't disappear from the market by the time you place your order. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Wes Peters writes: | On Thursday 06 March 2003 15:02, Paulo Roberto wrote: | --- Bram Van Dam [EMAIL PROTECTED] wrote: | cheap they are they do their job fairly well. If performance isn't | an issue then go for it. | | I couldn't agree more. If you are just staying in 55 mph, you don't | need a Ferrari. | | It's not a ford vs. ferrari problem, it's that the ford only has first | gear, so you're doing 45 mph at redline and in grave danger of blowing | the heads off continuously. | | The problem with the RealTek chipset is that the packets have to be | aligned on some completely stupid boundary in memory (32 bytes if memory | serves). The driver code ends up copying the packet data to a tempory | buffer before sending it for almost every outgoing packet, which is just | totally stupid. [snip] | JUST SAY NO. Actually, test and the pick the fastest tends to be better. Since D-Link dropped their good 4-port card for a broken one which they discontinued we had to scramble for a solution. Our test bed was a basically a server machine tied to a router/bridge like thing with 4 clients. We'd run tests all to the server, all to the clients and everything at once. This illustrated the HW issue with the new D-Link 4 port card since none of their supported drivers and OSes could get over 20Mbs. We had 100FDX links to each client and a Gig link to the server. FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD must be broken even though it was faster then their supported OSes (Windows 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD driver. Using this framework we had a bridge riser card that we could plug 4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), sis(4) cards of various types and with our motherboard and CPU the rl(4) 8139C chips where the fastest via netperf with a significant margin. I went into the test biased against Realtek but couldn't justify not using them after testing. Now we are using the 8100L chip so we have a pretty simple design. So I'd say given a sufficiently fast CPU and memory the Realteks work pretty darn good. The speed win could be do to a slightly better bus interface. That was the problem with the newer D-Link 4 port card in that during RX the chip would take over the PCI bus for a lng time. A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot different then pushing 100Mbs with a P5 133Mhz. Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards. To date we haven't had any trouble with them and we've shipped a bunch. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Wes Peters wrote: The problem with the RealTek chipset is that the packets have to be aligned on some completely stupid boundary in memory (32 bytes if memory serves). The driver code ends up copying the packet data to a tempory buffer before sending it for almost every outgoing packet, which is just totally stupid. And TCP/IP headers are not an even multiple of the alignment boundary (4 bytes, actually). So every packet the card DMA's in has to be copied so that access to the TCP packet contents are aligned. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Le Friday 07 March 2003 18:16, Doug Ambrisko a écrit : [SNIP] everything at once. This illustrated the HW issue with the new D-Link 4 port card since none of their supported drivers and OSes could get over 20Mbs. We had 100FDX links to each client and a Gig link to the server. FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD must be broken even though it was faster then their supported OSes (Windows 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD driver. [re-SNIP] Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards. and the avid reader asks : so, now, what NIC are you really using ? (I too have used with great pleasure quite a bunch of DLink-DFE-570), and I was leaning towards using the newer DFE-580 4-port on another project ...) any suggestions (with benchmark results ?) heartily welcome ! TfH To date we haven't had any trouble with them and we've shipped a bunch. then, what are these them ? Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Thierry Herbelot writes: | Le Friday 07 March 2003 18:16, Doug Ambrisko a ?crit : | everything at once. This illustrated the HW issue with the new D-Link 4 | port card since none of their supported drivers and OSes could get over | 20Mbs. We had 100FDX links to each client and a Gig link to the server. | FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD | must be broken even though it was faster then their supported OSes | (Windows 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD | driver. | | [re-SNIP] | | Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port | cards. | | and the avid reader asks : so, now, what NIC are you really using ? (I too | have used with great pleasure quite a bunch of DLink-DFE-570), and I was | leaning towards using the newer DFE-580 4-port on another project ...) The DFE-580 is EOL. That is their solution to their less then optimal card with no replacement coming according to our rep. We are using our own custom board with the Realtek 8100L parts. | any suggestions (with benchmark results ?) heartily welcome ! I need to find them however, you need to benchmark in your environment since CPU load etc can effect things. PHK found a 4 port fxp card that was priced pretty good. I don't know how successful he has with them. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Friday 07 March 2003 09:16, Doug Ambrisko wrote: Wes Peters writes: | On Thursday 06 March 2003 15:02, Paulo Roberto wrote: | --- Bram Van Dam [EMAIL PROTECTED] wrote: | cheap they are they do their job fairly well. If performance | isn't an issue then go for it. | | I couldn't agree more. If you are just staying in 55 mph, you don't | need a Ferrari. | | It's not a ford vs. ferrari problem, it's that the ford only has | first gear, so you're doing 45 mph at redline and in grave danger of | blowing the heads off continuously. | | The problem with the RealTek chipset is that the packets have to be | aligned on some completely stupid boundary in memory (32 bytes if | memory serves). The driver code ends up copying the packet data to a | tempory buffer before sending it for almost every outgoing packet, | which is just totally stupid. [snip] | JUST SAY NO. Actually, test and the pick the fastest tends to be better. Since D-Link dropped their good 4-port card for a broken one which they discontinued we had to scramble for a solution. Our test bed was a basically a server machine tied to a router/bridge like thing with 4 clients. We'd run tests all to the server, all to the clients and everything at once. This illustrated the HW issue with the new D-Link 4 port card since none of their supported drivers and OSes could get over 20Mbs. We had 100FDX links to each client and a Gig link to the server. FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD must be broken even though it was faster then their supported OSes (Windows 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD driver. Using this framework we had a bridge riser card that we could plug 4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), sis(4) cards of various types and with our motherboard and CPU the rl(4) 8139C chips where the fastest via netperf with a significant margin. I went into the test biased against Realtek but couldn't justify not using them after testing. Now we are using the 8100L chip so we have a pretty simple design. You did something truly bizarre. I've tested similar cards on many machines ranging from K6-2 400MHz to P4 2.4GHz and the RealTek performance has always been at or near the bottom of the heap. On the slower processors, the overhead of aligning packets shows heavily, but it can be noticed on any system. A number of the chips folded into the dc(4) driver are horrible and perform right down there with the RealTek, but a few are fairly good. The 3com 3c905s are generally quite good using the xl(4) driver, as are the Intel EEPro's using fxp. I've read of others struggling with both but never encountered this myself. I tend to be quite conservative about throwing random versions of FreeBSD at systems, though, and many of those complaints come from people at various points on -stable, rather than a known release point. So I'd say given a sufficiently fast CPU and memory the Realteks work pretty darn good. For a sufficient engine RPM, that escort will do 85 MPH in first gear, too. ;^) The speed win could be do to a slightly better bus interface. That was the problem with the newer D-Link 4 port card in that during RX the chip would take over the PCI bus for a lng time. Yup, they're complicated beasts. For someone who is not going to work on the drivers themselves but wants performance, I suspect buying whatever you can get in bulk for eight dollars is not an optimal strategy. A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot different then pushing 100Mbs with a P5 133Mhz. Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards. To date we haven't had any trouble with them and we've shipped a bunch. Give me 1 second and I can easily bring any of your systems to their knees, regardless of which cards you have installed. Everything is relative. Were you watching the system load while performing your testing? Was the cpu doing anything but routing? Is it required to for your application? These and many others are all important questions, and tend to have different answers for every application. For a desktop workstation with undemanding network application requirements (email, web browsing, occasional software updates) RealTek or any other card that successfully attach to the network and correctly autonegotiate with your hub (shudder) or switch is fine. Even a RealTek. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Friday 07 March 2003 13:17, Doug Ambrisko wrote: Thierry Herbelot writes: | | and the avid reader asks : so, now, what NIC are you really using ? | (I too have used with great pleasure quite a bunch of DLink-DFE-570), | and I was leaning towards using the newer DFE-580 4-port on another | project ...) PHK found a 4 port fxp card that was priced pretty good. I don't know how successful he has with them. We're using a 2-port EEPro with 82551 chips with the two ports connected with relays and a watchdog; we get excellent throughput in our testing so far. I don't recall the vendor, it is Ad-something. I can look them up Monday if you email me about it then. I think they make a 4-port 551 card without the relays as well, but I don't know about pricing. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Realtek
HI there. Gotta question. Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. Can someone give a good explanation of that or at least where can I find information about it? Lotta thanxs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Hi, On Thu, Mar 06, 2003 at 11:46:43AM -0300, Pablo Morales wrote: HI there. Gotta question. Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. Can someone give a good explanation of that or at least where can I find information about it? please read comments in /usr/src/sys/pci/if_rl.c Kirill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
At 15:46 6/03/2003, you wrote: HI there. Gotta question. Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. I happen to have a couple of those realtek cards. They're definitely not the BEST every made, but not the worst either. Granted, I've never once reached 100mbits with them (usually around 30-50mbits), but considering how cheap they are they do their job fairly well. If performance isn't an issue then go for it. If it *is* an issue, look for 3Com the likes. Of course this isn't technical information, it however is first hand information from someone who's been using the cards for several years (me). - Bram To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Pablo Morales wrote: Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. Can someone give a good explanation of that or at least where can I find information about it? Second block comment in: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/pci/if_rl.c?rev=1.88content-type=text/plain or /usr/src/sys/pci/if_rl.c -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
Someone said that the realtek 8029 and 8139 ethernet cards are the worst cards ever made. My boss is planning to make a great buy of this cards for a communication project ( the reasons is obius, the cost of this cards ) I'm trying to persuade him to by 3com ethernet cards, but I need technical information to demostrate him that it's not a good inversion to buy those kind of cards. Can someone give a good explanation of that or at least where can I find information about it? What, exactly, will you be doing on these systems? On high end servers, where every last ounce of cpu is needed I've made use of various Intel network cards. However, on workstations, web servers (except at the very high end), and a few other things, losing a percent or two of CPU power isn't an issue. With the majority of web servers out there, every CPU made in the last 3 or 4 years can drive a realtek at full speed without an issue. Almost always your internet connection is the only limiting factor. With slower systems (400MHZ) you'd likely see a benefit from running the 3com. Otherwise, I wouldn't bother.. I've never regretted using them. (I've got a webserver with a 10Mbit link to the net -- The performance hit hasn't ever been noticable on that--As for workstations, 1 or 2% CPU is NOT an issue.. They might average 2-4k/sec over the course of a workday.. ). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
--- Bram Van Dam [EMAIL PROTECTED] wrote: cheap they are they do their job fairly well. If performance isn't an issue then go for it. I couldn't agree more. If you are just staying in 55 mph, you don't need a Ferrari. cheers __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek
On Thursday 06 March 2003 15:02, Paulo Roberto wrote: --- Bram Van Dam [EMAIL PROTECTED] wrote: cheap they are they do their job fairly well. If performance isn't an issue then go for it. I couldn't agree more. If you are just staying in 55 mph, you don't need a Ferrari. It's not a ford vs. ferrari problem, it's that the ford only has first gear, so you're doing 45 mph at redline and in grave danger of blowing the heads off continuously. The problem with the RealTek chipset is that the packets have to be aligned on some completely stupid boundary in memory (32 bytes if memory serves). The driver code ends up copying the packet data to a tempory buffer before sending it for almost every outgoing packet, which is just totally stupid. There are dozens of other chipsets in the same price range as the RealTek's that don't require this stupidity, most of them supported by the dc(4) driver. Track down a couple of different cards, try them out on your own, and they buy a bunch of them. Belkin is selling a card based on the Intel (formerly DEC) 21143 for $15; if you can find them in bulk you can probably get them for $8-9. Those are a LOT better than the RealTek cards. JUST SAY NO. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible problem with rl (Realtek) ethernet card driver in 4.5-STABLE
Does this look like a driver bug, a hardware fault or all of the above? I realise the realtek chips are not the best, but they shouldn't cause a box to fall over :) Here are the details from the core dumps I got, which led me to Hi, I had (in the words of Andrew Lloyd Webber) some Strange Things Mystifying when I was writting a device driver that were very similar. Later I upgraded to version 5.0 PREVIEW and the same code performed flawlessly. I have some deep seated suspicians that the VIA chipset had some problems in the 4.X releases. You might try a newer release (if not 4.5). Cheers Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible problem with rl (Realtek) ethernet card driver in 4.5-STABLE
Nigel Roberts writes: #10 0xc0237fbe in rl_rxeof (sc=0xc0b9d200) at ../../pci/if_rl.c:1151 #11 0xc023827a in rl_intr (arg=0xc0b9d200) at ../../pci/if_rl.c:1342 #12 0xc0279c7a in vec3 () #13 0xc01c2196 in ether_output (ifp=0xc0ba4000, m=0xc076af00, dst=0xc0c28770, rt0=0xc0c59d00) at ../../net/if_ethersubr.c:369 #14 0xc01d4663 in ip_output (m0=0xc076af00, opt=0x0, ro=0xc02f9970, flags=1, imo=0x0) at ../../netinet/ip_output.c:822 Was the realtek really at IRQ 3? I'm NOT an x86 hacker, and I don't understand the interrupt code there very well.. Is it possible to have an irq line which is shared between 2 devices which use different interrupt masks? If so, what prevents intr_mux() from being called for a TTY interrupt, and then calling another driver which shares the line but has a NET mask, even when NET interrupts are masked? Does this go away if you remove the serial line driver (sio) from your kernel? Can we see a (non verbose) dmesg from this box? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Possible problem with rl (Realtek) ethernet card driver in 4.5-STABLE
About a month ago, I ran into problems with a realtek card in an AMD
K6-2 based machine I have. The box was built to act as a firewall for
a 10Mb internet connection, and everytime it came under load ie. 5Mb
throughput, it fell over with a page fault, although occcasionally it
also fell over under minimal load. I've since replaced the card with
an fxp (intel) card and the problem has gone away.
The realtek card is currently sitting in a linux 2.4.17 machine and is
running fine (current uptime ~15 days) and handles high throughput
quite readily. I haven't tested the card in a machine running GENERIC,
but I can if anyone thinks it's worth doing. 2 * 128MB core dumps +
debug kernel are available on request.
Does this look like a driver bug, a hardware fault or all of the
above? I realise the realtek chips are not the best, but they
shouldn't cause a box to fall over :)
Here are the details from the core dumps I got, which led me to
believe it was a problem with the card/driver:
$ uname -a
FreeBSD earnest.nobiscuit.com 4.5-STABLE FreeBSD 4.5-STABLE #6: Sat Apr 27 12:42:27
NZST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EARNEST i386
$ gdb -k kernel.debug.20020427 vmcore.0
--snip--
IdlePTD at phsyical address 0x0039
initial pcb at physical address 0x002f8300
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3a
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc025387e
stack pointer = 0x10:0xc8cc1c2c
frame pointer = 0x10:0xc8cc1ccc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2271 (setiathome)
interrupt mask = net tty
trap number = 12
panic: page fault
syncing disks... 2
done
Uptime: 1d3h24m45s
dumping to dev #ad/0x20001, offset 401520
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc017e243 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc017e681 in panic (fmt=0xc02c802c %s) at ../../kern/kern_shutdown.c:595
#3 0xc0287583 in trap_fatal (frame=0xc8cc1bec, eva=58)
at ../../i386/i386/trap.c:966
#4 0xc0287231 in trap_pfault (frame=0xc8cc1bec, usermode=0, eva=58)
at ../../i386/i386/trap.c:859
#5 0xc0286dd7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -943714304, tf_esi = -1070594804, tf_ebp = -926147380,
tf_isp = -926147560, tf_ebx = 0, tf_edx = 0, tf_ecx = -926147464,
tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = -1071302530, tf_cs = 8,
tf_eflags = 66178, tf_esp = -926535008, tf_ss = -1070594804})
at ../../i386/i386/trap.c:458
#6 0xc025387e in vm_fault (map=0xc030050c, vaddr=3351252992,
fault_type=1 '\001', fault_flags=0) at ../../vm/vm_object.h:189
#7 0xc02871de in trap_pfault (frame=0xc8cc1d40, usermode=0, eva=3351252992)
at ../../i386/i386/trap.c:848
#8 0xc0286dd7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1066163320, tf_esi = -943714306, tf_ebp = -926147144,
tf_isp = -926147220, tf_ebx = -1066038272, tf_edx = 2048, tf_ecx = 286,
tf_eax = -122449014, tf_trapno = 12, tf_err = 0, tf_eip = -1071096414,
tf_cs = 8, tf_eflags = 66070, tf_esp = 6752410, tf_ss = -1066038272})
at ../../i386/i386/trap.c:458
#9 0xc0285da2 in generic_bcopy ()
#10 0xc0237fbe in rl_rxeof (sc=0xc0b9d200) at ../../pci/if_rl.c:1151
#11 0xc023827a in rl_intr (arg=0xc0b9d200) at ../../pci/if_rl.c:1342
#12 0xc0279c7a in vec3 ()
#13 0xc01c2196 in ether_output (ifp=0xc0ba4000, m=0xc076af00, dst=0xc0c28770,
rt0=0xc0c59d00) at ../../net/if_ethersubr.c:369
#14 0xc01d4663 in ip_output (m0=0xc076af00, opt=0x0, ro=0xc02f9970, flags=1,
imo=0x0) at ../../netinet/ip_output.c:822
#15 0xc01d3c78 in ip_forward (m=0xc076af00, srcrt=0)
at ../../netinet/ip_input.c:1745
#16 0xc01d2ca6 in ip_input (m=0xc076af00) at ../../netinet/ip_input.c:638
#17 0xc01d2ee7 in ipintr () at ../../netinet/ip_input.c:869
#18 0xc0279bf5 in swi_net_next ()
#19 0x1422c in ?? ()
#20 0x3414 in ?? ()
#21 0xef9b in ?? ()
#22 0x138fe in ?? ()
#23 0x13a25 in ?? ()
#24 0x2abb in ?? ()
#25 0x107e in ?? ()
$ gdb -k kernel.debug.20020427 vmcore.1
IdlePTD at phsyical address 0x0039
initial pcb at physical address 0x002f8300
panicstr: page fault
panic messages:
---
Fatal trap
Realtek RTL8100B
Is this supported? Cannot seem to find this version at ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.5-RELEASE/HARDWARE.HTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Realtek RTL8100B
In message: [EMAIL PROTECTED] Dan [EMAIL PROTECTED] writes: : : Is this supported? : Cannot seem to find this version at : ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.5-RELEASE/HARDWARE.HTM If this is a USB ethernet chip, then I just got done reviewing a driver from someone in Japan that should be going into the tree soon. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Realtek card support
Dear All, I usually don't recommend the 8139/29 for anything that is expected to work consistently. The cards work alright, but I prefer to stick to Digital or Intel based NICs for important tasks. While it's obviously well established that these cards should be used as doorstops (and they would even suck at that) my idea was that there may be someone out there who can make the driver at least not hang up the line. Force it hard to 10mbit, or even reset the card for each and every packet sent, fork the code for this chip into src/pci/if_sucks.c, but at least make it work. I don't intent to use this brand for anything but toilet paper, but I keep running into people who have these cards. If people in the store and have to choose between a us$20 realtek and a us$100 3com they go for the realtek. Right now we're sending them back to the store to spend the extra us$80. I'd find the person who'd make the driver work around this card a hero. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek card support
I'm using a PCMCIA CARDBUS version of the card in -CURRENT whitout any problems sofar. I don't have experience with the PCI or ISA versions of Realtec. I prefer the Intel E100B and the 3COM 3C905B PCI boards. "Koster, K.J." wrote: Dear All, I usually don't recommend the 8139/29 for anything that is expected to work consistently. The cards work alright, but I prefer to stick to Digital or Intel based NICs for important tasks. While it's obviously well established that these cards should be used as doorstops (and they would even suck at that) my idea was that there may be someone out there who can make the driver at least not hang up the line. Force it hard to 10mbit, or even reset the card for each and every packet sent, fork the code for this chip into src/pci/if_sucks.c, but at least make it work. I don't intent to use this brand for anything but toilet paper, but I keep running into people who have these cards. If people in the store and have to choose between a us$20 realtek and a us$100 3com they go for the realtek. Right now we're sending them back to the store to spend the extra us$80. I'd find the person who'd make the driver work around this card a hero. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek card support
In message [EMAIL PROTECTED] Arjan Knepper writes: : I'm using a PCMCIA CARDBUS version of the card in -CURRENT : whitout any problems What's the make/model of this card? I knew one existed, but not the make/model of it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek card support
Warner Losh wrote: In message [EMAIL PROTECTED] Arjan Knepper writes: : I'm using a PCMCIA CARDBUS version of the card in -CURRENT : whitout any problems What's the make/model of this card? I knew one existed, but not the make/model of it. Warner Its a Dynalink L100CLV 10/100Mbps LAN see http://www.dynalink.com/english/index.html Arjan begin:vcard n:Knepper;Arjan tel;fax:+31-(0)10-243-7314 tel;work:+31-(0)10-243-7362 x-mozilla-html:FALSE url:http://www.jak.nl org:JAK++ Software Development B.V. adr:;;Stoveer 247;Rotterdam;;3032 GB;Netherlands version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;-7904 fn:Arjan Knepper end:vcard
Re: Realtek card support
We've had horrible luck with the realtek 8139 with a few of our 10MBps hubs. We've had OK luck with cross over cables, but not good enough to run with that configuration in our deployed systems. We've also found that this is due to autonegotiation is the cause of this and that if we explicitly choose 10BaseT it works well enough to deploy in our systems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek card support
I usually don't recommend the 8139/29 for anything that is expected to work consistently. The cards work alright, but I prefer to stick to Digital or Intel based NICs for important tasks. Warner Losh had the audacity to say: We've had horrible luck with the realtek 8139 with a few of our 10MBps hubs. We've had OK luck with cross over cables, but not good enough to run with that configuration in our deployed systems. We've also found that this is due to autonegotiation is the cause of this and that if we explicitly choose 10BaseT it works well enough to deploy in our systems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Realtek card support
In message [EMAIL PROTECTED] Coleman Kane writes: : I usually don't recommend the 8139/29 for anything that is expected : to work consistently. The cards work alright, but I prefer to stick : to Digital or Intel based NICs for important tasks. Same here. However, with the SBCs we buy, we have little choice since they all seem to want to use RealTek. Likely due to bottom feeding reasons. I've also had good luck with 3Com NICs (use one in my main home server), but mixed luck with some Tulip and tulip-like clones. The dc driver does help that a lot, however... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Realtek card support
Dear All, I have two RealTek network cards that I'm willing to send to someone who is going to update the FreeBSD realtek driver to support them. I know it's supposed to be broken in the hardware, but the sad fact is that in the Netherlands this is the *only* card they sell in many smaller stores. If you say "network adaptor" they give you realtek. If you ask for another brand, they look at you funny and give you realtek. If you *insist* on another brand they give you more funny looks, and give you realtek with the words that it's the OEM version of your preferred brand. (Calm down, deep breath ... there, much better) Anyway: send me your snail mail address, and I'll send you the realtek card. Kees Jan PS. for the record: I also still have an SMC EtherEZ 10Mb UTP and a 3Com 3c503 for those who want to work on drivers for them. You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
