On Sun, Nov 19, 2017 at 03:09:38PM -0500, Eduard Nicodei wrote:
> >-------- Original Message --------
> >Subject: Re: sunxi/sxie.c: ~3KB/s TX speed (6.2 + uboot 17.03)
> >Local Time: November 14, 2017 12:07 AM
> >UTC Time: November 14, 2017 12:07 AM
> >From: artturi....@gmail.com
> >To: Eduard Nicodei <enico...@protonmail.com>
> >arm@openbsd.org
> >
> >On Mon, Nov 13, 2017 at 06:33:48PM -0500, Eduard Nicodei wrote:
> >>Hi,
> >>I've had same problem as Artturi
> >>(https://marc.info/?l=openbsd-bugs&m=150071170630651&w=2), but on a
> >>Olinuxino A10 Lime. After trying u-boot 17.03 I noticed that TX speeds
> >>were very slow (~3KB/s).
> >>Here is what the packets look like on the other machine (192.168.1.17):
> >>192.168.1.3.1484 > 192.168.1.17.30000: S 3400651399:3400651399(0) win 16384
> >> 192.168.1.17.30000 > 192.168.1.3.1484: S 2057093871:2057093871(0) ack
> >> 3400651400 win 28960
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . ack 1 win 256
> >> 0b:90:d0:de:44:1c 5f:bd:8a:25:ff:c6 69ef 118:
> >> e506 fdff 29fe dfef 0094 3fff 0894 ffee
> >> a0a9 f9ab 8446 dcf3 ba20 5c47 0249 f3de
> >> c90a d7d1 0028 9ef4 9381 8b69 7103 8ef4
> >> 6e68 f7
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 1:1449(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 249
> >> 0b:90:d0:de:44:1c 5f:bd:8a:25:ff:c6 69ef 1514:
> >> e506 fdff 29fe dfef 0094 3fff 0894 ffee
> >> a0a9 f9ab 8446 dcf3 ba20 5c47 0249 f3de
> >> c90a d7d1 0028 9ef4 9381 8b69 7103 8ef4
> >> 6e68 f7
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 1501:2949(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 272
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 4397:5845(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 295
> >>On the Olinuxino Lime (192.168.1.3) they look OK:
> >>192.168.1.3.1484 > 192.168.1.17.30000: S 3400651399:3400651399(0) win 16384
> >> 192.168.1.17.30000 > 192.168.1.3.1484: S 2057093871:2057093871(0) ack
> >> 3400651400 win 28960
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 1:1449(1448) ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: P 1449:1501(52) ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 1501:2949(1448) ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 2949:4397(1448) ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 4397:5845(1448) ack 1 win 256
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 5845:7293(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 249
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 7293:8741(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 272
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 8741:10189(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 295
> >> 192.168.1.3.1484 > 192.168.1.17.30000: . 10189:11637(1448) ack 1 win 256
> >> 192.168.1.17.30000 > 192.168.1.3.1484: . ack 1449 win 317
> >>I believe this might be caused by sxie driver using two TX FIFOs: I hacked
> >>a bit the kernel and when using only 1 TX FIFO it did not send any mangled
> >>frames (though packets were getting dropped by ifq_enqueue). I also added
> >>some counters to keep track which queue was being used and the numbers of
> >>mangled frames were close the number of times the second FIFO was used.
> >>I would like to investigate further, but I would like to know if this could
> >>be caused by the older u-boot or if it seems like an actual fault with the
> >>driver?
> >>Has anybody had good TX speed using sxie? I saw John DiMarco also reported
> >>a TX speed of about 4KB/s but that was over a year ago
> >>(https://marc.info/?l=openbsd-arm&m=147378434716041&w=2).
> >>I booted a debian image and it run at a few *MB/s so I'm pretty confident
> >>it's not a hw problem.
> >>Many Thanks,
> >> Eduard
> >>
> >I can get ip and even ssh in on -current and latest u-boot,
> > but yeah it's broken enough that i did shutdown my boards w/it,
> > i know it used to do way more IRQs too.
> > I don't know yet, nor really feel like it'd be worth my time to do
> > anything than install something else on it, but it might be related
> > that someone did fuckup the timers on it too, tick does around 66/update
> > in systat, and stattick barely 100.
> >
> > fwiw., i got some fixes commited to u-boot for sun4i_emac,
> > but otherwise it's unable to boot sd0a:/bsd w/bootarm.efi,
> > so still broken&useless, it will be(U-Boot 2017.11).
> >
> > -Artturi
> >>U-Boot SPL 2017.03 (Apr 03 2017 - 11:14:00)
> >> DRAM: 512 MiB
> >> CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
> >> Trying to boot from MMC1
> >>U-Boot 2017.03 (Apr 03 2017 - 11:14:00 -0600) Allwinner Technology
> >>CPU: Allwinner A10 (SUN4I)
> >> Model: Olimex A10-OLinuXino-LIME
> >> I2C: ready
> >> DRAM: 512 MiB
> >> MMC: SUNXI SD/MMC: 0
> >> *** Warning - bad CRC, using default environment
> >>In: serial
> >> Out: serial
> >> Err: serial
> >> SCSI: SATA link 0 timeout.
> >> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> >> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> >> Net: eth0: ethernet@01c0b000
> >> starting USB...
> >> USB0: USB EHCI 1.00
> >> USB1: USB OHCI 1.0
> >> USB2: USB EHCI 1.00
> >> USB3: USB OHCI 1.0
> >> scanning bus 0 for devices... 1 USB Device(s) found
> >> scanning bus 2 for devices... 1 USB Device(s) found
> >> scanning usb for storage devices... 0 Storage Device(s) found
> >> Hit any key to stop autoboot: 0
> >> switch to partitions #0, OK
> >> mmc0 is current device
> >> Scanning mmc 0:1...
> >> reading /sun4i-a10-olinuxino-lime.dtb
> >> 26581 bytes read in 30 ms (865.2 KiB/s)
> >> Found EFI removable media binary efi/boot/bootarm.efi
> >> reading efi/boot/bootarm.efi
> >> 67436 bytes read in 42 ms (1.5 MiB/s)
> >>Starting EFI application at 42000000 ...
> >>
> >>Scanning disks on scsi...
> >> Scanning disks on usb...
> >> Scanning disks on mmc...
> >> MMC Device 1 not found
> >> MMC Device 2 not found
> >> MMC Device 3 not found
> >> Found 6 disks
> >>>>OpenBSD/armv7 BOOTARM 1.0
> >>>> boot>
> >>>> booting sd0a:/bsd: 3935884+166328+562136
> >>>> [273417+90+522736+245831]=0x5785f4
> >>>>OpenBSD/armv7 booting ...
> >> arg0 0xc08785f4 arg1 0x0 arg2 0x48000000
> >> Allocating page tables
> >> freestart = 0x40879000, free_pages = 128903 (0x0001f787)
> >> IRQ stack: p0x408a7000 v0xc08a7000
> >> ABT stack: p0x408a8000 v0xc08a8000
> >> UND stack: p0x408a9000 v0xc08a9000
> >> SVC stack: p0x408aa000 v0xc08aa000
> >> Creating L1 page table at 0x4087c000
> >> Mapping kernel
> >> Constructing L2 page tables
> >> undefined page pmap [ using 1042532 bytes of bsd ELF symbol table ]
> >> board type: 0
> >> Copyright (c) 1982, 1986, 1989, 1991, 1993
> >> The Regents of the University of California. All rights reserved.
> >> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> >> https://www.OpenBSD.org
> >>OpenBSD 6.2-current (GENERIC) #122: Sat Nov 11 11:05:42 MST 2017
> >>dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
> >> real mem = 536870912 (512MB)
> >> avail mem = 517271552 (493MB)
> >> mainbus0 at root: Olimex A10-OLinuXino-LIME
> >> cpu0 at mainbus0: ARM Cortex-A8 r3p2 (ARMv7)
> >> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> >> cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
> >> sxiccmu0 at mainbus0
> >> simplebus0 at mainbus0: "soc"
> >> sxipio0 at simplebus0: 175 pins
> >> sxitimer0 at simplebus0: cntrtimer @ 24000KHz
> >> sxie0 at simplebus0, address 02:02:0a:81:e6:6c
> >> rlphy0 at sxie0 phy 1: RTL8201L 10/100 PHY, rev. 1
> >> sximmc0 at simplebus0
> >> sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
> >> ehci0 at simplebus0
> >>
>
>
> Thanks for the reply Artturi!
>
>
> You are right, I did not notice the tick/stattick values.
>
> Regarding sxie.c, I've gone ahead and yanked out the second TX FIFO, used
> ifq_restart in the ISR (as per example in ifq.h) and increased send queue max
> length from 1 to IFQ_MAXLEN. Now I'm getting a much more healthy 1MB/s TX
> and ~8MB/s RX, even when doing both.
>
> If anybody more knowlegable thinks it's worth it and would like to give some
> feedback on the diff, I would be more than happy to clean it up and submit to
> tech@. I agree though that giving up on the second TX FIFO might be just
> side-stepping the problem.
>
>
> Regards,
> Eduard
>
I gave your diff a spin, and there was no more garbage being sent,
but i think i ran into another bug, that i wasn't aware of.
As if there was something wrong with receiving&&||ARP too.
Could you run a test like this?:
1. reboot board with sxie
2. run some load on it (preferably causing traffic, distccd in my case)
3. let it idle enough, so that "$ arp -an" does show expired entrys on it
4. remove the arp entry for host w/sxie from one of those hosts with
expired entries on host/sxie
5. try to ping it from the host you did 4. on
for me it doesn't, but otherway around things work, and so does static
entries i had already forgotten about.. i used to run w/nothing but static
setups some years ago, now i prefer dhcpd.
diff (that doesn't really fix anything yet) below for the missing
sxie_miibus_statchg(), and in case you follow current,
there's diff you'll want on tech@ for emac.
-Artturi
diff --git a/sys/arch/armv7/sunxi/sxie.c b/sys/arch/armv7/sunxi/sxie.c
index db6d862aa34..9e92d50685a 100644
--- a/sys/arch/armv7/sunxi/sxie.c
+++ b/sys/arch/armv7/sunxi/sxie.c
@@ -717,19 +717,32 @@ sxie_miibus_writereg(struct device *dev, int phy, int
reg, int val)
void
sxie_miibus_statchg(struct device *dev)
{
- /* XXX */
-#if 0
struct sxie_softc *sc = (struct sxie_softc *)dev;
+ uint64_t mma = sc->sc_mii.mii_media_active;
+ uint64_t _valid = IFM_ACTIVE | IFM_AVALID;
+
+ if ((mma & _valid) != _valid)
+ return; /* no link */
- switch (IFM_SUBTYPE(sc->sc_mii.mii_media_active)) {
+ switch (IFM_SUBTYPE(mma)) {
case IFM_10_T:
+ SXICLR4(sc, SXIE_MACSUPP, 1 << 8);
+ break;
case IFM_100_TX:
- /*case IFM_1000_T: only on GMAC */
+ SXISET4(sc, SXIE_MACSUPP, 1 << 8);
break;
default:
break;
}
-#endif
+
+ if (mma & IFM_FLOW) {
+ SXICMS4(sc, SXIE_MACCR0, SXIE_MACTXFC | SXIE_MACRXFC,
+ (mma & IFM_ETH_TXPAUSE ? SXIE_MACTXFC : 0) |
+ (mma & IFM_ETH_RXPAUSE ? SXIE_MACRXFC : 0));
+ } else
+ SXICLR4(sc, SXIE_MACCR0, SXIE_MACTXFC | SXIE_MACRXFC);
+
+ SXICMS4(sc, SXIE_MACCR1, 1, mma & IFM_FDX ? 1 : 0);
}
int
>
> Index: sys/arch/armv7/sunxi/sxie.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/armv7/sunxi/sxie.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 sxie.c
> --- sys/arch/armv7/sunxi/sxie.c 22 Jan 2017 10:17:37 -0000 1.25
> +++ sys/arch/armv7/sunxi/sxie.c 19 Nov 2017 00:06:19 -0000
> @@ -97,7 +97,7 @@
> #define SXIE_MACA2 0x00a0
>
> /* i once spent hours on pretty defines, cvs up ate 'em. these shall do */
> -#define SXIE_INTR_ENABLE 0x010f
> +#define SXIE_INTR_ENABLE 0x010f
> #define SXIE_INTR_DISABLE 0x0000
> #define SXIE_INTR_CLEAR 0x0000
>
> @@ -106,7 +106,7 @@
>
> #define SXIE_RX_ENABLE 0x0004
> #define SXIE_TX_ENABLE 0x0003
> -#define SXIE_RXTX_ENABLE 0x0007
> +#define SXIE_RXTX_ENABLE 0x0007
>
> #define SXIE_RXDRQM 0x0002
> #define SXIE_RXTM 0x0004
> @@ -250,7 +250,7 @@ sxie_attach(struct device *parent, struc
> ifp->if_watchdog = sxie_watchdog;
> ifp->if_capabilities = IFCAP_VLAN_MTU; /* XXX status check in recv? */
>
> - IFQ_SET_MAXLEN(&ifp->if_snd, 1);
> + IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN);
>
> /* Initialize MII/media info. */
> mii = &sc->sc_mii;
> @@ -440,16 +440,10 @@ sxie_intr(void *arg)
>
> if (pending & (SXIE_TX_FIFO0 | SXIE_TX_FIFO1)) {
> ifq_clr_oactive(&ifp->if_snd);
> - sc->txf_inuse &= ~pending;
> - if (sc->txf_inuse == 0)
> - ifp->if_timer = 0;
> - else
> - ifp->if_timer = 5;
> + ifq_restart(&ifp->if_snd);
> + ifp->if_timer = 0;
> }
>
> - if (ifp->if_flags & IFF_RUNNING && !IFQ_IS_EMPTY(&ifp->if_snd))
> - sxie_start(ifp);
> -
> SXISET4(sc, SXIE_INTCR, SXIE_INTR_ENABLE);
>
> return 1;
> @@ -468,42 +462,36 @@ sxie_start(struct ifnet *ifp)
> uint32_t fifo;
> uint32_t txbuf[SXIE_MAX_PKT_SIZE / sizeof(uint32_t)]; /* XXX !!! */
>
> - if (sc->txf_inuse == (SXIE_TX_FIFO0 | SXIE_TX_FIFO1))
> - ifq_set_oactive(&ifp->if_snd);
> + if (ifq_is_oactive(&ifp->if_snd))
> + {
> + printf("sxie: start called while in use\n");
> + return;
> + }
>
> - if (!(ifp->if_flags & IFF_RUNNING) || ifq_is_oactive(&ifp->if_snd))
> + if (!ISSET(ifp->if_flags, IFF_RUNNING))
> + {
> + printf("sxie: start called when not running\n");
> return;
> + }
>
> td = (uint8_t *)&txbuf[0];
> m = NULL;
> head = NULL;
> -trynext:
> - m = ifq_deq_begin(&ifp->if_snd);
> +
> + m = ifq_dequeue(&ifp->if_snd);
> if (m == NULL)
> return;
>
> if (m->m_pkthdr.len > SXIE_MAX_PKT_SIZE) {
> - ifq_deq_commit(&ifp->if_snd, m);
> printf("sxie_start: packet too big\n");
> - m_freem(m);
> - return;
> + ifp->if_snd.ifq_errors++;
> + goto end;
> }
>
> - if (sc->txf_inuse == (SXIE_TX_FIFO0 | SXIE_TX_FIFO1)) {
> - ifq_deq_rollback(&ifp->if_snd, m);
> - printf("sxie_start: tx fifos in use.\n");
> - ifq_set_oactive(&ifp->if_snd);
> - return;
> - }
>
> - /* select fifo */
> - if (sc->txf_inuse & SXIE_TX_FIFO0) {
> - sc->txf_inuse |= SXIE_TX_FIFO1;
> - fifo = 1;
> - } else {
> - sc->txf_inuse |= SXIE_TX_FIFO0;
> - fifo = 0;
> - }
> + ifq_set_oactive(&ifp->if_snd);
> +
> + fifo = 0;
> SXIWRITE4(sc, SXIE_TXINS, fifo);
>
> /* set packet length */
> @@ -518,15 +506,14 @@ trynext:
> /* transmit to PHY from fifo */
> SXISET4(sc, SXIE_TXCR0 + (fifo * 4), 1);
> ifp->if_timer = 5;
> - ifq_deq_commit(&ifp->if_snd, m);
>
> #if NBPFILTER > 0
> if (ifp->if_bpf)
> bpf_mtap(ifp->if_bpf, m, BPF_DIRECTION_OUT);
> #endif
> +end:
> m_freem(m);
> -
> - goto trynext;
> + return;
> }
>
> void
