NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/53494: vte doesn't work on eBox 3352DX3-AP
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:
> > >
> >
>
Home |
Main Index |
Thread Index |
Old Index