Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-i386/53494; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
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@localhost> wrote:
 >
 > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
 >
 > From: Andrius V <vezhlys%gmail.com@localhost>
 > To: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >         netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
 > 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@localhost> wrote:
 >  >
 >  > The following reply was made to PR port-i386/53494; it has been noted by GNATS.
 >  >
 >  > From: Andrius V <vezhlys%gmail.com@localhost>
 >  > To: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >  >         netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
 >  > Cc: Masanobu SAITOH <msaitoh%execsw.org@localhost>
 >  > 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@localhost> 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@localhost:/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@localhost:/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:
 >  >  >
 >  >
 >