NetBSD Problem Report #53494
From www@NetBSD.org Thu Aug 2 21:04:37 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 9850C7A180
for <gnats-bugs@gnats.NetBSD.org>; Thu, 2 Aug 2018 21:04:37 +0000 (UTC)
Message-Id: <20180802210434.A59897A1D7@mollari.NetBSD.org>
Date: Thu, 2 Aug 2018 21:04:34 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: vte doesn't work on eBox 3352DX3-AP
X-Send-Pr-Version: www-1.0
>Number: 53494
>Category: port-i386
>Synopsis: vte doesn't work on eBox 3352DX3-AP
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: andvar@NetBSD.org
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
>Closed-Date: Fri Sep 03 20:40:34 +0000 2021
>Last-Modified: Fri Sep 03 20:40:34 +0000 2021
>Originator: Andrius V
>Release: current
>Organization:
>Environment:
NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386
>Description:
Hello,
I recently received eBox 3352DX3-AP system which is based on VortexDX3 CPU. I am facing an issue with R6040 Ethernet controller on it. It can't set a media type (even if I am trying to set supported one manually) and it doesn't have any status value, dhcpcd sets some incorrect IP and I can't access the network. ifconfig vte0:
vte0: flags=0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=1<VLAN_MTU>
ec_enabled=0
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (none)
inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
General phy attaches to it (not a rdcphy) because it has different OUI and model. But even if I would register new OUI and model to rdcphy, it wouldn't change the behavior.
I am booting system without ACPI and SMP (it fails to boot with those because of other issue I still need to report). I tried controller on FreeBSD and Linux as well. FreeBSD seems to have the same issue, Linux works though. Please see dmesg below (there is also USB D-Link network card attached, it works):
NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
total memory = 1983 MB
avail memory = 1930 MB
rnd: seeded with 128 bits
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
running cgd selftest aes-xts-256 aes-xts-512 done
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
RDC Semiconductor Co., Ltd. EMKORE (1.0 )
mainbus0 (root)
cpu0 at mainbus0
cpu0: Vortex86DX3, id 0x611
cpu0: package 0, core 0, smt 0
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: vendor 17f3 product 6023 (rev. 0x02)
ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
vte0: Ethernet address xx:xx:xx:xx:xx:xx
vte0: interrupting at irq 5
ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
ohci0: interrupting at irq 14
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
ehci0: interrupting at irq 7
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: 1 companion controller, 4 ports: ohci0
usb1 at ehci0: USB revision 2.0
rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
rdcide0: bus-master DMA support present
rdcide0: primary channel configured to native-PCI mode
rdcide0: using irq 15 for native-PCI interrupt
atabus0 at rdcide0 channel 0
rdcide0: secondary channel configured to native-PCI mode
rdcide0: secondary channel ignored (disabled)
vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
hdaudio0: interrupting at irq 14
hdafg0 at hdaudio0: vendor 10ec product 0262
hdafg0: DAC00 2ch: Speaker [Jack]
hdafg0: DIG01 2ch: Digital Out [Jack]
hdafg0: ADC02 2ch: Mic In [Jack]
hdafg0: ADC03 2ch: Line In [Jack]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
hdafg0: Virtual format configured - Format SLINEAR, precision 16, channels 2, frequency 48000
hdafg0: Latency: 128 milliseconds
isa0 at pcib0
pckbc0 at isa0 port 0x60-0x64
attimer0 at isa0 port 0x40-0x43
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
attimer0: attached to pcppi0
isa at pcib1 not configured
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub1: 4 ports with 4 removable, self powered
IPsec: Initialized Security Association Processing.
axen0 at uhub1 port 1
axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.00, addr 2
axen0: AX88179
axen0: Ethernet address xx:xx:xx:xx:xx:xx
rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
ehci0: handing over low speed device on port 3 to ohci0
wd0 at atabus0 drive 0
wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
wd0: drive supports 1-sector PIO transfers, LBA addressing
wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA)
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
kern.module.path=/stand/i386/8.99.22/modules
uhidev0 at uhub0 port 3 configuration 1 interface 0
uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass 3/1
ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub0 port 3 configuration 1 interface 1
uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass 3/0
uhidev1: 2 report ids
uhid0 at uhidev1 reportid 1: input=2, output=0, feature=0
uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
>How-To-Repeat:
Boot system and run dhcpcd client for vte0.
>Fix:
>Release-Note:
>Audit-Trail:
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc: Masanobu SAITOH <msaitoh@execsw.org>
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Fri, 25 Oct 2019 19:16:35 +0300
Hi,
I did some debugging on this issue. Seemingly the problem lies on
ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
rdcphy_status). They both return 0xffff value which I believe
indicates some incorrect result. MII_BMSR has 0x782d value though.
In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
IFM_100_TX; by default, controller starts to work successfully (media
is attached, IP is getting assigned and it can connect to network), so
the hardware is OK by itself. Since the code is pretty much similar to
many other phys, I fail to understand the reason behind this issue, I
guess it may be some initialization issues in if_vte driver, but I
tried to compare it to Linux r6040 driver and I didn't find anything
radically different from NetBSD. Ideas where I can still check or what
can be potential reasons are really welcome. Thank you.
ifconfig of working vte0:
vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ec_capabilities=3D1<VLAN_MTU>
ec_enabled=3D0
address: xx:xx:xx:xx:xx:xx
media: Ethernet autoselect (100baseTX)
status: active
inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
Workaround diff (xxRDC defines new OUI):
diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
index 427744a958d..20392efda70 100644
--- a/sys/dev/mii/rdcphy.c
+++ b/sys/dev/mii/rdcphy.c
@@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
static const struct mii_phydesc rdcphys[] =3D {
MII_PHY_DESC(RDC, R6040),
+ MII_PHY_DESC(xxRDC, R6040),
MII_PHY_END,
};
@@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
mii_data *mii, int cmd)
}
break;
}
-
/* Update the media status. */
rdcphy_status(sc);
@@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_status |=3D IFM_ACTIVE;
PHY_READ(sc, MII_BMCR, &bmcr);
+
+ /*
if ((bmcr & BMCR_ISO) !=3D 0) {
mii->mii_media_active |=3D IFM_NONE;
mii->mii_media_status =3D 0;
@@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
if ((bmcr & BMCR_LOOP) !=3D 0)
mii->mii_media_active |=3D IFM_LOOP;
+ */
if ((bmcr & BMCR_AUTOEN) !=3D 0) {
if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
@@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_active |=3D IFM_10_T;
break;
default:
- mii->mii_media_active |=3D IFM_NONE;
+ mii->mii_media_active |=3D IFM_100_TX;
return;
}
if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
>
> >Number: 53494
> >Category: port-i386
> >Synopsis: vte doesn't work on eBox 3352DX3-AP
> >Confidential: no
> >Severity: serious
> >Priority: low
> >Responsible: port-i386-maintainer
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> >Originator: Andrius V
> >Release: current
> >Organization:
> >Environment:
> NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
i386
> >Description:
> Hello,
>
> I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
a media type (even if I am trying to set supported one manually) and it doe=
sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
s the network. ifconfig vte0:
> vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
tu 1500
> ec_capabilities=3D1<VLAN_MTU>
> ec_enabled=3D0
> address: xx:xx:xx:xx:xx:xx
> media: Ethernet autoselect (none)
> inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
>
> General phy attaches to it (not a rdcphy) because it has different OUI an=
d model. But even if I would register new OUI and model to rdcphy, it would=
n't change the behavior.
>
> I am booting system without ACPI and SMP (it fails to boot with those bec=
ause of other issue I still need to report). I tried controller on FreeBSD =
and Linux as well. FreeBSD seems to have the same issue, Linux works though=
. Please see dmesg below (there is also USB D-Link network card attached, i=
t works):
> NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> total memory =3D 1983 MB
> avail memory =3D 1930 MB
> rnd: seeded with 128 bits
> timecounter: Timecounters tick every 10.000 msec
> Kernelized RAIDframe activated
> running cgd selftest aes-xts-256 aes-xts-512 done
> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> RDC Semiconductor Co., Ltd. EMKORE (1.0 =
)
> mainbus0 (root)
> cpu0 at mainbus0
> cpu0: Vortex86DX3, id 0x611
> cpu0: package 0, core 0, smt 0
> 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: vendor 17f3 product 6023 (rev. 0x02)
> ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
.5GT/s
> pci1 at ppb0 bus 1
> pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
.5GT/s
> pci2 at ppb1 bus 2
> pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> vte0: Ethernet address xx:xx:xx:xx:xx:xx
> vte0: interrupting at irq 5
> ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> ohci0: interrupting at irq 14
> ohci0: OHCI version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> ehci0: interrupting at irq 7
> ehci0: BIOS has given up ownership
> ehci0: EHCI version 1.0
> ehci0: 1 companion controller, 4 ports: ohci0
> usb1 at ehci0: USB revision 2.0
> rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> rdcide0: bus-master DMA support present
> rdcide0: primary channel configured to native-PCI mode
> rdcide0: using irq 15 for native-PCI interrupt
> atabus0 at rdcide0 channel 0
> rdcide0: secondary channel configured to native-PCI mode
> rdcide0: secondary channel ignored (disabled)
> vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> wsmux1: connecting to wsdisplay0
> drm at vga0 not configured
> hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> hdaudio0: interrupting at irq 14
> hdafg0 at hdaudio0: vendor 10ec product 0262
> hdafg0: DAC00 2ch: Speaker [Jack]
> hdafg0: DIG01 2ch: Digital Out [Jack]
> hdafg0: ADC02 2ch: Mic In [Jack]
> hdafg0: ADC03 2ch: Line In [Jack]
> hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
s 2, frequency 48000
> hdafg0: Latency: 128 milliseconds
> isa0 at pcib0
> pckbc0 at isa0 port 0x60-0x64
> attimer0 at isa0 port 0x40-0x43
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: PC speaker
> sysbeep0 at pcppi0
> attimer0: attached to pcppi0
> isa at pcib1 not configured
> timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
00, addr 1
> uhub0: 4 ports with 4 removable, self powered
> uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
00, addr 1
> uhub1: 4 ports with 4 removable, self powered
> IPsec: Initialized Security Association Processing.
> axen0 at uhub1 port 1
> axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
0, addr 2
> axen0: AX88179
> axen0: Ethernet address xx:xx:xx:xx:xx:xx
> rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
ev. 5
> rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
uto
> ehci0: handing over low speed device on port 3 to ohci0
> wd0 at atabus0 drive 0
> wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> wd0: drive supports 1-sector PIO transfers, LBA addressing
> wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
ors
> wd0: 32-bit data port
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
00) (using DMA)
> boot device: wd0
> root on wd0a dumps on wd0b
> root file system type: ffs
> kern.module.path=3D/stand/i386/8.99.22/modules
> uhidev0 at uhub0 port 3 configuration 1 interface 0
> uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
3/1
> ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> wskbd0 at ukbd0: console keyboard, using wsdisplay0
> uhidev1 at uhub0 port 3 configuration 1 interface 1
> uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
3/0
> uhidev1: 2 report ids
> uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> wsdisplay0: screen 1 added (80x25, vt100 emulation)
> wsdisplay0: screen 2 added (80x25, vt100 emulation)
> wsdisplay0: screen 3 added (80x25, vt100 emulation)
> wsdisplay0: screen 4 added (80x25, vt100 emulation)
>
> >How-To-Repeat:
> Boot system and run dhcpcd client for vte0.
> >Fix:
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Mon, 23 Dec 2019 14:48:10 +0200
Hi,
There's a weird pattern which may give some clue to the issue: it
seems like every second PHY register fails to be read
(vte_miibus_readreg). Registers with the odd number (1,3,5, etc)
return some "proper" non zero value or zero. Every even address
(0,2,4, etc) return 0xFFFF though. Any idea why it may be happening?
On Fri, Oct 25, 2019 at 7:20 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> Cc: Masanobu SAITOH <msaitoh@execsw.org>
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Fri, 25 Oct 2019 19:16:35 +0300
>
> Hi,
>
> I did some debugging on this issue. Seemingly the problem lies on
> ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
> rdcphy_status). They both return 0xffff value which I believe
> indicates some incorrect result. MII_BMSR has 0x782d value though.
>
> In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
> IFM_100_TX; by default, controller starts to work successfully (media
> is attached, IP is getting assigned and it can connect to network), so
> the hardware is OK by itself. Since the code is pretty much similar to
> many other phys, I fail to understand the reason behind this issue, I
> guess it may be some initialization issues in if_vte driver, but I
> tried to compare it to Linux r6040 driver and I didn't find anything
> radically different from NetBSD. Ideas where I can still check or what
> can be potential reasons are really welcome. Thank you.
>
> ifconfig of working vte0:
> vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> ec_capabilities=3D1<VLAN_MTU>
> ec_enabled=3D0
> address: xx:xx:xx:xx:xx:xx
> media: Ethernet autoselect (100baseTX)
> status: active
> inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
> inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
>
> Workaround diff (xxRDC defines new OUI):
>
> diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> index 427744a958d..20392efda70 100644
> --- a/sys/dev/mii/rdcphy.c
> +++ b/sys/dev/mii/rdcphy.c
> @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
>
> static const struct mii_phydesc rdcphys[] =3D {
> MII_PHY_DESC(RDC, R6040),
> + MII_PHY_DESC(xxRDC, R6040),
> MII_PHY_END,
> };
>
> @@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
> mii_data *mii, int cmd)
> }
> break;
> }
> -
> /* Update the media status. */
> rdcphy_status(sc);
>
> @@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
> mii->mii_media_status |=3D IFM_ACTIVE;
>
> PHY_READ(sc, MII_BMCR, &bmcr);
> +
> + /*
> if ((bmcr & BMCR_ISO) !=3D 0) {
> mii->mii_media_active |=3D IFM_NONE;
> mii->mii_media_status =3D 0;
> @@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
>
> if ((bmcr & BMCR_LOOP) !=3D 0)
> mii->mii_media_active |=3D IFM_LOOP;
> + */
>
> if ((bmcr & BMCR_AUTOEN) !=3D 0) {
> if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
> @@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
> mii->mii_media_active |=3D IFM_10_T;
> break;
> default:
> - mii->mii_media_active |=3D IFM_NONE;
> + mii->mii_media_active |=3D IFM_100_TX;
> return;
> }
> if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
>
> On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
> >
> > >Number: 53494
> > >Category: port-i386
> > >Synopsis: vte doesn't work on eBox 3352DX3-AP
> > >Confidential: no
> > >Severity: serious
> > >Priority: low
> > >Responsible: port-i386-maintainer
> > >State: open
> > >Class: sw-bug
> > >Submitter-Id: net
> > >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> > >Originator: Andrius V
> > >Release: current
> > >Organization:
> > >Environment:
> > NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
> UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
> i386
> > >Description:
> > Hello,
> >
> > I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
> U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
> a media type (even if I am trying to set supported one manually) and it doe=
> sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
> s the network. ifconfig vte0:
> > vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
> tu 1500
> > ec_capabilities=3D1<VLAN_MTU>
> > ec_enabled=3D0
> > address: xx:xx:xx:xx:xx:xx
> > media: Ethernet autoselect (none)
> > inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> >
> > General phy attaches to it (not a rdcphy) because it has different OUI an=
> d model. But even if I would register new OUI and model to rdcphy, it would=
> n't change the behavior.
> >
> > I am booting system without ACPI and SMP (it fails to boot with those bec=
> ause of other issue I still need to report). I tried controller on FreeBSD =
> and Linux as well. FreeBSD seems to have the same issue, Linux works though=
> . Please see dmesg below (there is also USB D-Link network card attached, i=
> t works):
> > NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> > total memory =3D 1983 MB
> > avail memory =3D 1930 MB
> > rnd: seeded with 128 bits
> > timecounter: Timecounters tick every 10.000 msec
> > Kernelized RAIDframe activated
> > running cgd selftest aes-xts-256 aes-xts-512 done
> > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > RDC Semiconductor Co., Ltd. EMKORE (1.0 =
> )
> > mainbus0 (root)
> > cpu0 at mainbus0
> > cpu0: Vortex86DX3, id 0x611
> > cpu0: package 0, core 0, smt 0
> > 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: vendor 17f3 product 6023 (rev. 0x02)
> > ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> .5GT/s
> > pci1 at ppb0 bus 1
> > pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> > ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> .5GT/s
> > pci2 at ppb1 bus 2
> > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> > pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> > pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> > vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> > vte0: Ethernet address xx:xx:xx:xx:xx:xx
> > vte0: interrupting at irq 5
> > ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> > ohci0: interrupting at irq 14
> > ohci0: OHCI version 1.0, legacy support
> > usb0 at ohci0: USB revision 1.0
> > ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> > ehci0: interrupting at irq 7
> > ehci0: BIOS has given up ownership
> > ehci0: EHCI version 1.0
> > ehci0: 1 companion controller, 4 ports: ohci0
> > usb1 at ehci0: USB revision 2.0
> > rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> > rdcide0: bus-master DMA support present
> > rdcide0: primary channel configured to native-PCI mode
> > rdcide0: using irq 15 for native-PCI interrupt
> > atabus0 at rdcide0 channel 0
> > rdcide0: secondary channel configured to native-PCI mode
> > rdcide0: secondary channel ignored (disabled)
> > vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> > wsmux1: connecting to wsdisplay0
> > drm at vga0 not configured
> > hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> > hdaudio0: interrupting at irq 14
> > hdafg0 at hdaudio0: vendor 10ec product 0262
> > hdafg0: DAC00 2ch: Speaker [Jack]
> > hdafg0: DIG01 2ch: Digital Out [Jack]
> > hdafg0: ADC02 2ch: Mic In [Jack]
> > hdafg0: ADC03 2ch: Line In [Jack]
> > hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> > audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> > hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
> s 2, frequency 48000
> > hdafg0: Latency: 128 milliseconds
> > isa0 at pcib0
> > pckbc0 at isa0 port 0x60-0x64
> > attimer0 at isa0 port 0x40-0x43
> > pcppi0 at isa0 port 0x61
> > midi0 at pcppi0: PC speaker
> > sysbeep0 at pcppi0
> > attimer0: attached to pcppi0
> > isa at pcib1 not configured
> > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> > uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
> 00, addr 1
> > uhub0: 4 ports with 4 removable, self powered
> > uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
> 00, addr 1
> > uhub1: 4 ports with 4 removable, self powered
> > IPsec: Initialized Security Association Processing.
> > axen0 at uhub1 port 1
> > axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
> 0, addr 2
> > axen0: AX88179
> > axen0: Ethernet address xx:xx:xx:xx:xx:xx
> > rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
> ev. 5
> > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
> uto
> > ehci0: handing over low speed device on port 3 to ohci0
> > wd0 at atabus0 drive 0
> > wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> > wd0: drive supports 1-sector PIO transfers, LBA addressing
> > wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
> ors
> > wd0: 32-bit data port
> > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> > wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
> 00) (using DMA)
> > boot device: wd0
> > root on wd0a dumps on wd0b
> > root file system type: ffs
> > kern.module.path=3D/stand/i386/8.99.22/modules
> > uhidev0 at uhub0 port 3 configuration 1 interface 0
> > uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> 3/1
> > ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> > wskbd0 at ukbd0: console keyboard, using wsdisplay0
> > uhidev1 at uhub0 port 3 configuration 1 interface 1
> > uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> 3/0
> > uhidev1: 2 report ids
> > uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> > uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> > wsdisplay0: screen 1 added (80x25, vt100 emulation)
> > wsdisplay0: screen 2 added (80x25, vt100 emulation)
> > wsdisplay0: screen 3 added (80x25, vt100 emulation)
> > wsdisplay0: screen 4 added (80x25, vt100 emulation)
> >
> > >How-To-Repeat:
> > Boot system and run dhcpcd client for vte0.
> > >Fix:
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Mon, 13 Jan 2020 14:52:06 +0200
Finally, I found some more clear clue on the failure - the main
culprit for failed link establishment and not properly working PHY
registers is mac reset (vte_reset code). It even distorts
functionality to the point that OUI becomes different. Removing
vte_reset from vte_attach changes OUI from 0xfcff2f back to 0x00d02d
which is the same value as currently defined for RDC in
miidevs.Commenting out all vte_reset calls keeps all PHY registers
functional in all operations (and with some additional tweaks vte
works quite well for me, while booted without ACPI/SMP; on ACPI still
fails somewhere). Since Linux reset code is the same (I think they
have a bug in waiting loop but it doesn't change functionality), I
believe vte_reset should work though, but it should be used only on
vte_init and vte_stop. However, I don't know yet, why this behavior is
not elevated in Linux. Maybe, this Linux commit can be a culprit since
NetBSD lacks this code:
https://github.com/torvalds/linux/commit/06e92c33999fd66128c2256b0461455633c3d53c
but I am not sure what is the counterpart of phy_start/stop in NetBSD
to test? Is it ifmedia_init/ifmedia_set, or reattachment of PHY in
general?
It is not the only issue to make a fully work vte interface but
vte_reset is certainly the main reason for PHY misbehavior. I think
other issues may be easier to fix, since I already have working
controller (at least on non ACPI/SMP boot) just need to pinpoint which
of my changes were necessary (the latest comparison can be found in my
github: https://github.com/vezhlys/netbsd-src/compare/master...vezhlys:vte#files_bucket).
Any help appreciated. Thanks.
Regards,
Andrius V
On Mon, Dec 23, 2019 at 2:50 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Mon, 23 Dec 2019 14:48:10 +0200
>
> Hi,
>
> There's a weird pattern which may give some clue to the issue: it
> seems like every second PHY register fails to be read
> (vte_miibus_readreg). Registers with the odd number (1,3,5, etc)
> return some "proper" non zero value or zero. Every even address
> (0,2,4, etc) return 0xFFFF though. Any idea why it may be happening?
>
> On Fri, Oct 25, 2019 at 7:20 PM Andrius V <vezhlys@gmail.com> wrote:
> >
> > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > Cc: Masanobu SAITOH <msaitoh@execsw.org>
> > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > Date: Fri, 25 Oct 2019 19:16:35 +0300
> >
> > Hi,
> >
> > I did some debugging on this issue. Seemingly the problem lies on
> > ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
> > rdcphy_status). They both return 0xffff value which I believe
> > indicates some incorrect result. MII_BMSR has 0x782d value though.
> >
> > In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
> > IFM_100_TX; by default, controller starts to work successfully (media
> > is attached, IP is getting assigned and it can connect to network), so
> > the hardware is OK by itself. Since the code is pretty much similar to
> > many other phys, I fail to understand the reason behind this issue, I
> > guess it may be some initialization issues in if_vte driver, but I
> > tried to compare it to Linux r6040 driver and I didn't find anything
> > radically different from NetBSD. Ideas where I can still check or what
> > can be potential reasons are really welcome. Thank you.
> >
> > ifconfig of working vte0:
> > vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > ec_capabilities=3D1<VLAN_MTU>
> > ec_enabled=3D0
> > address: xx:xx:xx:xx:xx:xx
> > media: Ethernet autoselect (100baseTX)
> > status: active
> > inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
> > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> >
> > Workaround diff (xxRDC defines new OUI):
> >
> > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> > index 427744a958d..20392efda70 100644
> > --- a/sys/dev/mii/rdcphy.c
> > +++ b/sys/dev/mii/rdcphy.c
> > @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
> >
> > static const struct mii_phydesc rdcphys[] =3D {
> > MII_PHY_DESC(RDC, R6040),
> > + MII_PHY_DESC(xxRDC, R6040),
> > MII_PHY_END,
> > };
> >
> > @@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
> > mii_data *mii, int cmd)
> > }
> > break;
> > }
> > -
> > /* Update the media status. */
> > rdcphy_status(sc);
> >
> > @@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
> > mii->mii_media_status |=3D IFM_ACTIVE;
> >
> > PHY_READ(sc, MII_BMCR, &bmcr);
> > +
> > + /*
> > if ((bmcr & BMCR_ISO) !=3D 0) {
> > mii->mii_media_active |=3D IFM_NONE;
> > mii->mii_media_status =3D 0;
> > @@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
> >
> > if ((bmcr & BMCR_LOOP) !=3D 0)
> > mii->mii_media_active |=3D IFM_LOOP;
> > + */
> >
> > if ((bmcr & BMCR_AUTOEN) !=3D 0) {
> > if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
> > @@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
> > mii->mii_media_active |=3D IFM_10_T;
> > break;
> > default:
> > - mii->mii_media_active |=3D IFM_NONE;
> > + mii->mii_media_active |=3D IFM_100_TX;
> > return;
> > }
> > if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
> >
> > On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
> > >
> > > >Number: 53494
> > > >Category: port-i386
> > > >Synopsis: vte doesn't work on eBox 3352DX3-AP
> > > >Confidential: no
> > > >Severity: serious
> > > >Priority: low
> > > >Responsible: port-i386-maintainer
> > > >State: open
> > > >Class: sw-bug
> > > >Submitter-Id: net
> > > >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> > > >Originator: Andrius V
> > > >Release: current
> > > >Organization:
> > > >Environment:
> > > NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
> > UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
> > i386
> > > >Description:
> > > Hello,
> > >
> > > I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
> > U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
> > a media type (even if I am trying to set supported one manually) and it doe=
> > sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
> > s the network. ifconfig vte0:
> > > vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
> > tu 1500
> > > ec_capabilities=3D1<VLAN_MTU>
> > > ec_enabled=3D0
> > > address: xx:xx:xx:xx:xx:xx
> > > media: Ethernet autoselect (none)
> > > inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > >
> > > General phy attaches to it (not a rdcphy) because it has different OUI an=
> > d model. But even if I would register new OUI and model to rdcphy, it would=
> > n't change the behavior.
> > >
> > > I am booting system without ACPI and SMP (it fails to boot with those bec=
> > ause of other issue I still need to report). I tried controller on FreeBSD =
> > and Linux as well. FreeBSD seems to have the same issue, Linux works though=
> > . Please see dmesg below (there is also USB D-Link network card attached, i=
> > t works):
> > > NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > total memory =3D 1983 MB
> > > avail memory =3D 1930 MB
> > > rnd: seeded with 128 bits
> > > timecounter: Timecounters tick every 10.000 msec
> > > Kernelized RAIDframe activated
> > > running cgd selftest aes-xts-256 aes-xts-512 done
> > > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > > RDC Semiconductor Co., Ltd. EMKORE (1.0 =
> > )
> > > mainbus0 (root)
> > > cpu0 at mainbus0
> > > cpu0: Vortex86DX3, id 0x611
> > > cpu0: package 0, core 0, smt 0
> > > 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: vendor 17f3 product 6023 (rev. 0x02)
> > > ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > .5GT/s
> > > pci1 at ppb0 bus 1
> > > pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> > > ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > .5GT/s
> > > pci2 at ppb1 bus 2
> > > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> > > pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> > > pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> > > vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> > > vte0: Ethernet address xx:xx:xx:xx:xx:xx
> > > vte0: interrupting at irq 5
> > > ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > > ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> > > ohci0: interrupting at irq 14
> > > ohci0: OHCI version 1.0, legacy support
> > > usb0 at ohci0: USB revision 1.0
> > > ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> > > ehci0: interrupting at irq 7
> > > ehci0: BIOS has given up ownership
> > > ehci0: EHCI version 1.0
> > > ehci0: 1 companion controller, 4 ports: ohci0
> > > usb1 at ehci0: USB revision 2.0
> > > rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> > > rdcide0: bus-master DMA support present
> > > rdcide0: primary channel configured to native-PCI mode
> > > rdcide0: using irq 15 for native-PCI interrupt
> > > atabus0 at rdcide0 channel 0
> > > rdcide0: secondary channel configured to native-PCI mode
> > > rdcide0: secondary channel ignored (disabled)
> > > vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> > > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> > > wsmux1: connecting to wsdisplay0
> > > drm at vga0 not configured
> > > hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> > > hdaudio0: interrupting at irq 14
> > > hdafg0 at hdaudio0: vendor 10ec product 0262
> > > hdafg0: DAC00 2ch: Speaker [Jack]
> > > hdafg0: DIG01 2ch: Digital Out [Jack]
> > > hdafg0: ADC02 2ch: Mic In [Jack]
> > > hdafg0: ADC03 2ch: Line In [Jack]
> > > hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> > > audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> > > hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
> > s 2, frequency 48000
> > > hdafg0: Latency: 128 milliseconds
> > > isa0 at pcib0
> > > pckbc0 at isa0 port 0x60-0x64
> > > attimer0 at isa0 port 0x40-0x43
> > > pcppi0 at isa0 port 0x61
> > > midi0 at pcppi0: PC speaker
> > > sysbeep0 at pcppi0
> > > attimer0: attached to pcppi0
> > > isa at pcib1 not configured
> > > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> > > uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
> > 00, addr 1
> > > uhub0: 4 ports with 4 removable, self powered
> > > uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
> > 00, addr 1
> > > uhub1: 4 ports with 4 removable, self powered
> > > IPsec: Initialized Security Association Processing.
> > > axen0 at uhub1 port 1
> > > axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
> > 0, addr 2
> > > axen0: AX88179
> > > axen0: Ethernet address xx:xx:xx:xx:xx:xx
> > > rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
> > ev. 5
> > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
> > uto
> > > ehci0: handing over low speed device on port 3 to ohci0
> > > wd0 at atabus0 drive 0
> > > wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> > > wd0: drive supports 1-sector PIO transfers, LBA addressing
> > > wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
> > ors
> > > wd0: 32-bit data port
> > > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> > > wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
> > 00) (using DMA)
> > > boot device: wd0
> > > root on wd0a dumps on wd0b
> > > root file system type: ffs
> > > kern.module.path=3D/stand/i386/8.99.22/modules
> > > uhidev0 at uhub0 port 3 configuration 1 interface 0
> > > uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > 3/1
> > > ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> > > wskbd0 at ukbd0: console keyboard, using wsdisplay0
> > > uhidev1 at uhub0 port 3 configuration 1 interface 1
> > > uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > 3/0
> > > uhidev1: 2 report ids
> > > uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> > > uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> > > wsdisplay0: screen 1 added (80x25, vt100 emulation)
> > > wsdisplay0: screen 2 added (80x25, vt100 emulation)
> > > wsdisplay0: screen 3 added (80x25, vt100 emulation)
> > > wsdisplay0: screen 4 added (80x25, vt100 emulation)
> > >
> > > >How-To-Repeat:
> > > Boot system and run dhcpcd client for vte0.
> > > >Fix:
> > >
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Thu, 30 Jan 2020 23:40:10 +0200
On the probably the last attempt to move forward, I tried different
ways to put link down (mii_down, setting link down, etc), even
completely deattaching/attaching rdcphy before/after reset. Despite
all the attempts, the outcome is the same: phy stops working properly
(every second register fails to operate, phy OUI value changes to
0xfcff2f). Seems like MAC reset command just somehow messes it up
internally no matter what. Due to different reasons, I could not build
custom working Linux kernel on the system, so it is hard to tell how
Linux avoids reset problem, despite seemingly having the same code.
mii-tool fails to get any info about PHY, including OUI value, so I
can't compare it. Maybe, the Linux forces the link somehow, similarly
to what I did in initial workaround (just by forcefully setting
IFM_100_TX and ignoring bcmr and status register values), maybe reset
somehow works there properly. I can only guess. DHCP failure to get IP
address on ACPI is likely unrelated/separate issue (maybe related to
the USB failure on ACPI), since link still establishes properly. I
tested and confirmed that same workaround (removing vte_reset calls)
works on FreeBSD 12.0, including ACPI/SMP boot (FreeBSD doesn't have
USB issues on ACPI/SMP as well). On OpenBSD it also helps to set media
type properly but similarly to ACPI boot in NetBSD, DHCP fails to
assign IP address. Besides these findings, I exhausted all the other
testing options. Since I have only one system, it's hard to tell if it
is phy model issue, system one or just something else I missed to
notice. Nevertheless it may be worth to add new phy model into
miidevs, in case some systems behave differently (and possibly
renaming RDC to xxRDC, since OUI value is not correct in NetBSD
(0x00d02d instead of official 0x000bb4 value)):
diff --git a/sys/dev/mii/miidevs b/sys/dev/mii/miidevs
index 4554ced3982..0ab52a75a2b 100644
--- a/sys/dev/mii/miidevs
+++ b/sys/dev/mii/miidevs
@@ -362,6 +362,7 @@ model xxQUALSEMI QS6612 0x0000 QS6612
10/100 media interface
/* RDC Semiconductor PHYs */
model RDC R6040 0x0003 R6040 10/100 media interface
+model RDC R6040_2 0x0005 R6040 10/100 media interface
--- a/sys/dev/mii/rdcphy.c
+++ b/sys/dev/mii/rdcphy.c
@@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs = {
static const struct mii_phydesc rdcphys[] = {
MII_PHY_DESC(RDC, R6040),
+ MII_PHY_DESC(RDC, R6040_2),
MII_PHY_END,
};
Regards,
Andrius V
On Mon, Jan 13, 2020 at 2:55 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Mon, 13 Jan 2020 14:52:06 +0200
>
> Finally, I found some more clear clue on the failure - the main
> culprit for failed link establishment and not properly working PHY
> registers is mac reset (vte_reset code). It even distorts
> functionality to the point that OUI becomes different. Removing
> vte_reset from vte_attach changes OUI from 0xfcff2f back to 0x00d02d
> which is the same value as currently defined for RDC in
> miidevs.Commenting out all vte_reset calls keeps all PHY registers
> functional in all operations (and with some additional tweaks vte
> works quite well for me, while booted without ACPI/SMP; on ACPI still
> fails somewhere). Since Linux reset code is the same (I think they
> have a bug in waiting loop but it doesn't change functionality), I
> believe vte_reset should work though, but it should be used only on
> vte_init and vte_stop. However, I don't know yet, why this behavior is
> not elevated in Linux. Maybe, this Linux commit can be a culprit since
> NetBSD lacks this code:
> https://github.com/torvalds/linux/commit/06e92c33999fd66128c2256b0461455633c3d53c
> but I am not sure what is the counterpart of phy_start/stop in NetBSD
> to test? Is it ifmedia_init/ifmedia_set, or reattachment of PHY in
> general?
>
> It is not the only issue to make a fully work vte interface but
> vte_reset is certainly the main reason for PHY misbehavior. I think
> other issues may be easier to fix, since I already have working
> controller (at least on non ACPI/SMP boot) just need to pinpoint which
> of my changes were necessary (the latest comparison can be found in my
> github: https://github.com/vezhlys/netbsd-src/compare/master...vezhlys:vte#files_bucket).
> Any help appreciated. Thanks.
>
> Regards,
> Andrius V
>
>
> On Mon, Dec 23, 2019 at 2:50 PM Andrius V <vezhlys@gmail.com> wrote:
> >
> > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > Cc:
> > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > Date: Mon, 23 Dec 2019 14:48:10 +0200
> >
> > Hi,
> >
> > There's a weird pattern which may give some clue to the issue: it
> > seems like every second PHY register fails to be read
> > (vte_miibus_readreg). Registers with the odd number (1,3,5, etc)
> > return some "proper" non zero value or zero. Every even address
> > (0,2,4, etc) return 0xFFFF though. Any idea why it may be happening?
> >
> > On Fri, Oct 25, 2019 at 7:20 PM Andrius V <vezhlys@gmail.com> wrote:
> > >
> > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > Cc: Masanobu SAITOH <msaitoh@execsw.org>
> > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > Date: Fri, 25 Oct 2019 19:16:35 +0300
> > >
> > > Hi,
> > >
> > > I did some debugging on this issue. Seemingly the problem lies on
> > > ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
> > > rdcphy_status). They both return 0xffff value which I believe
> > > indicates some incorrect result. MII_BMSR has 0x782d value though.
> > >
> > > In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
> > > IFM_100_TX; by default, controller starts to work successfully (media
> > > is attached, IP is getting assigned and it can connect to network), so
> > > the hardware is OK by itself. Since the code is pretty much similar to
> > > many other phys, I fail to understand the reason behind this issue, I
> > > guess it may be some initialization issues in if_vte driver, but I
> > > tried to compare it to Linux r6040 driver and I didn't find anything
> > > radically different from NetBSD. Ideas where I can still check or what
> > > can be potential reasons are really welcome. Thank you.
> > >
> > > ifconfig of working vte0:
> > > vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > ec_capabilities=3D1<VLAN_MTU>
> > > ec_enabled=3D0
> > > address: xx:xx:xx:xx:xx:xx
> > > media: Ethernet autoselect (100baseTX)
> > > status: active
> > > inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
> > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > >
> > > Workaround diff (xxRDC defines new OUI):
> > >
> > > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> > > index 427744a958d..20392efda70 100644
> > > --- a/sys/dev/mii/rdcphy.c
> > > +++ b/sys/dev/mii/rdcphy.c
> > > @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
> > >
> > > static const struct mii_phydesc rdcphys[] =3D {
> > > MII_PHY_DESC(RDC, R6040),
> > > + MII_PHY_DESC(xxRDC, R6040),
> > > MII_PHY_END,
> > > };
> > >
> > > @@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
> > > mii_data *mii, int cmd)
> > > }
> > > break;
> > > }
> > > -
> > > /* Update the media status. */
> > > rdcphy_status(sc);
> > >
> > > @@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
> > > mii->mii_media_status |=3D IFM_ACTIVE;
> > >
> > > PHY_READ(sc, MII_BMCR, &bmcr);
> > > +
> > > + /*
> > > if ((bmcr & BMCR_ISO) !=3D 0) {
> > > mii->mii_media_active |=3D IFM_NONE;
> > > mii->mii_media_status =3D 0;
> > > @@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
> > >
> > > if ((bmcr & BMCR_LOOP) !=3D 0)
> > > mii->mii_media_active |=3D IFM_LOOP;
> > > + */
> > >
> > > if ((bmcr & BMCR_AUTOEN) !=3D 0) {
> > > if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
> > > @@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
> > > mii->mii_media_active |=3D IFM_10_T;
> > > break;
> > > default:
> > > - mii->mii_media_active |=3D IFM_NONE;
> > > + mii->mii_media_active |=3D IFM_100_TX;
> > > return;
> > > }
> > > if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
> > >
> > > On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
> > > >
> > > > >Number: 53494
> > > > >Category: port-i386
> > > > >Synopsis: vte doesn't work on eBox 3352DX3-AP
> > > > >Confidential: no
> > > > >Severity: serious
> > > > >Priority: low
> > > > >Responsible: port-i386-maintainer
> > > > >State: open
> > > > >Class: sw-bug
> > > > >Submitter-Id: net
> > > > >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> > > > >Originator: Andrius V
> > > > >Release: current
> > > > >Organization:
> > > > >Environment:
> > > > NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
> > > UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
> > > i386
> > > > >Description:
> > > > Hello,
> > > >
> > > > I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
> > > U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
> > > a media type (even if I am trying to set supported one manually) and it doe=
> > > sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
> > > s the network. ifconfig vte0:
> > > > vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
> > > tu 1500
> > > > ec_capabilities=3D1<VLAN_MTU>
> > > > ec_enabled=3D0
> > > > address: xx:xx:xx:xx:xx:xx
> > > > media: Ethernet autoselect (none)
> > > > inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> > > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > > >
> > > > General phy attaches to it (not a rdcphy) because it has different OUI an=
> > > d model. But even if I would register new OUI and model to rdcphy, it would=
> > > n't change the behavior.
> > > >
> > > > I am booting system without ACPI and SMP (it fails to boot with those bec=
> > > ause of other issue I still need to report). I tried controller on FreeBSD =
> > > and Linux as well. FreeBSD seems to have the same issue, Linux works though=
> > > . Please see dmesg below (there is also USB D-Link network card attached, i=
> > > t works):
> > > > NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> > > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > > total memory =3D 1983 MB
> > > > avail memory =3D 1930 MB
> > > > rnd: seeded with 128 bits
> > > > timecounter: Timecounters tick every 10.000 msec
> > > > Kernelized RAIDframe activated
> > > > running cgd selftest aes-xts-256 aes-xts-512 done
> > > > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > > > RDC Semiconductor Co., Ltd. EMKORE (1.0 =
> > > )
> > > > mainbus0 (root)
> > > > cpu0 at mainbus0
> > > > cpu0: Vortex86DX3, id 0x611
> > > > cpu0: package 0, core 0, smt 0
> > > > 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: vendor 17f3 product 6023 (rev. 0x02)
> > > > ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > .5GT/s
> > > > pci1 at ppb0 bus 1
> > > > pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > .5GT/s
> > > > pci2 at ppb1 bus 2
> > > > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> > > > pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> > > > vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> > > > vte0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > vte0: interrupting at irq 5
> > > > ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > > > ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> > > > ohci0: interrupting at irq 14
> > > > ohci0: OHCI version 1.0, legacy support
> > > > usb0 at ohci0: USB revision 1.0
> > > > ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> > > > ehci0: interrupting at irq 7
> > > > ehci0: BIOS has given up ownership
> > > > ehci0: EHCI version 1.0
> > > > ehci0: 1 companion controller, 4 ports: ohci0
> > > > usb1 at ehci0: USB revision 2.0
> > > > rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> > > > rdcide0: bus-master DMA support present
> > > > rdcide0: primary channel configured to native-PCI mode
> > > > rdcide0: using irq 15 for native-PCI interrupt
> > > > atabus0 at rdcide0 channel 0
> > > > rdcide0: secondary channel configured to native-PCI mode
> > > > rdcide0: secondary channel ignored (disabled)
> > > > vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> > > > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> > > > wsmux1: connecting to wsdisplay0
> > > > drm at vga0 not configured
> > > > hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> > > > hdaudio0: interrupting at irq 14
> > > > hdafg0 at hdaudio0: vendor 10ec product 0262
> > > > hdafg0: DAC00 2ch: Speaker [Jack]
> > > > hdafg0: DIG01 2ch: Digital Out [Jack]
> > > > hdafg0: ADC02 2ch: Mic In [Jack]
> > > > hdafg0: ADC03 2ch: Line In [Jack]
> > > > hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> > > > audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> > > > hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
> > > s 2, frequency 48000
> > > > hdafg0: Latency: 128 milliseconds
> > > > isa0 at pcib0
> > > > pckbc0 at isa0 port 0x60-0x64
> > > > attimer0 at isa0 port 0x40-0x43
> > > > pcppi0 at isa0 port 0x61
> > > > midi0 at pcppi0: PC speaker
> > > > sysbeep0 at pcppi0
> > > > attimer0: attached to pcppi0
> > > > isa at pcib1 not configured
> > > > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> > > > uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
> > > 00, addr 1
> > > > uhub0: 4 ports with 4 removable, self powered
> > > > uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
> > > 00, addr 1
> > > > uhub1: 4 ports with 4 removable, self powered
> > > > IPsec: Initialized Security Association Processing.
> > > > axen0 at uhub1 port 1
> > > > axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
> > > 0, addr 2
> > > > axen0: AX88179
> > > > axen0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
> > > ev. 5
> > > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
> > > uto
> > > > ehci0: handing over low speed device on port 3 to ohci0
> > > > wd0 at atabus0 drive 0
> > > > wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> > > > wd0: drive supports 1-sector PIO transfers, LBA addressing
> > > > wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
> > > ors
> > > > wd0: 32-bit data port
> > > > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> > > > wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
> > > 00) (using DMA)
> > > > boot device: wd0
> > > > root on wd0a dumps on wd0b
> > > > root file system type: ffs
> > > > kern.module.path=3D/stand/i386/8.99.22/modules
> > > > uhidev0 at uhub0 port 3 configuration 1 interface 0
> > > > uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > 3/1
> > > > ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> > > > wskbd0 at ukbd0: console keyboard, using wsdisplay0
> > > > uhidev1 at uhub0 port 3 configuration 1 interface 1
> > > > uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > 3/0
> > > > uhidev1: 2 report ids
> > > > uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> > > > uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> > > > wsdisplay0: screen 1 added (80x25, vt100 emulation)
> > > > wsdisplay0: screen 2 added (80x25, vt100 emulation)
> > > > wsdisplay0: screen 3 added (80x25, vt100 emulation)
> > > > wsdisplay0: screen 4 added (80x25, vt100 emulation)
> > > >
> > > > >How-To-Repeat:
> > > > Boot system and run dhcpcd client for vte0.
> > > > >Fix:
> > > >
> > >
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Fri, 18 Jun 2021 16:56:07 +0300
Hi,
I would probably recommend to close this bug for now and consider my
hardware being faulty until proved differently. Just tested the same
functionality in Linux driver, and it appeared to have the same issue
after reset command, that every second register stops reporting its
actual value. The controller still worked in Linux only for the reason
that solely BMSR value was used to bring the interface up, and this
register still works properly after reset. More recent Linux kernels
(>5.3) started using BMCR register too, thus R6040 fails to work in
the same manner as in BSDs. I found at least one dmesg report
(https://dmesgd.nycbug.org/index.cgi?do=view&id=2524) with the same
0x0005 PHY model (different SoC though: EX instead DX3), which was
reporting oui value correctly, indicating that it did not suffer from
vte_reset the issue as in my device. So, it does not seem to be PHY
model related behaviour either. Maybe it is SoC related but it's
impossible to know without having another device. I would suspect that
it is more likely to be my unit issue (whatever is the reason).
Unrelated to my bug report, but Linux seemingly has an opposite check here:
On Thu, Jan 30, 2020 at 11:45 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Thu, 30 Jan 2020 23:40:10 +0200
>
> On the probably the last attempt to move forward, I tried different
> ways to put link down (mii_down, setting link down, etc), even
> completely deattaching/attaching rdcphy before/after reset. Despite
> all the attempts, the outcome is the same: phy stops working properly
> (every second register fails to operate, phy OUI value changes to
> 0xfcff2f). Seems like MAC reset command just somehow messes it up
> internally no matter what. Due to different reasons, I could not build
> custom working Linux kernel on the system, so it is hard to tell how
> Linux avoids reset problem, despite seemingly having the same code.
> mii-tool fails to get any info about PHY, including OUI value, so I
> can't compare it. Maybe, the Linux forces the link somehow, similarly
> to what I did in initial workaround (just by forcefully setting
> IFM_100_TX and ignoring bcmr and status register values), maybe reset
> somehow works there properly. I can only guess. DHCP failure to get IP
> address on ACPI is likely unrelated/separate issue (maybe related to
> the USB failure on ACPI), since link still establishes properly. I
> tested and confirmed that same workaround (removing vte_reset calls)
> works on FreeBSD 12.0, including ACPI/SMP boot (FreeBSD doesn't have
> USB issues on ACPI/SMP as well). On OpenBSD it also helps to set media
> type properly but similarly to ACPI boot in NetBSD, DHCP fails to
> assign IP address. Besides these findings, I exhausted all the other
> testing options. Since I have only one system, it's hard to tell if it
> is phy model issue, system one or just something else I missed to
> notice. Nevertheless it may be worth to add new phy model into
> miidevs, in case some systems behave differently (and possibly
> renaming RDC to xxRDC, since OUI value is not correct in NetBSD
> (0x00d02d instead of official 0x000bb4 value)):
>
> diff --git a/sys/dev/mii/miidevs b/sys/dev/mii/miidevs
> index 4554ced3982..0ab52a75a2b 100644
> --- a/sys/dev/mii/miidevs
> +++ b/sys/dev/mii/miidevs
> @@ -362,6 +362,7 @@ model xxQUALSEMI QS6612 0x0000 QS6612
> 10/100 media interface
>
> /* RDC Semiconductor PHYs */
> model RDC R6040 0x0003 R6040 10/100 media interface
> +model RDC R6040_2 0x0005 R6040 10/100 media interface
>
> --- a/sys/dev/mii/rdcphy.c
> +++ b/sys/dev/mii/rdcphy.c
> @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs = {
>
> static const struct mii_phydesc rdcphys[] = {
> MII_PHY_DESC(RDC, R6040),
> + MII_PHY_DESC(RDC, R6040_2),
> MII_PHY_END,
> };
>
> Regards,
> Andrius V
>
> On Mon, Jan 13, 2020 at 2:55 PM Andrius V <vezhlys@gmail.com> wrote:
> >
> > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > Cc:
> > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > Date: Mon, 13 Jan 2020 14:52:06 +0200
> >
> > Finally, I found some more clear clue on the failure - the main
> > culprit for failed link establishment and not properly working PHY
> > registers is mac reset (vte_reset code). It even distorts
> > functionality to the point that OUI becomes different. Removing
> > vte_reset from vte_attach changes OUI from 0xfcff2f back to 0x00d02d
> > which is the same value as currently defined for RDC in
> > miidevs.Commenting out all vte_reset calls keeps all PHY registers
> > functional in all operations (and with some additional tweaks vte
> > works quite well for me, while booted without ACPI/SMP; on ACPI still
> > fails somewhere). Since Linux reset code is the same (I think they
> > have a bug in waiting loop but it doesn't change functionality), I
> > believe vte_reset should work though, but it should be used only on
> > vte_init and vte_stop. However, I don't know yet, why this behavior is
> > not elevated in Linux. Maybe, this Linux commit can be a culprit since
> > NetBSD lacks this code:
> > https://github.com/torvalds/linux/commit/06e92c33999fd66128c2256b0461455633c3d53c
> > but I am not sure what is the counterpart of phy_start/stop in NetBSD
> > to test? Is it ifmedia_init/ifmedia_set, or reattachment of PHY in
> > general?
> >
> > It is not the only issue to make a fully work vte interface but
> > vte_reset is certainly the main reason for PHY misbehavior. I think
> > other issues may be easier to fix, since I already have working
> > controller (at least on non ACPI/SMP boot) just need to pinpoint which
> > of my changes were necessary (the latest comparison can be found in my
> > github: https://github.com/vezhlys/netbsd-src/compare/master...vezhlys:vte#files_bucket).
> > Any help appreciated. Thanks.
> >
> > Regards,
> > Andrius V
> >
> >
> > On Mon, Dec 23, 2019 at 2:50 PM Andrius V <vezhlys@gmail.com> wrote:
> > >
> > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > Cc:
> > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > Date: Mon, 23 Dec 2019 14:48:10 +0200
> > >
> > > Hi,
> > >
> > > There's a weird pattern which may give some clue to the issue: it
> > > seems like every second PHY register fails to be read
> > > (vte_miibus_readreg). Registers with the odd number (1,3,5, etc)
> > > return some "proper" non zero value or zero. Every even address
> > > (0,2,4, etc) return 0xFFFF though. Any idea why it may be happening?
> > >
> > > On Fri, Oct 25, 2019 at 7:20 PM Andrius V <vezhlys@gmail.com> wrote:
> > > >
> > > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > > >
> > > > From: Andrius V <vezhlys@gmail.com>
> > > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > > Cc: Masanobu SAITOH <msaitoh@execsw.org>
> > > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > > Date: Fri, 25 Oct 2019 19:16:35 +0300
> > > >
> > > > Hi,
> > > >
> > > > I did some debugging on this issue. Seemingly the problem lies on
> > > > ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
> > > > rdcphy_status). They both return 0xffff value which I believe
> > > > indicates some incorrect result. MII_BMSR has 0x782d value though.
> > > >
> > > > In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
> > > > IFM_100_TX; by default, controller starts to work successfully (media
> > > > is attached, IP is getting assigned and it can connect to network), so
> > > > the hardware is OK by itself. Since the code is pretty much similar to
> > > > many other phys, I fail to understand the reason behind this issue, I
> > > > guess it may be some initialization issues in if_vte driver, but I
> > > > tried to compare it to Linux r6040 driver and I didn't find anything
> > > > radically different from NetBSD. Ideas where I can still check or what
> > > > can be potential reasons are really welcome. Thank you.
> > > >
> > > > ifconfig of working vte0:
> > > > vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > > ec_capabilities=3D1<VLAN_MTU>
> > > > ec_enabled=3D0
> > > > address: xx:xx:xx:xx:xx:xx
> > > > media: Ethernet autoselect (100baseTX)
> > > > status: active
> > > > inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
> > > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > > >
> > > > Workaround diff (xxRDC defines new OUI):
> > > >
> > > > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> > > > index 427744a958d..20392efda70 100644
> > > > --- a/sys/dev/mii/rdcphy.c
> > > > +++ b/sys/dev/mii/rdcphy.c
> > > > @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
> > > >
> > > > static const struct mii_phydesc rdcphys[] =3D {
> > > > MII_PHY_DESC(RDC, R6040),
> > > > + MII_PHY_DESC(xxRDC, R6040),
> > > > MII_PHY_END,
> > > > };
> > > >
> > > > @@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
> > > > mii_data *mii, int cmd)
> > > > }
> > > > break;
> > > > }
> > > > -
> > > > /* Update the media status. */
> > > > rdcphy_status(sc);
> > > >
> > > > @@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
> > > > mii->mii_media_status |=3D IFM_ACTIVE;
> > > >
> > > > PHY_READ(sc, MII_BMCR, &bmcr);
> > > > +
> > > > + /*
> > > > if ((bmcr & BMCR_ISO) !=3D 0) {
> > > > mii->mii_media_active |=3D IFM_NONE;
> > > > mii->mii_media_status =3D 0;
> > > > @@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
> > > >
> > > > if ((bmcr & BMCR_LOOP) !=3D 0)
> > > > mii->mii_media_active |=3D IFM_LOOP;
> > > > + */
> > > >
> > > > if ((bmcr & BMCR_AUTOEN) !=3D 0) {
> > > > if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
> > > > @@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
> > > > mii->mii_media_active |=3D IFM_10_T;
> > > > break;
> > > > default:
> > > > - mii->mii_media_active |=3D IFM_NONE;
> > > > + mii->mii_media_active |=3D IFM_100_TX;
> > > > return;
> > > > }
> > > > if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
> > > >
> > > > On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
> > > > >
> > > > > >Number: 53494
> > > > > >Category: port-i386
> > > > > >Synopsis: vte doesn't work on eBox 3352DX3-AP
> > > > > >Confidential: no
> > > > > >Severity: serious
> > > > > >Priority: low
> > > > > >Responsible: port-i386-maintainer
> > > > > >State: open
> > > > > >Class: sw-bug
> > > > > >Submitter-Id: net
> > > > > >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> > > > > >Originator: Andrius V
> > > > > >Release: current
> > > > > >Organization:
> > > > > >Environment:
> > > > > NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
> > > > UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
> > > > i386
> > > > > >Description:
> > > > > Hello,
> > > > >
> > > > > I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
> > > > U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
> > > > a media type (even if I am trying to set supported one manually) and it doe=
> > > > sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
> > > > s the network. ifconfig vte0:
> > > > > vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
> > > > tu 1500
> > > > > ec_capabilities=3D1<VLAN_MTU>
> > > > > ec_enabled=3D0
> > > > > address: xx:xx:xx:xx:xx:xx
> > > > > media: Ethernet autoselect (none)
> > > > > inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> > > > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > > > >
> > > > > General phy attaches to it (not a rdcphy) because it has different OUI an=
> > > > d model. But even if I would register new OUI and model to rdcphy, it would=
> > > > n't change the behavior.
> > > > >
> > > > > I am booting system without ACPI and SMP (it fails to boot with those bec=
> > > > ause of other issue I still need to report). I tried controller on FreeBSD =
> > > > and Linux as well. FreeBSD seems to have the same issue, Linux works though=
> > > > . Please see dmesg below (there is also USB D-Link network card attached, i=
> > > > t works):
> > > > > NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> > > > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > > > total memory =3D 1983 MB
> > > > > avail memory =3D 1930 MB
> > > > > rnd: seeded with 128 bits
> > > > > timecounter: Timecounters tick every 10.000 msec
> > > > > Kernelized RAIDframe activated
> > > > > running cgd selftest aes-xts-256 aes-xts-512 done
> > > > > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > > > > RDC Semiconductor Co., Ltd. EMKORE (1.0 =
> > > > )
> > > > > mainbus0 (root)
> > > > > cpu0 at mainbus0
> > > > > cpu0: Vortex86DX3, id 0x611
> > > > > cpu0: package 0, core 0, smt 0
> > > > > 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: vendor 17f3 product 6023 (rev. 0x02)
> > > > > ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > > ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > > .5GT/s
> > > > > pci1 at ppb0 bus 1
> > > > > pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > > ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > > ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > > .5GT/s
> > > > > pci2 at ppb1 bus 2
> > > > > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > > pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> > > > > pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> > > > > vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> > > > > vte0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > > vte0: interrupting at irq 5
> > > > > ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> > > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > > > > ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> > > > > ohci0: interrupting at irq 14
> > > > > ohci0: OHCI version 1.0, legacy support
> > > > > usb0 at ohci0: USB revision 1.0
> > > > > ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> > > > > ehci0: interrupting at irq 7
> > > > > ehci0: BIOS has given up ownership
> > > > > ehci0: EHCI version 1.0
> > > > > ehci0: 1 companion controller, 4 ports: ohci0
> > > > > usb1 at ehci0: USB revision 2.0
> > > > > rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> > > > > rdcide0: bus-master DMA support present
> > > > > rdcide0: primary channel configured to native-PCI mode
> > > > > rdcide0: using irq 15 for native-PCI interrupt
> > > > > atabus0 at rdcide0 channel 0
> > > > > rdcide0: secondary channel configured to native-PCI mode
> > > > > rdcide0: secondary channel ignored (disabled)
> > > > > vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> > > > > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> > > > > wsmux1: connecting to wsdisplay0
> > > > > drm at vga0 not configured
> > > > > hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> > > > > hdaudio0: interrupting at irq 14
> > > > > hdafg0 at hdaudio0: vendor 10ec product 0262
> > > > > hdafg0: DAC00 2ch: Speaker [Jack]
> > > > > hdafg0: DIG01 2ch: Digital Out [Jack]
> > > > > hdafg0: ADC02 2ch: Mic In [Jack]
> > > > > hdafg0: ADC03 2ch: Line In [Jack]
> > > > > hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> > > > > audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> > > > > hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
> > > > s 2, frequency 48000
> > > > > hdafg0: Latency: 128 milliseconds
> > > > > isa0 at pcib0
> > > > > pckbc0 at isa0 port 0x60-0x64
> > > > > attimer0 at isa0 port 0x40-0x43
> > > > > pcppi0 at isa0 port 0x61
> > > > > midi0 at pcppi0: PC speaker
> > > > > sysbeep0 at pcppi0
> > > > > attimer0: attached to pcppi0
> > > > > isa at pcib1 not configured
> > > > > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> > > > > uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
> > > > 00, addr 1
> > > > > uhub0: 4 ports with 4 removable, self powered
> > > > > uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
> > > > 00, addr 1
> > > > > uhub1: 4 ports with 4 removable, self powered
> > > > > IPsec: Initialized Security Association Processing.
> > > > > axen0 at uhub1 port 1
> > > > > axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
> > > > 0, addr 2
> > > > > axen0: AX88179
> > > > > axen0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > > rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
> > > > ev. 5
> > > > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
> > > > uto
> > > > > ehci0: handing over low speed device on port 3 to ohci0
> > > > > wd0 at atabus0 drive 0
> > > > > wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> > > > > wd0: drive supports 1-sector PIO transfers, LBA addressing
> > > > > wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
> > > > ors
> > > > > wd0: 32-bit data port
> > > > > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> > > > > wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
> > > > 00) (using DMA)
> > > > > boot device: wd0
> > > > > root on wd0a dumps on wd0b
> > > > > root file system type: ffs
> > > > > kern.module.path=3D/stand/i386/8.99.22/modules
> > > > > uhidev0 at uhub0 port 3 configuration 1 interface 0
> > > > > uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > > 3/1
> > > > > ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> > > > > wskbd0 at ukbd0: console keyboard, using wsdisplay0
> > > > > uhidev1 at uhub0 port 3 configuration 1 interface 1
> > > > > uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > > 3/0
> > > > > uhidev1: 2 report ids
> > > > > uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> > > > > uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> > > > > wsdisplay0: screen 1 added (80x25, vt100 emulation)
> > > > > wsdisplay0: screen 2 added (80x25, vt100 emulation)
> > > > > wsdisplay0: screen 3 added (80x25, vt100 emulation)
> > > > > wsdisplay0: screen 4 added (80x25, vt100 emulation)
> > > > >
> > > > > >How-To-Repeat:
> > > > > Boot system and run dhcpcd client for vte0.
> > > > > >Fix:
> > > > >
> > > >
> > >
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Fri, 18 Jun 2021 17:11:56 +0300
> Unrelated to my bug report, but Linux seemingly has an opposite check here:
My hand slipped and I sent my email prematurely. I wanted to write,
that this check is the opposite in Linux:
if ((CSR_READ_2(sc, VTE_MCR1) & MCR1_MAC_RESET) == 0)
break;
It checks for true value before breaking, which sometimes happens,
sometimes reaches timeout (it is also a bigger value 2048 against
VTE_RESET_TIMEOUT being 100). But it may be more correct check in
Linux, since the current one usually breaks immediatelly with default
mcr1 value before writing reset bit.
On Fri, Jun 18, 2021 at 4:56 PM Andrius V <vezhlys@gmail.com> wrote:
>
> Hi,
>
> I would probably recommend to close this bug for now and consider my
> hardware being faulty until proved differently. Just tested the same
> functionality in Linux driver, and it appeared to have the same issue
> after reset command, that every second register stops reporting its
> actual value. The controller still worked in Linux only for the reason
> that solely BMSR value was used to bring the interface up, and this
> register still works properly after reset. More recent Linux kernels
> (>5.3) started using BMCR register too, thus R6040 fails to work in
> the same manner as in BSDs. I found at least one dmesg report
> (https://dmesgd.nycbug.org/index.cgi?do=view&id=2524) with the same
> 0x0005 PHY model (different SoC though: EX instead DX3), which was
> reporting oui value correctly, indicating that it did not suffer from
> vte_reset the issue as in my device. So, it does not seem to be PHY
> model related behaviour either. Maybe it is SoC related but it's
> impossible to know without having another device. I would suspect that
> it is more likely to be my unit issue (whatever is the reason).
>
> Unrelated to my bug report, but Linux seemingly has an opposite check here:
>
>
>
> On Thu, Jan 30, 2020 at 11:45 PM Andrius V <vezhlys@gmail.com> wrote:
> >
> > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > Cc:
> > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > Date: Thu, 30 Jan 2020 23:40:10 +0200
> >
> > On the probably the last attempt to move forward, I tried different
> > ways to put link down (mii_down, setting link down, etc), even
> > completely deattaching/attaching rdcphy before/after reset. Despite
> > all the attempts, the outcome is the same: phy stops working properly
> > (every second register fails to operate, phy OUI value changes to
> > 0xfcff2f). Seems like MAC reset command just somehow messes it up
> > internally no matter what. Due to different reasons, I could not build
> > custom working Linux kernel on the system, so it is hard to tell how
> > Linux avoids reset problem, despite seemingly having the same code.
> > mii-tool fails to get any info about PHY, including OUI value, so I
> > can't compare it. Maybe, the Linux forces the link somehow, similarly
> > to what I did in initial workaround (just by forcefully setting
> > IFM_100_TX and ignoring bcmr and status register values), maybe reset
> > somehow works there properly. I can only guess. DHCP failure to get IP
> > address on ACPI is likely unrelated/separate issue (maybe related to
> > the USB failure on ACPI), since link still establishes properly. I
> > tested and confirmed that same workaround (removing vte_reset calls)
> > works on FreeBSD 12.0, including ACPI/SMP boot (FreeBSD doesn't have
> > USB issues on ACPI/SMP as well). On OpenBSD it also helps to set media
> > type properly but similarly to ACPI boot in NetBSD, DHCP fails to
> > assign IP address. Besides these findings, I exhausted all the other
> > testing options. Since I have only one system, it's hard to tell if it
> > is phy model issue, system one or just something else I missed to
> > notice. Nevertheless it may be worth to add new phy model into
> > miidevs, in case some systems behave differently (and possibly
> > renaming RDC to xxRDC, since OUI value is not correct in NetBSD
> > (0x00d02d instead of official 0x000bb4 value)):
> >
> > diff --git a/sys/dev/mii/miidevs b/sys/dev/mii/miidevs
> > index 4554ced3982..0ab52a75a2b 100644
> > --- a/sys/dev/mii/miidevs
> > +++ b/sys/dev/mii/miidevs
> > @@ -362,6 +362,7 @@ model xxQUALSEMI QS6612 0x0000 QS6612
> > 10/100 media interface
> >
> > /* RDC Semiconductor PHYs */
> > model RDC R6040 0x0003 R6040 10/100 media interface
> > +model RDC R6040_2 0x0005 R6040 10/100 media interface
> >
> > --- a/sys/dev/mii/rdcphy.c
> > +++ b/sys/dev/mii/rdcphy.c
> > @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs = {
> >
> > static const struct mii_phydesc rdcphys[] = {
> > MII_PHY_DESC(RDC, R6040),
> > + MII_PHY_DESC(RDC, R6040_2),
> > MII_PHY_END,
> > };
> >
> > Regards,
> > Andrius V
> >
> > On Mon, Jan 13, 2020 at 2:55 PM Andrius V <vezhlys@gmail.com> wrote:
> > >
> > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > Cc:
> > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > Date: Mon, 13 Jan 2020 14:52:06 +0200
> > >
> > > Finally, I found some more clear clue on the failure - the main
> > > culprit for failed link establishment and not properly working PHY
> > > registers is mac reset (vte_reset code). It even distorts
> > > functionality to the point that OUI becomes different. Removing
> > > vte_reset from vte_attach changes OUI from 0xfcff2f back to 0x00d02d
> > > which is the same value as currently defined for RDC in
> > > miidevs.Commenting out all vte_reset calls keeps all PHY registers
> > > functional in all operations (and with some additional tweaks vte
> > > works quite well for me, while booted without ACPI/SMP; on ACPI still
> > > fails somewhere). Since Linux reset code is the same (I think they
> > > have a bug in waiting loop but it doesn't change functionality), I
> > > believe vte_reset should work though, but it should be used only on
> > > vte_init and vte_stop. However, I don't know yet, why this behavior is
> > > not elevated in Linux. Maybe, this Linux commit can be a culprit since
> > > NetBSD lacks this code:
> > > https://github.com/torvalds/linux/commit/06e92c33999fd66128c2256b0461455633c3d53c
> > > but I am not sure what is the counterpart of phy_start/stop in NetBSD
> > > to test? Is it ifmedia_init/ifmedia_set, or reattachment of PHY in
> > > general?
> > >
> > > It is not the only issue to make a fully work vte interface but
> > > vte_reset is certainly the main reason for PHY misbehavior. I think
> > > other issues may be easier to fix, since I already have working
> > > controller (at least on non ACPI/SMP boot) just need to pinpoint which
> > > of my changes were necessary (the latest comparison can be found in my
> > > github: https://github.com/vezhlys/netbsd-src/compare/master...vezhlys:vte#files_bucket).
> > > Any help appreciated. Thanks.
> > >
> > > Regards,
> > > Andrius V
> > >
> > >
> > > On Mon, Dec 23, 2019 at 2:50 PM Andrius V <vezhlys@gmail.com> wrote:
> > > >
> > > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > > >
> > > > From: Andrius V <vezhlys@gmail.com>
> > > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > > Cc:
> > > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > > Date: Mon, 23 Dec 2019 14:48:10 +0200
> > > >
> > > > Hi,
> > > >
> > > > There's a weird pattern which may give some clue to the issue: it
> > > > seems like every second PHY register fails to be read
> > > > (vte_miibus_readreg). Registers with the odd number (1,3,5, etc)
> > > > return some "proper" non zero value or zero. Every even address
> > > > (0,2,4, etc) return 0xFFFF though. Any idea why it may be happening?
> > > >
> > > > On Fri, Oct 25, 2019 at 7:20 PM Andrius V <vezhlys@gmail.com> wrote:
> > > > >
> > > > > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> > > > >
> > > > > From: Andrius V <vezhlys@gmail.com>
> > > > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > > > > Cc: Masanobu SAITOH <msaitoh@execsw.org>
> > > > > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > > > > Date: Fri, 25 Oct 2019 19:16:35 +0300
> > > > >
> > > > > Hi,
> > > > >
> > > > > I did some debugging on this issue. Seemingly the problem lies on
> > > > > ability to get MII_BMCR and MII_RDCPHY_STATUS values (in
> > > > > rdcphy_status). They both return 0xffff value which I believe
> > > > > indicates some incorrect result. MII_BMSR has 0x782d value though.
> > > > >
> > > > > In case, if I ignore BMCR checks and put mii->mii_media_active |=3D
> > > > > IFM_100_TX; by default, controller starts to work successfully (media
> > > > > is attached, IP is getting assigned and it can connect to network), so
> > > > > the hardware is OK by itself. Since the code is pretty much similar to
> > > > > many other phys, I fail to understand the reason behind this issue, I
> > > > > guess it may be some initialization issues in if_vte driver, but I
> > > > > tried to compare it to Linux r6040 driver and I didn't find anything
> > > > > radically different from NetBSD. Ideas where I can still check or what
> > > > > can be potential reasons are really welcome. Thank you.
> > > > >
> > > > > ifconfig of working vte0:
> > > > > vte0: flags=3D0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > > > ec_capabilities=3D1<VLAN_MTU>
> > > > > ec_enabled=3D0
> > > > > address: xx:xx:xx:xx:xx:xx
> > > > > media: Ethernet autoselect (100baseTX)
> > > > > status: active
> > > > > inet 192.168.1.21/24 broadcast 192.168.1.255 flags 0x1<TENTATIVE>
> > > > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > > > >
> > > > > Workaround diff (xxRDC defines new OUI):
> > > > >
> > > > > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> > > > > index 427744a958d..20392efda70 100644
> > > > > --- a/sys/dev/mii/rdcphy.c
> > > > > +++ b/sys/dev/mii/rdcphy.c
> > > > > @@ -75,6 +75,7 @@ static const struct mii_phy_funcs rdcphy_funcs =3D {
> > > > >
> > > > > static const struct mii_phydesc rdcphys[] =3D {
> > > > > MII_PHY_DESC(RDC, R6040),
> > > > > + MII_PHY_DESC(xxRDC, R6040),
> > > > > MII_PHY_END,
> > > > > };
> > > > >
> > > > > @@ -188,7 +189,6 @@ rdcphy_service(struct mii_softc *sc, struct
> > > > > mii_data *mii, int cmd)
> > > > > }
> > > > > break;
> > > > > }
> > > > > -
> > > > > /* Update the media status. */
> > > > > rdcphy_status(sc);
> > > > >
> > > > > @@ -214,6 +214,8 @@ rdcphy_status(struct mii_softc *sc)
> > > > > mii->mii_media_status |=3D IFM_ACTIVE;
> > > > >
> > > > > PHY_READ(sc, MII_BMCR, &bmcr);
> > > > > +
> > > > > + /*
> > > > > if ((bmcr & BMCR_ISO) !=3D 0) {
> > > > > mii->mii_media_active |=3D IFM_NONE;
> > > > > mii->mii_media_status =3D 0;
> > > > > @@ -222,6 +224,7 @@ rdcphy_status(struct mii_softc *sc)
> > > > >
> > > > > if ((bmcr & BMCR_LOOP) !=3D 0)
> > > > > mii->mii_media_active |=3D IFM_LOOP;
> > > > > + */
> > > > >
> > > > > if ((bmcr & BMCR_AUTOEN) !=3D 0) {
> > > > > if ((bmsr & BMSR_ACOMP) =3D=3D 0) {
> > > > > @@ -239,7 +242,7 @@ rdcphy_status(struct mii_softc *sc)
> > > > > mii->mii_media_active |=3D IFM_10_T;
> > > > > break;
> > > > > default:
> > > > > - mii->mii_media_active |=3D IFM_NONE;
> > > > > + mii->mii_media_active |=3D IFM_100_TX;
> > > > > return;
> > > > > }
> > > > > if ((physts & STATUS_FULL_DUPLEX) !=3D 0)
> > > > >
> > > > > On Fri, Aug 3, 2018 at 12:05 AM <vezhlys@gmail.com> wrote:
> > > > > >
> > > > > > >Number: 53494
> > > > > > >Category: port-i386
> > > > > > >Synopsis: vte doesn't work on eBox 3352DX3-AP
> > > > > > >Confidential: no
> > > > > > >Severity: serious
> > > > > > >Priority: low
> > > > > > >Responsible: port-i386-maintainer
> > > > > > >State: open
> > > > > > >Class: sw-bug
> > > > > > >Submitter-Id: net
> > > > > > >Arrival-Date: Thu Aug 02 21:05:00 +0000 2018
> > > > > > >Originator: Andrius V
> > > > > > >Release: current
> > > > > > >Organization:
> > > > > > >Environment:
> > > > > > NetBSD vertexpc 8.99.22 NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 =
> > > > > UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
> > > > > i386
> > > > > > >Description:
> > > > > > Hello,
> > > > > >
> > > > > > I recently received eBox 3352DX3-AP system which is based on VortexDX3 CP=
> > > > > U. I am facing an issue with R6040 Ethernet controller on it. It can't set =
> > > > > a media type (even if I am trying to set supported one manually) and it doe=
> > > > > sn't have any status value, dhcpcd sets some incorrect IP and I can't acces=
> > > > > s the network. ifconfig vte0:
> > > > > > vte0: flags=3D0x8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> m=
> > > > > tu 1500
> > > > > > ec_capabilities=3D1<VLAN_MTU>
> > > > > > ec_enabled=3D0
> > > > > > address: xx:xx:xx:xx:xx:xx
> > > > > > media: Ethernet autoselect (none)
> > > > > > inet 169.254.69.13/16 broadcast 169.254.255.255 flags 0x0
> > > > > > inet6 fe80::7257:8bd0:b0fa:afc0%vte0/64 flags 0x0 scopeid 0x1
> > > > > >
> > > > > > General phy attaches to it (not a rdcphy) because it has different OUI an=
> > > > > d model. But even if I would register new OUI and model to rdcphy, it would=
> > > > > n't change the behavior.
> > > > > >
> > > > > > I am booting system without ACPI and SMP (it fails to boot with those bec=
> > > > > ause of other issue I still need to report). I tried controller on FreeBSD =
> > > > > and Linux as well. FreeBSD seems to have the same issue, Linux works though=
> > > > > . Please see dmesg below (there is also USB D-Link network card attached, i=
> > > > > t works):
> > > > > > NetBSD 8.99.22 (GENERIC) #0: Fri Jul 27 16:12:40 UTC 2018
> > > > > > mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > > > > total memory =3D 1983 MB
> > > > > > avail memory =3D 1930 MB
> > > > > > rnd: seeded with 128 bits
> > > > > > timecounter: Timecounters tick every 10.000 msec
> > > > > > Kernelized RAIDframe activated
> > > > > > running cgd selftest aes-xts-256 aes-xts-512 done
> > > > > > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> > > > > > RDC Semiconductor Co., Ltd. EMKORE (1.0 =
> > > > > )
> > > > > > mainbus0 (root)
> > > > > > cpu0 at mainbus0
> > > > > > cpu0: Vortex86DX3, id 0x611
> > > > > > cpu0: package 0, core 0, smt 0
> > > > > > 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: vendor 17f3 product 6023 (rev. 0x02)
> > > > > > ppb0 at pci0 dev 1 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > > > ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > > > .5GT/s
> > > > > > pci1 at ppb0 bus 1
> > > > > > pci1: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > > > ppb1 at pci0 dev 2 function 0: vendor 17f3 product 1031 (rev. 0x01)
> > > > > > ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2=
> > > > > .5GT/s
> > > > > > pci2 at ppb1 bus 2
> > > > > > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> > > > > > pcib0 at pci0 dev 7 function 0: vendor 17f3 product 6035 (rev. 0x01)
> > > > > > pcib1 at pci0 dev 7 function 1: vendor 17f3 product 6035 (rev. 0x01)
> > > > > > vte0 at pci0 dev 8 function 0: vendor 17f3 product 6040 (rev. 0x00)
> > > > > > vte0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > > > vte0: interrupting at irq 5
> > > > > > ukphy0 at vte0 phy 1: OUI 0xfcff2f, model 0x0005, rev. 0
> > > > > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > > > > > ohci0 at pci0 dev 10 function 0: vendor 17f3 product 6060 (rev. 0x14)
> > > > > > ohci0: interrupting at irq 14
> > > > > > ohci0: OHCI version 1.0, legacy support
> > > > > > usb0 at ohci0: USB revision 1.0
> > > > > > ehci0 at pci0 dev 10 function 1: vendor 17f3 product 6061 (rev. 0x08)
> > > > > > ehci0: interrupting at irq 7
> > > > > > ehci0: BIOS has given up ownership
> > > > > > ehci0: EHCI version 1.0
> > > > > > ehci0: 1 companion controller, 4 ports: ohci0
> > > > > > usb1 at ehci0: USB revision 2.0
> > > > > > rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x02)
> > > > > > rdcide0: bus-master DMA support present
> > > > > > rdcide0: primary channel configured to native-PCI mode
> > > > > > rdcide0: using irq 15 for native-PCI interrupt
> > > > > > atabus0 at rdcide0 channel 0
> > > > > > rdcide0: secondary channel configured to native-PCI mode
> > > > > > rdcide0: secondary channel ignored (disabled)
> > > > > > vga0 at pci0 dev 13 function 0: vendor 17f3 product 2015 (rev. 0x00)
> > > > > > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
> > > > > > wsmux1: connecting to wsdisplay0
> > > > > > drm at vga0 not configured
> > > > > > hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
> > > > > > hdaudio0: interrupting at irq 14
> > > > > > hdafg0 at hdaudio0: vendor 10ec product 0262
> > > > > > hdafg0: DAC00 2ch: Speaker [Jack]
> > > > > > hdafg0: DIG01 2ch: Digital Out [Jack]
> > > > > > hdafg0: ADC02 2ch: Mic In [Jack]
> > > > > > hdafg0: ADC03 2ch: Line In [Jack]
> > > > > > hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
> > > > > > audio0 at hdafg0: full duplex, playback, capture, mmap, independent
> > > > > > hdafg0: Virtual format configured - Format SLINEAR, precision 16, channel=
> > > > > s 2, frequency 48000
> > > > > > hdafg0: Latency: 128 milliseconds
> > > > > > isa0 at pcib0
> > > > > > pckbc0 at isa0 port 0x60-0x64
> > > > > > attimer0 at isa0 port 0x40-0x43
> > > > > > pcppi0 at isa0 port 0x61
> > > > > > midi0 at pcppi0: PC speaker
> > > > > > sysbeep0 at pcppi0
> > > > > > attimer0: attached to pcppi0
> > > > > > isa at pcib1 not configured
> > > > > > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> > > > > > uhub0 at usb0: NetBSD (0000) OHCI root hub (0000), class 9/0, rev 1.00/1.=
> > > > > 00, addr 1
> > > > > > uhub0: 4 ports with 4 removable, self powered
> > > > > > uhub1 at usb1: NetBSD (0000) EHCI root hub (0000), class 9/0, rev 2.00/1.=
> > > > > 00, addr 1
> > > > > > uhub1: 4 ports with 4 removable, self powered
> > > > > > IPsec: Initialized Security Association Processing.
> > > > > > axen0 at uhub1 port 1
> > > > > > axen0: D-Link Elec. Corp. (0x2001) D-Link DUB-1312 (0x4a00), rev 2.10/1.0=
> > > > > 0, addr 2
> > > > > > axen0: AX88179
> > > > > > axen0: Ethernet address xx:xx:xx:xx:xx:xx
> > > > > > rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 1000BASE-T media interface, r=
> > > > > ev. 5
> > > > > > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, a=
> > > > > uto
> > > > > > ehci0: handing over low speed device on port 3 to ohci0
> > > > > > wd0 at atabus0 drive 0
> > > > > > wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
> > > > > > wd0: drive supports 1-sector PIO transfers, LBA addressing
> > > > > > wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sect=
> > > > > ors
> > > > > > wd0: 32-bit data port
> > > > > > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
> > > > > > wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/1=
> > > > > 00) (using DMA)
> > > > > > boot device: wd0
> > > > > > root on wd0a dumps on wd0b
> > > > > > root file system type: ffs
> > > > > > kern.module.path=3D/stand/i386/8.99.22/modules
> > > > > > uhidev0 at uhub0 port 3 configuration 1 interface 0
> > > > > > uhidev0: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > > > 3/1
> > > > > > ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
> > > > > > wskbd0 at ukbd0: console keyboard, using wsdisplay0
> > > > > > uhidev1 at uhub0 port 3 configuration 1 interface 1
> > > > > > uhidev1: USB (0x1c4f) USB Keykoard (0x02), rev 1.10/1.10, addr 2, iclass =
> > > > > 3/0
> > > > > > uhidev1: 2 report ids
> > > > > > uhid0 at uhidev1 reportid 1: input=3D2, output=3D0, feature=3D0
> > > > > > uhid1 at uhidev1 reportid 2: input=3D1, output=3D0, feature=3D0
> > > > > > wsdisplay0: screen 1 added (80x25, vt100 emulation)
> > > > > > wsdisplay0: screen 2 added (80x25, vt100 emulation)
> > > > > > wsdisplay0: screen 3 added (80x25, vt100 emulation)
> > > > > > wsdisplay0: screen 4 added (80x25, vt100 emulation)
> > > > > >
> > > > > > >How-To-Repeat:
> > > > > > Boot system and run dhcpcd client for vte0.
> > > > > > >Fix:
> > > > > >
> > > > >
> > > >
> > >
> >
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Fri, 18 Jun 2021 16:33:32 +0000
On Fri, Jun 18, 2021 at 02:00:02PM +0000, Andrius V wrote:
> I would probably recommend to close this bug for now and consider my
> hardware being faulty until proved differently.
> [...]
If it's possible to make it work by using only the one register, is it
worth adding a code path for that and treating it as a quirk? (maybe
only selectable explicitly unless/until we figure out how to probe it)
I haven't looked at the code and know nothing about the hw, so I have
no idea how hard or how invasive that would be, but it's a possible
way forward if you want your hw working and want to spend the time.
--
David A. Holland
dholland@netbsd.org
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Sat, 19 Jun 2021 01:07:17 +0300
Though possible I guess by skipping all bmcr checks in rdcphy_status,
if it's value equals to 0xffff, I doubt it's worth an effort. Since
status register also doesn't work, I am not sure how Linux was setting
the speed/duplex, but I believe by BMSR advertised capabilities and
putting the best possible option, which would mean we would also need
just to force 100baseTX full duplex. I would imagine patch similar to
this (untested):
diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
index 613d945bc09..6aaadd9f604 100644
--- a/sys/dev/mii/rdcphy.c
+++ b/sys/dev/mii/rdcphy.c
@@ -218,6 +218,11 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_status |= IFM_ACTIVE;
PHY_READ(sc, MII_BMCR, &bmcr);
+
+ if (bmcr == 0xffff && physts == 0xffff) {
+ goto broken_reset;
+ }
+
if ((bmcr & BMCR_ISO) != 0) {
mii->mii_media_active |= IFM_NONE;
mii->mii_media_status = 0;
@@ -250,4 +255,15 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
else
mii->mii_media_active |= IFM_HDX;
+ return;
+
+ broken_reset:
+ if ((bmsr & BMSR_ACOMP) == 0) {
+ /* Erg, still trying, I guess... */
+ mii->mii_media_active |= IFM_NONE;
+ return;
+ }
+ mii->mii_media_status |= IFM_ACTIVE;
+ mii->mii_media_active |= IFM_100_TX;
+ mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
However, I have an easier solution myself by just commenting out all
vte_reset calls, which cause the issue. It makes Ethernet controller
to initialize and work without visible issues. Thus, unless someone
else hits the same problem, I don't think so, that specific quirk is
necessary in the code.
Regards,
Andrius V
On Fri, Jun 18, 2021 at 7:35 PM David Holland <dholland-bugs@netbsd.org> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: David Holland <dholland-bugs@netbsd.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Fri, 18 Jun 2021 16:33:32 +0000
>
> On Fri, Jun 18, 2021 at 02:00:02PM +0000, Andrius V wrote:
> > I would probably recommend to close this bug for now and consider my
> > hardware being faulty until proved differently.
> > [...]
>
> If it's possible to make it work by using only the one register, is it
> worth adding a code path for that and treating it as a quirk? (maybe
> only selectable explicitly unless/until we figure out how to probe it)
>
> I haven't looked at the code and know nothing about the hw, so I have
> no idea how hard or how invasive that would be, but it's a possible
> way forward if you want your hw working and want to spend the time.
>
> --
> David A. Holland
> dholland@netbsd.org
>
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, dholland-bugs@netbsd.org
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Sat, 19 Jun 2021 23:27:42 +0300
Above patch would work only if rdcphy is attached, but since one of
two ID registers fails to report correct value, oui becomes invalid
(0xfcff2f) and generic driver (ukphy) is attached instead. So, either
rdcphy_match should be changed to check just part of ID as well or
broken OUI added to miidevs. The quick patch below would make vte work
on my device with some limitations like media type should not be
changed after. If it looks reasonable to apply, I can cleanup and
prepare a better one. However, I believe it just easier to consider my
device broken and close the PR. In case I would somehow find a way to
restore functionality programmatically (quite unlikely), I would
create a patch for that.
diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
index 613d945bc09..d5bb0e59daf 100644
--- a/sys/dev/mii/rdcphy.c
+++ b/sys/dev/mii/rdcphy.c
@@ -76,6 +76,7 @@ static const struct mii_phy_funcs rdcphy_funcs = {
static const struct mii_phydesc rdcphys[] = {
MII_PHY_DESC(xxRDC, R6040),
MII_PHY_DESC(xxRDC, R6040_2),
+ {0xfcff2f, 0x0005, "R6040 10/100 media interface - invalid OUI"},
MII_PHY_DESC(xxRDC, R6040_3),
MII_PHY_END,
};
@@ -218,6 +219,11 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_status |= IFM_ACTIVE;
PHY_READ(sc, MII_BMCR, &bmcr);
+
+ if ((bmcr & 0xffff) && (physts & 0xffff)) {
+ goto broken_reset;
+ }
+
if ((bmcr & BMCR_ISO) != 0) {
mii->mii_media_active |= IFM_NONE;
mii->mii_media_status = 0;
@@ -250,4 +256,15 @@ rdcphy_status(struct mii_softc *sc)
mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
else
mii->mii_media_active |= IFM_HDX;
+
+ return;
+
+ broken_reset:
+ if ((bmsr & BMSR_ACOMP) == 0) {
+ mii->mii_media_active |= IFM_NONE;
+ return;
+ }
+ mii->mii_media_status |= IFM_ACTIVE;
+ mii->mii_media_active |= IFM_100_TX;
+ mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
}
On Sat, Jun 19, 2021 at 1:07 AM Andrius V <vezhlys@gmail.com> wrote:
>
> Though possible I guess by skipping all bmcr checks in rdcphy_status,
> if it's value equals to 0xffff, I doubt it's worth an effort. Since
> status register also doesn't work, I am not sure how Linux was setting
> the speed/duplex, but I believe by BMSR advertised capabilities and
> putting the best possible option, which would mean we would also need
> just to force 100baseTX full duplex. I would imagine patch similar to
> this (untested):
>
> diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c
> index 613d945bc09..6aaadd9f604 100644
> --- a/sys/dev/mii/rdcphy.c
> +++ b/sys/dev/mii/rdcphy.c
> @@ -218,6 +218,11 @@ rdcphy_status(struct mii_softc *sc)
> mii->mii_media_status |= IFM_ACTIVE;
>
> PHY_READ(sc, MII_BMCR, &bmcr);
> +
> + if (bmcr == 0xffff && physts == 0xffff) {
> + goto broken_reset;
> + }
> +
> if ((bmcr & BMCR_ISO) != 0) {
> mii->mii_media_active |= IFM_NONE;
> mii->mii_media_status = 0;
> @@ -250,4 +255,15 @@ rdcphy_status(struct mii_softc *sc)
> mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
> else
> mii->mii_media_active |= IFM_HDX;
> + return;
> +
> + broken_reset:
> + if ((bmsr & BMSR_ACOMP) == 0) {
> + /* Erg, still trying, I guess... */
> + mii->mii_media_active |= IFM_NONE;
> + return;
> + }
> + mii->mii_media_status |= IFM_ACTIVE;
> + mii->mii_media_active |= IFM_100_TX;
> + mii->mii_media_active |= IFM_FDX | mii_phy_flowstatus(sc);
>
> However, I have an easier solution myself by just commenting out all
> vte_reset calls, which cause the issue. It makes Ethernet controller
> to initialize and work without visible issues. Thus, unless someone
> else hits the same problem, I don't think so, that specific quirk is
> necessary in the code.
>
> Regards,
> Andrius V
>
> On Fri, Jun 18, 2021 at 7:35 PM David Holland <dholland-bugs@netbsd.org> wrote:
> >
> > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
> >
> > From: David Holland <dholland-bugs@netbsd.org>
> > To: gnats-bugs@netbsd.org
> > Cc:
> > Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> > Date: Fri, 18 Jun 2021 16:33:32 +0000
> >
> > On Fri, Jun 18, 2021 at 02:00:02PM +0000, Andrius V wrote:
> > > I would probably recommend to close this bug for now and consider my
> > > hardware being faulty until proved differently.
> > > [...]
> >
> > If it's possible to make it work by using only the one register, is it
> > worth adding a code path for that and treating it as a quirk? (maybe
> > only selectable explicitly unless/until we figure out how to probe it)
> >
> > I haven't looked at the code and know nothing about the hw, so I have
> > no idea how hard or how invasive that would be, but it's a possible
> > way forward if you want your hw working and want to spend the time.
> >
> > --
> > David A. Holland
> > dholland@netbsd.org
> >
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, vezhlys@gmail.com
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Sat, 19 Jun 2021 20:39:51 +0000
On Sat, Jun 19, 2021 at 08:30:03PM +0000, Andrius V wrote:
> However, I believe it just easier to consider my
> device broken and close the PR. In case I would somehow find a way to
> restore functionality programmatically (quite unlikely), I would
> create a patch for that.
Well, it's your device. I guess I'll close the PR but feel free to
revisit it if you choose :-)
--
David A. Holland
dholland@netbsd.org
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 19 Jun 2021 20:42:45 +0000
State-Changed-Why:
hw is broken, conclusion for now at least is to not try to work around it
State-Changed-From-To: closed->open
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Sat, 28 Aug 2021 22:05:15 +0000
State-Changed-Why:
reopening, not broken hw, have a patch.
Responsible-Changed-From-To: port-i386-maintainer->andvar@NetBSD.org
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Sat, 28 Aug 2021 22:06:03 +0000
Responsible-Changed-Why:
take
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
Date: Sun, 29 Aug 2021 02:10:38 +0300
I reopened the bug, since I finally found what was causing the issue
and it is not because of broken hardware. It appeared that after
vte_reset VTE_MDCSC (MDC speed control) register value is set to
default value 0x0030 instead of original 0x0068 value. This value
controls clock speed from MAC to PHY (per my understanding) which
explains why every second register fails to be read. Restoring value
to original after reset solves the issue. Though for most this value
is apparently default (including my own DX2, EX2 based systems), if
somebody else can also test the patch and confirm that your system is
not broken, it would be much appreciated. I tested my own systems,
they seem to work. For DX3 you may need to boot without ACPI/SMP
support (at least in my case).
Patch can be downloaded here:
https://ftp.netbsd.org/pub/NetBSD/misc/andvar/if_vte.c.diff
Index: sys/dev/pci/if_vte.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_vte.c,v
retrieving revision 1.31
diff -u -p -r1.31 if_vte.c
--- sys/dev/pci/if_vte.c 7 Feb 2020 00:04:28 -0000 1.31
+++ sys/dev/pci/if_vte.c 28 Aug 2021 22:19:40 -0000
@@ -1211,9 +1211,10 @@ vte_tick(void *arg)
static void
vte_reset(struct vte_softc *sc)
{
- uint16_t mcr;
+ uint16_t mcr, mdcsc;
int i;
+ mdcsc = CSR_READ_2(sc, VTE_MDCSC);
mcr = CSR_READ_2(sc, VTE_MCR1);
CSR_WRITE_2(sc, VTE_MCR1, mcr | MCR1_MAC_RESET);
for (i = VTE_RESET_TIMEOUT; i > 0; i--) {
@@ -1231,6 +1232,14 @@ vte_reset(struct vte_softc *sc)
CSR_WRITE_2(sc, VTE_MACSM, 0x0002);
CSR_WRITE_2(sc, VTE_MACSM, 0);
DELAY(5000);
+
+ /*
+ * On some SoCs (like Vortex86DX3) MDC speed control register value needs
+ * to be restored to original value instead of default one, otherwise
+ * some PHY registers may fail to be read.
+ */
+ if (mdcsc != MDCSC_DEFAULT)
+ CSR_WRITE_2(sc, VTE_MDCSC, mdcsc);
}
Regards,
Andrius V
On Sat, Jun 19, 2021 at 11:40 PM David Holland <dholland-bugs@netbsd.org> wrote:
>
> The following reply was made to PR port-i386/53494; it has been noted by GNATS.
>
> From: David Holland <dholland-bugs@netbsd.org>
> To: gnats-bugs@netbsd.org
> Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, vezhlys@gmail.com
> Subject: Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
> Date: Sat, 19 Jun 2021 20:39:51 +0000
>
> On Sat, Jun 19, 2021 at 08:30:03PM +0000, Andrius V wrote:
> > However, I believe it just easier to consider my
> > device broken and close the PR. In case I would somehow find a way to
> > restore functionality programmatically (quite unlikely), I would
> > create a patch for that.
>
> Well, it's your device. I guess I'll close the PR but feel free to
> revisit it if you choose :-)
>
> --
> David A. Holland
> dholland@netbsd.org
>
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53494 CVS commit: src/sys/dev/pci
Date: Mon, 30 Aug 2021 20:09:22 +0000
Module Name: src
Committed By: andvar
Date: Mon Aug 30 20:09:22 UTC 2021
Modified Files:
src/sys/dev/pci: if_vte.c
Log Message:
Restore original MDC speed control register value after MAC reset, if it wasn't default. Fixes PR port-i386/53494.
ok riastradh
To generate a diff of this commit:
cvs rdiff -u -r1.31 -r1.32 src/sys/dev/pci/if_vte.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->needs-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Mon, 30 Aug 2021 20:35:15 +0000
State-Changed-Why:
Needfs pukllups to -8 -9
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Mon, 30 Aug 2021 21:10:47 +0000
State-Changed-Why:
[pullup-8 #1693] and [pullup-9 #1339]
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53494 CVS commit: [netbsd-9] src/sys/dev/pci
Date: Fri, 3 Sep 2021 10:20:23 +0000
Module Name: src
Committed By: martin
Date: Fri Sep 3 10:20:22 UTC 2021
Modified Files:
src/sys/dev/pci [netbsd-9]: if_vte.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #1339):
sys/dev/pci/if_vte.c: revision 1.32
Restore original MDC speed control register value after MAC reset, if
it wasn't default. Fixes PR port-i386/53494.
ok riastradh
To generate a diff of this commit:
cvs rdiff -u -r1.26.2.1 -r1.26.2.2 src/sys/dev/pci/if_vte.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53494 CVS commit: [netbsd-8] src/sys/dev/pci
Date: Fri, 3 Sep 2021 10:23:18 +0000
Module Name: src
Committed By: martin
Date: Fri Sep 3 10:23:18 UTC 2021
Modified Files:
src/sys/dev/pci [netbsd-8]: if_vte.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #1693):
sys/dev/pci/if_vte.c: revision 1.32
Restore original MDC speed control register value after MAC reset, if
it wasn't default. Fixes PR port-i386/53494.
ok riastradh
To generate a diff of this commit:
cvs rdiff -u -r1.17.2.2 -r1.17.2.3 src/sys/dev/pci/if_vte.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Fri, 03 Sep 2021 20:40:34 +0000
State-Changed-Why:
Pullups completed. Thanks.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home