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: 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: port 0xe300-0xe3ff mem
0xed80-0xed8000ff irq 5 at device 16.0 on pci0
miibus0: on re0
rlphy0: on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:60:e0:e1:21:d7
re1: port 0xe400-0xe4ff mem
0xed801000-0xed8010ff irq 12 at device 17.0 on pci0
miibus1: on re1
rlphy1: on miibus1
rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re1: Ethernet address: 00:60:e0:e1:21:d6
re2: port 0xe500-0xe5ff mem
0xed802000-0xed8020ff irq 10 at device 18.0 on pci0
miibus2: on re2
rlphy2: on miibus2
rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re2: Ethernet address: 00:60:e0:e1:21:d5
re3: port 0xe600-0xe6ff mem
0xed803000-0xed8030ff irq 11 at device 19.0 on pci0
miibus3: on re3
rlphy3: on miibus3
rlphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re3: Ethernet address: 00:60:e0:e1:21:d4
# ifconfig -a
re0: flags=8843 mtu 1500
options=18
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=8843 mtu 1500
options=18
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=8802 mtu 1500
options=18
ether 00:60:e0:e1:21:d5
media: Ethernet autoselect (none)
re3: flags=8802 mtu 1500
options=18
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
class= network
subclass = ethernet
[EMAIL PROTECTED]:18:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
[EMAIL PROTECTED]:19:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x20
hdr=0x00
class= network
subclass = ethernet
--
Regards, /\_/\ "All dogs go to heaven."
[EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/
+==oOO--(_)--OOo---
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: 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: 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]"
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
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=11165804011&r=1&w=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 - Full dmesg(8): NetBSD 3.1_RC3 (CFRDMDROOT.MPACPI-$Revision: 1.21.4.5 $) #9: Sat Oct 14 21:19:14 EDT 2006 [EMAIL PROTECTED]:/home/nbsd/obj.i386/temp/sys/arch/i386/compile/CFRDMDROOT.MPACPI total memory = 189 MB avail memory = 166 MB BIOS32 rev. 0 found at 0xfb570 mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: VIA C3 Samuel 2/Ezra (686-class), 800.11 MHz, id 0x673 cpu0: features 80803035 cpu0: features 80803035 cpu0: features 80803035<3DNOW> cpu0: "VIA Samuel 2" cpu0: I-cache 64 KB 32B/line 4-way, D-cache 64 KB 32B/line 4-way cpu0: L2 cache 64 KB 32B/line 4-way cpu0: ITLB 128 4 KB entries 8-way cpu0: DTLB 128 4 KB entries 8-way cpu0: 4 page colors acpi0 at mainbus0 acpi0: using Intel ACPI CA subsystem version 20040211 acpi0: X/RSDT: OemId , AslId acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present ACPI Object Type 'Processor' (0x0c) at acpi0 not configured acpibut0 at acpi0 (PNP0C0C): ACPI Power Button PNP0C01 [System Board] at acpi0 not configured PNP0A03 [PCI Bus] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C0F [PCI interrupt link device] at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured PNP [AT Interrupt Controller] at acpi0 not configured PNP0200 [AT DMA Controller] at acpi0 not configured PNP0100 [AT Timer] at acpi0 not configured PNP0B00 [AT Real-Time Clock] at acpi0 not configured PNP0800 [AT-style speaker sound] at acpi0 not configured npx1 at acpi0 (PNP0C04) npx1: io 0xf0-0xff irq 13 npx1: using exception 16 fdc0 at acpi0 (PNP0700) fdc0: io 0x3f0-0x3f5,0x3f7 irq 6 drq 2 com0 at acpi0 (PNP0501-1) com0: io 0x3f8-0x3ff irq 4 com0: ns16550a, working fifo com1 at acpi0 (PNP0501-2) com1: io 0x2f8-0x2ff irq 3 com1: ns16550a, working fifo lpt0 at acpi0 (PNP0400-1) lpt0: io 0x378-0x37f irq 7 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: VIA Technologies product 0x0601 (rev. 0x05) agp0 at pchb0: aperture at 0xe800, size 0x1000 ppb0 at pci0 dev 1 function 0: VIA Technologies product 0x8601 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 0 function 0: Trident Microsystems product 0x8500 (rev. 0x6a) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation) wsmux1: connecting to wsdisplay0 pcib0 at pci0 dev 7 function 0 pcib0: VIA Technologies VT82C686A PCI-ISA Bridge (rev. 0x40) viaide0 at pci0 dev 7 function 1 viaide0: VIA Technologies VT82C686A (Apollo KX133) ATA100 controller viaide0: bus-master DMA support present viaide0: primary channel configured to compatibility mode viaide0: primary channel interrupting at irq 14 atabus0 at viaide0 channel 0 viaide0: secondary channel configured to compatibility mode viaide0: secondary channel interrupting at irq 15 atabus1 at viaide0 channel 1 uhci0 at pci0 dev 7 function 2: VIA Technologies VT83C572 USB Controller (rev. 0x1a) uhci0: interrupting at irq 10 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA Technolog
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=11165804011&r=1&w=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=11165804011&r=1&w=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]"
