Hi Kevin, > Thanks for the analysis, I committed your diff.
Thank you for applying the patch! > For some reason, ethernet and usb devices never get interrupts, I have to > disable both acpimadt and mpbios in the kernel to make it work. > Does your machine also have this problem? Thanks. Yes, there are some problems with level type interrupts on Vortex86DX3 machines, which seems to be the same issue on OpenBSD and NetBSD (edge type interrupts work on the other hand like for storage or serial interface). FreeBSD 12.0 (the last one I managed to boot without modifications) and Linux doesn't seem to have this issue (unless it somehow ignored) and devices work without visible issues. I have registered it as https://gnats.netbsd.org/53894 on NetBSD for that and I did some investigation to find out the cause, unfortunately without success so far. Thus, neither USB, nor network (and probably audio) doesn't work if device interrupts established through APIC. In NetBSD it is possible to boot without acpi/smp mode in which it attaches devices in legacy way (pic), in this case USB and network works. I believe solving that would make system work properly. However, in OpenBSD case I also had crashes with the default kernel, where older versions (don't remember which) would work with DIAGNOSTIC option disabled, for current ones I was applying certain patches, like to comment out acpi_checksum in acpi_attach_common and "pretend" that hdr_revision is below 4 (however, I haven't updated my code to current yet). Regards, Andrius V On Tue, Apr 19, 2022 at 6:29 AM Kevin Lo <[email protected]> wrote: > > Hi Andrius, > > I finally have hardware (DMP EB-3360-C2CF) to verify your diff and confirm > that restoring VTE_MDCSC value to original after reset solves the link state > flapping issue. Also tested on my ebox-3300mx to ensure it's not broken. > > Thanks for the analysis, I committed your diff. > > For some reason, ethernet and usb devices never get interrupts, I have to > disable both acpimadt and mpbios in the kernel to make it work. > Does your machine also have this problem? Thanks. > > Here's my dmesg output: > > OpenBSD 7.1-current (GENERIC.MP) #2: Mon Apr 18 16:19:48 CST 2022 > kevlo@ebox-3360:/usr/src/sys/arch/i386/compile/GENERIC.MP > real mem = 1006059520 (959MB) > avail mem = 970870784 (925MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: date 08/15/18, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.7 @ > 0xf9c80 (43 entries) > bios0: vendor American Megatrends Inc. version "08.00.1" date 08/15/2018 > bios0: RDC Semiconductor Co., Ltd. A9126 > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S0 > acpi0: tables DSDT FACP APIC MSDM SLIC OEMB > acpi0: wakeup devices USB1(S0) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (P0P1) > acpiprt2 at acpi0: bus 2 (P0P2) > "PNP0A03" at acpi0 not configured > acpicmos0 at acpi0 > "PNP0501" at acpi0 not configured > "PNP0501" at acpi0 not configured > mpbios at bios0 function 0x0 not configured > bios0: ROM list: 0xc0000/0x8000 > cpu0 at mainbus0: (uniprocessor) > cpu0: Vortex86DX3 (686-class) 1.01 GHz, 06-01-01 > cpu0: FPU,PSE,TSC,MSR,CX8,APIC,SEP,PGE,CMOV,MMX,FXSR,SSE > pci0 at mainbus0 bus 0: configuration mode 1 (bios) > pchb0 at pci0 dev 0 function 0 "RDC R6023 Host" rev 0x02 > ppb0 at pci0 dev 1 function 0 "RDC R1031 PCIe" rev 0x01: irq 10 > pci1 at ppb0 bus 1 > ppb1 at pci0 dev 2 function 0 "RDC R1031 PCIe" rev 0x01: irq 11 > pci2 at ppb1 bus 2 > pcib0 at pci0 dev 7 function 0 "RDC R6035 ISA" rev 0x01 > pcib1 at pci0 dev 7 function 1 "RDC R6035 ISA" rev 0x01 > vte0 at pci0 dev 8 function 0 "RDC R6040 Ethernet" rev 0x00: irq 5, address > 00:1b:eb:xx:xx:xx > rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 0 > ohci0 at pci0 dev 10 function 0 "RDC R6060 USB" rev 0x14: irq 6, version 1.0, > legacy support > ehci0 at pci0 dev 10 function 1 "RDC R6061 USB2" rev 0x08: irq 10 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "RDC EHCI root hub" rev 2.00/1.00 > addr 1 > pciide0 at pci0 dev 12 function 0 "RDC R1012 IDE" rev 0x02: DMA, channel 0 > configured to compatibility, channel 1 configured to compatibility > pciide0: channel 0 disabled (no drives) > wd0 at pciide0 channel 1 drive 0: <SanDisk SD8SB8U128G1122> > wd0: 1-sector PIO, LBA48, 122104MB, 250069680 sectors > vga1 at pci0 dev 13 function 0 "RDC M2015 VGA" rev 0x00 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > azalia0 at pci0 dev 14 function 0 "RDC R3010 HDA" rev 0x01: irq 6 > azalia0: codecs: Realtek ALC262 > audio0 at azalia0 > isa0 at pcib0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 > isa at pcib1 not configured > usb1 at ohci0: USB revision 1.0 > uhub1 at usb1 configuration 1 interface 0 "RDC OHCI root hub" rev 1.00/1.00 > addr 1 > uhidev0 at uhub1 port 1 configuration 1 interface 0 "SEM USB Keyboard" rev > 1.10/1.10 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > wskbd1: connecting to wsdisplay0 > uhidev1 at uhub1 port 1 configuration 1 interface 1 "SEM USB Keyboard" rev > 1.10/1.10 addr 2 > uhidev1: iclass 3/0, 2 report ids > ucc0 at uhidev1 reportid 1: 573 usages, 18 keys, array > wskbd2 at ucc0 mux 1 > wskbd2: connecting to wsdisplay0 > uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0 > vscsi0 at root > scsibus1 at vscsi0: 256 targets > softraid0 at root > scsibus2 at softraid0: 256 targets > root on wd0a (01024b6ca36ae6e9.a) swap on wd0b dump on wd0b > > > On Wed, Mar 23, 2022 at 10:09:49PM +0200, Andrius V wrote: > > Hello, > > > > I would like one more time to ask to apply the patch regarding vte(4) > > driver and rdcphy(4). As I mentioned on submitting patches, I added > > two additional rdcphy models for recognition (used in different > > Vortex86 SoCs) and applied MDC speed control register restore on > > vte_reset, which is needed for at least Vortex86DX3 machines (since > > reset changes register value to MDCSC_DEFAULT value, which may not be > > the original value, thus causing some phy registers read failures). > > Attaching updated patch for current sources. Thank you! > > > > Regards, > > Andrius V > > > > On Fri, Dec 10, 2021 at 12:21 AM Andrius V <[email protected]> wrote: > > > > > > Hi, > > > > > > I would like to follow up on submitted patch, is there any concern on > > > applying it for vte(4) driver (as well as adding new PHY models to > > > rdcphy(4): https://marc.info/?l=openbsd-bugs&m=163105121012387&w=2 to > > > rdcphy)? It would be helpful for me to avoid patching it manually. > > > Thank you. > > > > > > Regards, > > > Andrius V > > > > > > > > > > > > > > > On Mon, Sep 13, 2021 at 1:42 PM Andrius V <[email protected]> wrote: > > > > > > > > Hi, > > > > > > > > On some Vortex86 SoCs MDC speed control register needs to be restored > > > > to original value after MAC reset. This issue happens if MAC has non > > > > default VTE_MDCSC register value before reset, and it is erroneously > > > > set to default after, thus causing certain PHY registers fail to be > > > > read. Since PHY registers determine link status, the link is never > > > > established (ifconfig media shows "none" value). Also, one obvious > > > > sign is incorrect oui value in dmesg (0x3ffff4 instead of the one > > > > defined in MII_OUI_RDC). > > > > > > > > Initially, I found and fixed that in NetBSD, but it affects all BSDs > > > > and Linux. Patch is already applied on NetBSD > > > > (http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_vte.c.diff?r1=1.31&r2=1.32) > > > > and Linux netdev branch > > > > (https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=e3f0cc1a945fcefec0c7c9d9dfd028a51daa1846). > > > > Sending the same patch for OpenBSD. For more info and my debugging > > > > history can be found in > > > > http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53494 > > > > thread. I tested the patch on my Vortex86DX3 (link is established/oui > > > > is correct), DX2 based machines on OpenBSD (but the patch itself was > > > > tested by few more people in NetBSD/Linux too). > > > > > > > > This patch is loosely related to my request to add new PHY models, but > > > > can be applied independently, since vte(4) works with generic PHY > > > > driver as well. > > > > > > > > --- > > > > Index: sys/dev/pci/if_vte.c > > > > =================================================================== > > > > RCS file: /cvs/src/sys/dev/pci/if_vte.c,v > > > > retrieving revision 1.24 > > > > diff -u -p -u -p -r1.24 if_vte.c > > > > --- sys/dev/pci/if_vte.c 10 Jul 2020 13:26:38 -0000 1.24 > > > > +++ sys/dev/pci/if_vte.c 13 Sep 2021 10:22:06 -0000 > > > > @@ -1084,9 +1084,10 @@ vte_tick(void *arg) > > > > void > > > > vte_reset(struct vte_softc *sc) > > > > { > > > > - uint16_t mcr; > > > > + uint16_t mcr, mdcsc; > > > > int i; > > > > > > > > + mdcsc = CSR_READ_2(sc, VTE_MDCSC); > > > > mcr = CSR_READ_2(sc, VTE_MCR1); > > > > CSR_WRITE_2(sc, VTE_MCR1, mcr | MCR1_MAC_RESET); > > > > for (i = VTE_RESET_TIMEOUT; i > 0; i--) { > > > > @@ -1105,6 +1106,14 @@ vte_reset(struct vte_softc *sc) > > > > CSR_WRITE_2(sc, VTE_MACSM, 0x0002); > > > > CSR_WRITE_2(sc, VTE_MACSM, 0); > > > > DELAY(5000); > > > > + > > > > + /* > > > > + * On some SoCs (like Vortex86DX3) MDC speed control register value > > > > + * needs to be restored to original value instead of default one, > > > > + * otherwise some PHY registers may fail to be read. > > > > + */ > > > > + if (mdcsc != MDCSC_DEFAULT) > > > > + CSR_WRITE_2(sc, VTE_MDCSC, mdcsc); > > > > } > > > > > > > > int > > > > ---- > > > > > > > > Regards, > > > > Andrius V > > > diff --git a/sys/dev/mii/miidevs b/sys/dev/mii/miidevs > > index e5a947029cf..4d8a9d87d04 100644 > > --- a/sys/dev/mii/miidevs > > +++ b/sys/dev/mii/miidevs > > @@ -288,6 +288,8 @@ model QUALITYSEMI QS6612 0x0000 QS6612 10/100 PHY > > > > /* RDC Semi. PHYs */ > > model RDC R6040 0x0003 R6040 10/100 PHY > > +model RDC R6040_2 0x0005 R6040 10/100 PHY > > +model RDC R6040_3 0x0006 R6040 10/100 PHY > > > > /* Realtek PHYs */ > > model xxREALTEK RTL8251 0x0000 RTL8251 PHY > > diff --git a/sys/dev/mii/rdcphy.c b/sys/dev/mii/rdcphy.c > > index cf7d75d57ef..aae049d6ca1 100644 > > --- a/sys/dev/mii/rdcphy.c > > +++ b/sys/dev/mii/rdcphy.c > > @@ -102,6 +102,10 @@ const struct mii_phy_funcs rdcphy_funcs = { > > static const struct mii_phydesc rdcphys[] = { > > { MII_OUI_RDC, MII_MODEL_RDC_R6040, > > MII_STR_RDC_R6040 }, > > + { MII_OUI_RDC, MII_MODEL_RDC_R6040_2, > > + MII_STR_RDC_R6040_2 }, > > + { MII_OUI_RDC, MII_MODEL_RDC_R6040_3, > > + MII_STR_RDC_R6040_3 }, > > { 0, 0, > > NULL }, > > }; > > diff --git a/sys/dev/pci/if_vte.c b/sys/dev/pci/if_vte.c > > index 3a32a246324..9de70c795df 100644 > > --- a/sys/dev/pci/if_vte.c > > +++ b/sys/dev/pci/if_vte.c > > @@ -1084,9 +1084,10 @@ vte_tick(void *arg) > > void > > vte_reset(struct vte_softc *sc) > > { > > - uint16_t mcr; > > + uint16_t mcr, mdcsc; > > int i; > > > > + mdcsc = CSR_READ_2(sc, VTE_MDCSC); > > mcr = CSR_READ_2(sc, VTE_MCR1); > > CSR_WRITE_2(sc, VTE_MCR1, mcr | MCR1_MAC_RESET); > > for (i = VTE_RESET_TIMEOUT; i > 0; i--) { > > @@ -1105,6 +1106,13 @@ vte_reset(struct vte_softc *sc) > > CSR_WRITE_2(sc, VTE_MACSM, 0x0002); > > CSR_WRITE_2(sc, VTE_MACSM, 0); > > DELAY(5000); > > + /* > > + * On some SoCs (like Vortex86DX3) MDC speed control register value > > + * needs to be restored to original value instead of default one, > > + * otherwise some PHY registers may fail to be read. > > + */ > > + if (mdcsc != MDCSC_DEFAULT) > > + CSR_WRITE_2(sc, VTE_MDCSC, mdcsc); > > } > > > > int >
