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:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 02 21:05:00 +0000 2018
>Last-Modified:  Thu Jan 30 21:45:01 +0000 2020
>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:

>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:
 >  >  >  >
 >  >  >
 >  >
 >

NetBSD Home
NetBSD PR Database Search

(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.