armada 370 L2 cache
Posted by Koen
|
Re: armada 370 L2 cache November 15, 2020 11:12PM |
Registered: 7 years ago Posts: 166 |
Hi,
It did not work:
It did not work:
root@OpenWrt:/# dmesg [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.9.8 (Wacke@HOME-Server) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 10.2.0 r14945-47e089e30e) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #0 SMP Sun Nov 10 [ 0.000000] CPU: ARMv7 Processor [561f5811] revision 1 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] OF: fdt: Machine model: RTNAS V3 [ 0.000000] Forcing write-allocate cache policy for Armada 370 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff] [ 0.000000] On node 0 totalpages: 262144 [ 0.000000] Normal zone: 1728 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 196608 pages, LIFO batch:63 [ 0.000000] HighMem zone: 65536 pages, LIFO batch:15 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] percpu: Embedded 11 pages/cpu s14732 r8192 d22132 u45056 [ 0.000000] pcpu-alloc: s14732 r8192 d22132 u45056 alloc=11*4096 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260416 [ 0.000000] Kernel command line: console=ttyS0,115200 [ 0.000000] Bootloader command line (ignored): console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootfstype=ubifs [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 1027760K/1048576K available (7168K kernel code, 208K rwdata, 1676K rodata, 1024K init, 235K bss, 20816K reserved, 0K cma-reserved, 262144K highmem) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] rcu: Hierarchical RCU implementation. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] L2C: DT/platform modifies aux control register: 0x12086302 -> 0x12086300 [ 0.000000] Aurora cache controller enabled, 4 ways, 256 kB [ 0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x12086300 [ 0.000000] random: get_random_bytes called from start_kernel+0x400/0x5a4 with crng_init=0 [ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000007] sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114840871909ns [ 0.000020] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 102208375848 ns [ 0.000204] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.39 BogoMIPS (lpj=186996) [ 0.000216] pid_max: default: 32768 minimum: 301 [ 0.000327] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 0.000341] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 0.000968] CPU: Testing write buffer coherency: ok [ 0.001178] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.001653] Setting up static identity map for 0x100000 - 0x100060 [ 0.001967] mvebu-soc-id: MVEBU SoC ID=0x6710, Rev=0x1 [ 0.002054] mvebu-pmsu: Initializing Power Management Service Unit [ 0.002204] rcu: Hierarchical SRCU implementation. [ 0.002355] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build [ 0.002452] smp: Bringing up secondary CPUs ... [ 0.002461] smp: Brought up 1 node, 1 CPU [ 0.002468] SMP: Total of 1 processors activated (37.39 BogoMIPS). [ 0.002474] CPU: All CPU(s) started in SVC mode. [ 0.005075] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 [ 0.005190] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.005206] futex hash table entries: 256 (order: 2, 16384 bytes, linear) [ 0.005318] pinctrl core: initialized pinctrl subsystem [ 0.005954] NET: Registered protocol family 16 [ 0.006712] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.007372] thermal_sys: Registered thermal governor 'step_wise' [ 0.007570] mvebu-pmsu: CPU idle is currently broken: disabling [ 0.054260] cryptd: max_cpu_qlen set to 1000 [ 0.056508] SCSI subsystem initialized [ 0.057839] libata version 3.00 loaded. [ 0.058045] usbcore: registered new interface driver usbfs [ 0.058089] usbcore: registered new interface driver hub [ 0.058150] usbcore: registered new device driver usb [ 0.058435] workqueue: max_active 576 requested for napi_workq is out of range, clamping between 1 and 512 [ 0.064234] clocksource: Switched to clocksource armada_370_xp_clocksource [ 0.065048] NET: Registered protocol family 2 [ 0.065440] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear) [ 0.065469] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear) [ 0.065530] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear) [ 0.065628] TCP: Hash tables configured (established 8192 bind 8192) [ 0.065812] UDP hash table entries: 512 (order: 2, 16384 bytes, linear) [ 0.065854] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear) [ 0.066045] NET: Registered protocol family 1 [ 0.066075] PCI: CLS 0 bytes, default 64 [ 0.070901] workingset: timestamp_bits=14 max_order=18 bucket_order=4 [ 0.074237] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.074250] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.075886] bounce: pool size: 64 pages [ 0.077195] armada-370-pinctrl f1018000.pin-ctrl: registered pinctrl driver [ 0.078967] mvebu-pcie soc:pcie@82000000: host bridge /soc/pcie@82000000 ranges: [ 0.079006] mvebu-pcie soc:pcie@82000000: MEM 0x00f1040000..0x00f1041fff -> 0x0000040000 [ 0.079027] mvebu-pcie soc:pcie@82000000: MEM 0x00f1080000..0x00f1081fff -> 0x0000080000 [ 0.079046] mvebu-pcie soc:pcie@82000000: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 [ 0.079063] mvebu-pcie soc:pcie@82000000: IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 [ 0.079080] mvebu-pcie soc:pcie@82000000: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 [ 0.079093] mvebu-pcie soc:pcie@82000000: IO 0xffffffffffffffff..0x00fffffffe -> 0x0200000000 [ 0.079311] mvebu-pcie soc:pcie@82000000: PCI host bridge to bus 0000:00 [ 0.079326] pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.079337] pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff]) [ 0.079346] pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff] (bus address [0x00080000-0x00081fff]) [ 0.079353] pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff] [ 0.079361] pci_bus 0000:00: root bus resource [io 0x1000-0xeffff] [ 0.079466] pci 0000:00:01.0: [11ab:6710] type 01 class 0x060400 [ 0.079490] pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref] [ 0.079807] pci 0000:00:02.0: [11ab:6710] type 01 class 0x060400 [ 0.079827] pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref] [ 0.080767] PCI: bus0: Fast back to back transfers disabled [ 0.080779] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 0.080791] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 0.081615] PCI: bus1: Fast back to back transfers enabled [ 0.081627] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 0.082441] PCI: bus2: Fast back to back transfers enabled [ 0.082451] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02 [ 0.082511] pci 0000:00:01.0: BAR 6: assigned [mem 0xf8000000-0xf80007ff pref] [ 0.082523] pci 0000:00:02.0: BAR 6: assigned [mem 0xf8100000-0xf81007ff pref] [ 0.082533] pci 0000:00:01.0: PCI bridge to [bus 01] [ 0.082546] pci 0000:00:02.0: PCI bridge to [bus 02] [ 0.082984] mv_xor f1060800.xor: Marvell shared XOR driver [ 0.144914] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr ) [ 0.145202] mv_xor f1060900.xor: Marvell shared XOR driver [ 0.204892] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr ) [ 0.205262] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [ 0.205811] printk: console [ttyS0] disabled [ 0.205882] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 18, base_baud = 12500000) is a 16550A [ 0.975294] printk: console [ttyS0] enabled [ 0.985047] loop: module loaded [ 0.988618] sata_mv f10a0000.sata: version 1.28 [ 0.988855] sata_mv f10a0000.sata: slots 32 ports 2 [ 0.999662] scsi host0: sata_mv [ 1.003967] scsi host1: sata_mv [ 1.007349] ata1: SATA max UDMA/133 irq 27 [ 1.011468] ata2: SATA max UDMA/133 irq 27 [ 1.018190] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 1.024655] nand: Micron MT29F32G08CBACAWP [ 1.028774] nand: 4096 MiB, MLC, erase size: 1024 KiB, page size: 4096, OOB size: 224 [ 1.036665] nand: WARNING: pxa3xx_nand-0: the ECC used on your system (16b/2048B) is too weak compared to the one required by the NAND chip (24b/1024B) [ 1.051438] Bad block table found at page 1048320, version 0x01 [ 1.058750] Bad block table found at page 1048064, version 0x01 [ 1.065382] nand_read_bbt: bad block at 0x000005a00000 [ 1.070542] nand_read_bbt: bad block at 0x000005b00000 [ 1.076394] 7 fixed-partitions partitions found on MTD device pxa3xx_nand-0 [ 1.083394] Creating 7 MTD partitions on "pxa3xx_nand-0": [ 1.088871] 0x000000000000-0x000000400000 : "u-boot" [ 1.094583] 0x000000400000-0x000000800000 : "uboot_env" [ 1.100423] 0x000000800000-0x000000c00000 : "vendor" [ 1.106047] 0x000000c00000-0x000001800000 : "unused" [ 1.111610] 0x000001800000-0x000001c00000 : "kernel" [ 1.117250] 0x000001c00000-0x000040000000 : "ubi" [ 1.122843] 0x000040000000-0x0000fbc00000 : "syscfg" [ 1.129745] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information. [ 1.137654] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved. [ 1.147757] libphy: Fixed MDIO Bus: probed [ 1.152731] libphy: orion_mdio_bus: probed [ 1.167322] mv88e6085 f1072004.mdio-mii:00: switch 0x1710 detected: Marvell 88E6171, revision 2 [ 1.183575] libphy: mdio: probed [ 1.215425] mvneta f1074000.ethernet eth0: Using random mac address e2:06:d7:e3:68:54 [ 1.223544] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.230146] ehci-platform: EHCI generic platform driver [ 1.235508] ehci-orion: EHCI orion driver [ 1.239656] orion-ehci f1050000.usb: EHCI Host Controller [ 1.245122] orion-ehci f1050000.usb: new USB bus registered, assigned bus number 1 [ 1.252835] orion-ehci f1050000.usb: irq 24, io mem 0xf1050000 [ 1.284207] orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00 [ 1.290763] hub 1-0:1.0: USB hub found [ 1.295073] hub 1-0:1.0: 1 port detected [ 1.299433] orion-ehci f1051000.usb: EHCI Host Controller [ 1.304937] orion-ehci f1051000.usb: new USB bus registered, assigned bus number 2 [ 1.312633] orion-ehci f1051000.usb: irq 25, io mem 0xf1051000 [ 1.344155] orion-ehci f1051000.usb: USB 2.0 started, EHCI 1.00 [ 1.350648] hub 2-0:1.0: USB hub found [ 1.354929] hub 2-0:1.0: 1 port detected [ 1.359565] usbcore: registered new interface driver usb-storage [ 1.365819] i2c /dev entries driver [ 1.369881] ata1: SATA link down (SStatus 0 SControl F300) [ 1.394724] orion_wdt: Initial timeout 229 sec [ 1.399490] sdhci: Secure Digital Host Controller Interface driver [ 1.405776] sdhci: Copyright(c) Pierre Ossman [ 1.410284] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.421607] marvell-cesa f1090000.crypto: CESA device successfully registered [ 1.429630] NET: Registered protocol family 10 [ 1.435943] Segment Routing with IPv6 [ 1.439690] NET: Registered protocol family 17 [ 1.444645] 8021q: 802.1Q VLAN Support v1.8 [ 1.448907] Registering SWP/SWPB emulation handler [ 1.456137] mv88e6085 f1072004.mdio-mii:00: switch 0x1710 detected: Marvell 88E6171, revision 2 [ 1.472248] libphy: mdio: probed [ 1.677007] mv88e6085 f1072004.mdio-mii:00 lan1 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:00] driver [Generic PHY] (irq=POLL) [ 1.699072] mv88e6085 f1072004.mdio-mii:00 lan2 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:01] driver [Generic PHY] (irq=POLL) [ 1.713361] ata2: SATA link down (SStatus 0 SControl F300) [ 1.724388] mv88e6085 f1072004.mdio-mii:00 lan3 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:02] driver [Generic PHY] (irq=POLL) [ 1.744332] mv88e6085 f1072004.mdio-mii:00 lan4 (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:03] driver [Generic PHY] (irq=POLL) [ 1.766575] mv88e6085 f1072004.mdio-mii:00 wan (uninitialized): PHY [!soc!internal-regs!mdio@72004!switch0@0!mdio:04] driver [Generic PHY] (irq=POLL) [ 1.781413] mv88e6085 f1072004.mdio-mii:00: configuring for fixed/ link mode [ 1.789031] DSA: tree 0 setup [ 1.793279] UBI: auto-attach mtd5 [ 1.796691] ubi0: attaching mtd5 [ 1.799968] mv88e6085 f1072004.mdio-mii:00: Link is Up - 1Gbps/Full - flow control off [ 3.134587] ubi0: scanning is finished [ 3.148332] ubi0: attached mtd5 (name "ubi", size 996 MiB) [ 3.153854] ubi0: PEB size: 1048576 bytes (1024 KiB), LEB size: 1040384 bytes [ 3.161070] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 [ 3.167910] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 [ 3.174912] ubi0: good PEBs: 994, bad PEBs: 2, corrupted PEBs: 0 [ 3.180945] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128 [ 3.188208] ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1605201715 [ 3.197389] ubi0: available PEBs: 0, total reserved PEBs: 994, PEBs reserved for bad PEB handling: 78 [ 3.207950] block ubiblock0_0: created from ubi0:0(rootfs) [ 3.213469] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem [ 3.220999] ubi0: background thread "ubi_bgt0d" started, PID 649 [ 3.232675] VFS: Mounted root (squashfs filesystem) readonly on device 254:0. [ 3.242592] Freeing unused kernel memory: 1024K [ 3.265020] Run /sbin/init as init process [ 3.269137] with arguments: [ 3.269140] /sbin/init [ 3.269142] with environment: [ 3.269144] HOME=/ [ 3.269146] TERM=linux [ 3.496202] init: Console is alive [ 3.499767] init: - watchdog - [ 3.643084] kmodloader: loading kernel modules from /etc/modules-boot.d/* [ 3.745878] kmodloader: done loading kernel modules from /etc/modules-boot.d/* [ 3.755831] init: - preinit - [ 4.297747] random: jshn: uninitialized urandom read (4 bytes read) [ 4.377356] random: jshn: uninitialized urandom read (4 bytes read) [ 5.271572] random: jshn: uninitialized urandom read (4 bytes read) [ 5.317161] urandom_read: 1 callbacks suppressed [ 5.317167] random: jshn: uninitialized urandom read (4 bytes read) [ 5.348916] random: jshn: uninitialized urandom read (4 bytes read) [ 5.371081] random: jshn: uninitialized urandom read (4 bytes read) [ 9.585237] mount_root: loading kmods from internal overlay [ 9.599659] kmodloader: loading kernel modules from //etc/modules-boot.d/* [ 9.606952] kmodloader: done loading kernel modules from //etc/modules-boot.d/* [ 9.748845] UBIFS (ubi0:1): Mounting in unauthenticated mode [ 9.928772] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 741 [ 10.117884] UBIFS (ubi0:1): recovery needed [ 10.822752] UBIFS (ubi0:1): recovery completed [ 10.827327] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data" [ 10.835210] UBIFS (ubi0:1): LEB size: 1040384 bytes (1016 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes [ 10.845364] UBIFS (ubi0:1): FS size: 934264832 bytes (890 MiB, 898 LEBs), journal size 33292288 bytes (31 MiB, 32 LEBs) [ 10.856204] UBIFS (ubi0:1): reserved for root: 4952683 bytes (4836 KiB) [ 10.862851] UBIFS (ubi0:1): media format: w5/r0 (latest is w5/r0), UUID 750D90FD-F1F5-49D5-8297-7598A1A1518F, small LPT model [ 10.876518] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab [ 10.896494] block: extroot: not configured [ 10.900735] UBIFS (ubi0:1): un-mount UBI device 0 [ 10.905535] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops [ 10.916663] UBIFS (ubi0:1): Mounting in unauthenticated mode [ 11.096715] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 743 [ 11.753658] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data" [ 11.761571] UBIFS (ubi0:1): LEB size: 1040384 bytes (1016 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes [ 11.771719] UBIFS (ubi0:1): FS size: 934264832 bytes (890 MiB, 898 LEBs), journal size 33292288 bytes (31 MiB, 32 LEBs) [ 11.782558] UBIFS (ubi0:1): reserved for root: 4952683 bytes (4836 KiB) [ 11.789213] UBIFS (ubi0:1): media format: w5/r0 (latest is w5/r0), UUID 750D90FD-F1F5-49D5-8297-7598A1A1518F, small LPT model [ 11.890722] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab [ 11.907313] block: extroot: not configured [ 11.914019] mount_root: switching to ubifs overlay [ 11.946213] urandom-seed: Seeding with /etc/urandom.seed [ 12.003272] procd: - early - [ 12.006765] procd: - watchdog - [ 12.598643] procd: - watchdog - [ 12.601993] procd: - ubus - [ 12.652214] urandom_read: 1 callbacks suppressed [ 12.652221] random: ubusd: uninitialized urandom read (4 bytes read) [ 12.664532] random: ubusd: uninitialized urandom read (4 bytes read) [ 12.671823] procd: - init - [ 13.431798] kmodloader: loading kernel modules from /etc/modules.d/* [ 13.523356] urngd: v1.0.2 started. [ 13.701993] random: crng init done [ 13.707737] xt_time: kernel timezone is -0000 [ 13.734635] PPP generic driver version 2.4.2 [ 13.781709] NET: Registered protocol family 24 [ 13.807964] kmodloader: done loading kernel modules from /etc/modules.d/* [ 19.164897] mvneta f1074000.ethernet eth0: configuring for fixed/rgmii-id link mode [ 19.173992] mvneta f1074000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 19.194253] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 19.239358] mv88e6085 f1072004.mdio-mii:00 lan1: configuring for phy/gmii link mode [ 19.274629] 8021q: adding VLAN 0 to HW filter on device lan1 [ 19.280710] br-lan: port 1(lan1) entered blocking state [ 19.286040] br-lan: port 1(lan1) entered disabled state [ 19.314296] device lan1 entered promiscuous mode [ 19.318949] device eth0 entered promiscuous mode [ 19.456509] mv88e6085 f1072004.mdio-mii:00 lan2: configuring for phy/gmii link mode [ 19.491060] 8021q: adding VLAN 0 to HW filter on device lan2 [ 19.548676] br-lan: port 2(lan2) entered blocking state [ 19.553940] br-lan: port 2(lan2) entered disabled state [ 19.594906] device lan2 entered promiscuous mode [ 19.616214] mv88e6085 f1072004.mdio-mii:00 lan3: configuring for phy/gmii link mode [ 19.646404] 8021q: adding VLAN 0 to HW filter on device lan3 [ 19.664848] br-lan: port 3(lan3) entered blocking state [ 19.670122] br-lan: port 3(lan3) entered disabled state [ 19.710596] device lan3 entered promiscuous mode [ 19.726957] mv88e6085 f1072004.mdio-mii:00 lan4: configuring for phy/gmii link mode [ 19.757876] 8021q: adding VLAN 0 to HW filter on device lan4 [ 19.772126] br-lan: port 4(lan4) entered blocking state [ 19.777458] br-lan: port 4(lan4) entered disabled state [ 19.816970] device lan4 entered promiscuous mode [ 19.848351] mv88e6085 f1072004.mdio-mii:00 wan: configuring for phy/gmii link mode [ 19.877792] 8021q: adding VLAN 0 to HW filter on device wan [ 23.618314] mv88e6085 f1072004.mdio-mii:00 lan1: Link is Up - 1Gbps/Full - flow control rx/tx [ 23.626930] br-lan: port 1(lan1) entered blocking state [ 23.632183] br-lan: port 1(lan1) entered forwarding state [ 23.639450] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 33.294450] 8<--- cut here --- [ 33.297537] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6f65100 [ 33.305231] pgd = 59d45f36 [ 33.307949] [b6f65100] *pgd=2d7e8831, *pte=f0008383, *ppte=f0008a33
|
Re: armada 370 L2 cache November 16, 2020 12:37AM |
Registered: 7 years ago Posts: 166 |
|
Re: armada 370 L2 cache November 16, 2020 12:55AM |
Admin Registered: 12 years ago Posts: 17,893 |
wacke,
You are running OpenWrt, so I don't know what caused that error in the dmesg.
Perhaps you can boot with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 on USB.
Your u-boot is newer so the appropriate kernel and Debian rootfs is in my release thread:
https://forum.doozan.com/read.php?2,32146
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
You are running OpenWrt, so I don't know what caused that error in the dmesg.
Perhaps you can boot with rootfs Debian-5.2.9-mvebu-tld-1-rootfs-bodhi.tar.bz2 on USB.
Your u-boot is newer so the appropriate kernel and Debian rootfs is in my release thread:
https://forum.doozan.com/read.php?2,32146
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 16, 2020 01:06AM |
Registered: 7 years ago Posts: 166 |
bodhi Wrote:
-------------------------------------------------------
> wacke,
>
> You are running OpenWrt, so I don't know what
> caused that error in the dmesg.
>
That error was the resault of devmem 0xd0008100, and now I can get the resault:
But the
-------------------------------------------------------
> wacke,
>
> You are running OpenWrt, so I don't know what
> caused that error in the dmesg.
>
That error was the resault of devmem 0xd0008100, and now I can get the resault:
root@OpenWrt:/# devmem 0xf1008100 0x00000001 root@OpenWrt:/# devmem 0xf1008104 0x12086300 root@OpenWrt:/# devmem 0xf1020200 0x01000002
But the
devmem 0xf1008104output was not correct. How did you fix this?
|
Re: armada 370 L2 cache November 16, 2020 04:02AM |
Admin Registered: 12 years ago Posts: 17,893 |
wacke,
I'm not sure why your system reverse the address back to 0x12086300.
If that address 0x12086300 is indeed correct then it is OK.
It could be because your box has newer u-boot (the memory is different with this u-boot), but I cannot tell for sure.
You might try running my Debian rootfs and see if it behaves the same way as what we saw.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I'm not sure why your system reverse the address back to 0x12086300.
[ 0.000000] L2C: DT/platform modifies aux control register: 0x12086302 -> 0x12086300 [ 0.000000] Aurora cache controller enabled, 4 ways, 256 kB [ 0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x12086300
If that address 0x12086300 is indeed correct then it is OK.
root@OpenWrt:/# devmem 0xf1008100 0x00000001 root@OpenWrt:/# devmem 0xf1008104 0x12086300
It could be because your box has newer u-boot (the memory is different with this u-boot), but I cannot tell for sure.
You might try running my Debian rootfs and see if it behaves the same way as what we saw.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 20, 2020 03:36PM |
Registered: 6 years ago Posts: 142 |
Hi bodhi,
On my Netgear ReadyNAS RN102, I installed and tested Linux kernel '5.8.5-mvebu-370xp-tld-1' with the dtb-file you posted on November 14th. From the boot log:
The L2 control register, as well as the register following it, were set as expected:
The network bandwith was tested with 'netcat'. The box and my laptop were connected directly with a patch cable (no router). Both were assigned static IP addresses and 1 GiB of data were transferred. On the box 'netcat' was set to listen and discard:
Before installing the new dtb-file, it took 34 - 40 s (as reported by 'pv') to transfer the data (i.e. about 27 MiB/s). Afterwards, it took 22 - 23 s (i.e. about 44 MiB/s). A signifficant improvement indeed, but still not very impressive? If I understand correctly, enabling the CPU coherency should boost performance a bit further:
On the box, virtually all time was spent in the kernel, and almost nothing in user space:
Thanks, Koen, for making me aware of this discussion!
Regards,
Trond Melen
On my Netgear ReadyNAS RN102, I installed and tested Linux kernel '5.8.5-mvebu-370xp-tld-1' with the dtb-file you posted on November 14th. From the boot log:
[ 0.000000][ T0] L2C: DT/platform modifies aux control register: 0x12086300 -> 0x1a086302 [ 0.000000][ T0] Aurora cache controller enabled, 4 ways, 256 kB [ 0.000000][ T0] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302 ... [ 0.543313][ T1] mvebu-pmsu: CPU idle is currently broken: disabling
The L2 control register, as well as the register following it, were set as expected:
# busybox devmem 0xd0008100 0x00000001 # busybox devmem 0xd0008104 0x1A086302
The network bandwith was tested with 'netcat'. The box and my laptop were connected directly with a patch cable (no router). Both were assigned static IP addresses and 1 GiB of data were transferred. On the box 'netcat' was set to listen and discard:
time nc -q 0 -l -p 2222 > /dev/nullOn the laptop, 'pv' and 'netcat' were set to send 1 GiB of zeros:
pv -S -s 1G /dev/zero | nc 192.168.1.141 2222(Port 2222 and IP address 192.168.1.141 were arbitrarily chosen.)
Before installing the new dtb-file, it took 34 - 40 s (as reported by 'pv') to transfer the data (i.e. about 27 MiB/s). Afterwards, it took 22 - 23 s (i.e. about 44 MiB/s). A signifficant improvement indeed, but still not very impressive? If I understand correctly, enabling the CPU coherency should boost performance a bit further:
# busybox devmem 0xd0020200 0x00000002
On the box, virtually all time was spent in the kernel, and almost nothing in user space:
real 0m21.994s user 0m0.258s sys 0m20.562s
Thanks, Koen, for making me aware of this discussion!
Regards,
Trond Melen
|
Re: armada 370 L2 cache November 20, 2020 04:10PM |
Admin Registered: 12 years ago Posts: 17,893 |
Thanks Trond,
Cool! looks like it's almost all checked out for this performace improvement.
One test left to do is the iperf test.
David reported that on Mirabox his iperf number went from 400's Mbs to 800's Mbs. But mine went from 400's Mbs to 600's Mbs! It could be the switch I am using is not good. I'll have to set up the Mirabox a little better to see if I can get to 800 Mbs.
Now regarding the IO Cohenrency (the correct terminology), and the limitation in Linux kernel ability to determine hardware very early on. Since we are using a separate kernel for the Armada 370, danitool's patch is OK. I think it could be slightly adjusted to have a litle more clarity. This issue is similar for the reason (UART address) why I need to build different kernel and cannot use the standard MVEBU kernel.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Cool! looks like it's almost all checked out for this performace improvement.
One test left to do is the iperf test.
David reported that on Mirabox his iperf number went from 400's Mbs to 800's Mbs. But mine went from 400's Mbs to 600's Mbs! It could be the switch I am using is not good. I'll have to set up the Mirabox a little better to see if I can get to 800 Mbs.
Now regarding the IO Cohenrency (the correct terminology), and the limitation in Linux kernel ability to determine hardware very early on. Since we are using a separate kernel for the Armada 370, danitool's patch is OK. I think it could be slightly adjusted to have a litle more clarity. This issue is similar for the reason (UART address) why I need to build different kernel and cannot use the standard MVEBU kernel.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 21, 2020 02:47AM |
Registered: 6 years ago Posts: 142 |
Quote
bodhi
One test left to do is the iperf test.
In this test, the laptop's IP address was 192.168.1.200. This is from the box:
# iperf -c 192.168.1.200 ------------------------------------------------------------ Client connecting to 192.168.1.200, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.141 port 40814 connected with 192.168.1.200 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 861 MBytes 722 Mbits/secThe performance was the same with a direct cable as when the traffic was relayed through a gigabit router.
I'm surprised to see that the bandwidth reported by 'iperf' is about twice that achieved with 'netcat'.'iperf' seems to report peak performance, which, by definition, is some performance measure the device is guaranteed never to exceed. The performance with 'netcat' seems closer to what one can expect as a user of the device.
I guess 'iperf' runs a "ping pong test" with multiple balls in motion. Does the data in this test actually hit memory at either end, or are the IP packages turned around by the PHY itself in some test mode with hardware loop-back?
Regards,
Trond Melen
|
Re: armada 370 L2 cache November 21, 2020 03:24AM |
Registered: 6 years ago Posts: 142 |
I repeated the 'iperf' test, but now with the RT102 as the server. This is from the laptop:
I also repeated the test with 'pv' and 'netcat', now transferring data from the box to the laptop. This is from the box:
On the laptop, there was no stress:
Regards,
Trond Melen
$ iperf -c 192.168.1.141 ------------------------------------------------------------ Client connecting to 192.168.1.141, TCP port 5001 TCP window size: 612 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.200 port 44248 connected with 192.168.1.141 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 658 MBytes 552 Mbits/secThe reported bandwith is down by almost 20%.
I also repeated the test with 'pv' and 'netcat', now transferring data from the box to the laptop. This is from the box:
# time (pv -S -s 1G /dev/zero | nc 192.168.1.200 2222) 1.00GiB 0:00:47 [21.4MiB/s] [================================>] 100% ^C real 0m48.386s user 0m1.394s sys 0m46.365sThe elapsed time doubled from 23 s to 47 s (as reported by 'pv'). For the RT102, generating all those zeros and pushing them through the shell's pipe is a similar workload to pulling them from the Ethernet connector and discarding them. As before, very few CPU cycles were spent in user mode.
On the laptop, there was no stress:
$ time nc -l -q 0 -p 2222 > /dev/null real 0m52,696s user 0m1,521s sys 0m5,793s
Regards,
Trond Melen
|
Re: armada 370 L2 cache November 21, 2020 04:02AM |
Admin Registered: 12 years ago Posts: 17,893 |
Hi Trond,
The performance difference might have something to do with flow control, which is the default in this kernel.
You could run the bidirectional iperf test. See if you get a difference bandwidth.
Laptop:
RN102:
I believe iperf test is designed to measure the pure network performance so no packet is actually processed inside.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
The performance difference might have something to do with flow control, which is the default in this kernel.
You could run the bidirectional iperf test. See if you get a difference bandwidth.
Laptop:
iperf -s -i 3
RN102:
iperf -n2000M -i 3 -c 192.168.1.200
Quote
I guess 'iperf' runs a "ping pong test" with multiple balls in motion. Does the data in this test actually hit memory at either end, or are the IP packages turned around by the PHY itself in some test mode with hardware loop-back?
I believe iperf test is designed to measure the pure network performance so no packet is actually processed inside.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 21, 2020 05:31AM |
Registered: 6 years ago Posts: 142 |
I have repeated the above tests on my second Netgear ReadyNAS RN102 running the current stock firmware version 6.10.3:
Register snooping:
Highlights from the boot log:
The laptop, cabled to the same gigabit router as the box, was set to generate and send 1 GiB of zeros:
The box had already been set to listen and discard:
I think the stock firmware deserves to be the base case, implying that the performance drop of the open source firmware was reduced from 67% to 45% by enabling the L2 cache. A lot of wasted CPU cycles are still to be found though, I'm afraid.
For completeness, here is the 'iperf' result with the laptop as the server:
Regards,
Trond Melen
# uname -a Linux rn102 4.4.190.armada.1 #1 SMP Mon Oct 28 02:07:39 UTC 2019 armv7l GNU/Linux # cat /etc/debian_version 8.11 # dmesg | grep mvebu-pmsu [ 0.002181] mvebu-pmsu: Initializing Power Management Service Unit
Register snooping:
# busybox devmem 0xd0008100 0x00000001 # busybox devmem 0xd0008104 0x1A086302 # busybox devmem 0xd0020200 0x00000002
Highlights from the boot log:
[ 0.000000] Memory policy: Data cache writeback ... [ 0.000000] Kernel command line: console=ttyS0,115200 reason=normal bdtype=rn102 ... [ 0.000000] L2C: DT/platform modifies aux control register: 0x12086300 -> 0x1a086302 [ 0.000000] Aurora cache controller enabled, 4 ways, 256 kB [ 0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302 ... [ 0.002181] mvebu-pmsu: Initializing Power Management Service Unit
The laptop, cabled to the same gigabit router as the box, was set to generate and send 1 GiB of zeros:
$ pv -S -s 1G /dev/zero | nc 192.168.1.192 2222
1,00GiB 0:00:12 [82,1MiB/s] [===================================================================================>] 100%
^C
So the elapsed time (as reported by 'pv' on the laptop) was down from 22 s with open source firmware to 12 s with Netgear's firmware.
The box had already been set to listen and discard:
# time nc -q 0 -l -p 2222 > /dev/null real 0m13.329s user 0m0.350s sys 0m11.890s
I think the stock firmware deserves to be the base case, implying that the performance drop of the open source firmware was reduced from 67% to 45% by enabling the L2 cache. A lot of wasted CPU cycles are still to be found though, I'm afraid.
For completeness, here is the 'iperf' result with the laptop as the server:
# iperf -c 192.168.1.200 ------------------------------------------------------------ Client connecting to 192.168.1.200, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.192 port 40402 connected with 192.168.1.200 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.09 GBytes 939 Mbits/secSo the RT102 is capable of saturating a gigabit Ethernet connection, but currently only with the stock firmware. The performance drop was reduced to 23% by the L2 cache fix for the open source firmware (as reported by 'iperf' with default settings). I'm happier not knowing how much it was before the fix!
Regards,
Trond Melen
|
Re: armada 370 L2 cache November 21, 2020 04:49PM |
Admin Registered: 12 years ago Posts: 17,893 |
@daviddyer,
Could you post your iperf test? and also
Thanks!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Could you post your iperf test? and also
ethtool eth0
Thanks!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 21, 2020 07:14PM |
Registered: 6 years ago Posts: 359 |
Server is Optiplex790 (Intel i3-2100, 8GB memory, Dell OptiPlex 790 Motherboard with Intel Giga ethernet NIC) , Ubuntu , IP address
192.168.7.28
root@OptiPlex790:~# uname -a
Linux OptiPlex790 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@OptiPlex790:~# iperf -s
One strange thing: with L2 enabled, / disabled,
time echo "scale=4000; 4*a(1)" | bc -l
is about the same. At about 68 seconds, about the same level with goflexhome / dockstar
Edited 2 time(s). Last edit at 11/21/2020 07:16PM by daviddyer.
192.168.7.28
root@OptiPlex790:~# uname -a
Linux OptiPlex790 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@OptiPlex790:~# iperf -s
------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.87 port 52996 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.87 port 52998 [ 4] 0.0-10.0 sec 1.09 GBytes 935 Mbits/sec 192.168.7.87 is Rock64 1GB single board computer with 1GB memory. Run to compare. ---------------------------------------------------------------------------------------------------- [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58602 [ 4] 0.0-10.0 sec 976 MBytes 818 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58604 [ 4] 0.0-10.0 sec 946 MBytes 793 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58606 [ 4] 0.0-10.0 sec 947 MBytes 793 Mbits/sec 192.168.7.48 is mirabox with new dtb. Kernel 5.8.5 ~800Mb/s level ---------------------------------------------------------------------------------------------------- [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39260 [ 4] 0.0-10.0 sec 483 MBytes 405 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39262 [ 4] 0.0-10.0 sec 481 MBytes 403 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 39264 [ 4] 0.0-10.0 sec 486 MBytes 407 Mbits/sec 192.168.7.48 is mirabox with old dtb. Kernel 5.8.5 ~400Mb/s level ----------------------------------------------------------------------------------------------------
root@Mirabox:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes
One strange thing: with L2 enabled, / disabled,
time echo "scale=4000; 4*a(1)" | bc -l
is about the same. At about 68 seconds, about the same level with goflexhome / dockstar
Edited 2 time(s). Last edit at 11/21/2020 07:16PM by daviddyer.
|
Re: armada 370 L2 cache November 21, 2020 09:53PM |
Admin Registered: 12 years ago Posts: 17,893 |
Thanks David!
I think your test proved that the optimum performance was achieved. Usually if we get 800-900 Mbs with iperf test, that's all we can do in real world usage. It is quite near the theoretical bandwidth.
So the bottom line, 2 important factors:
1. The network driver settings in this kernel. I'd suspect that when you turn off flow control, you will get even better network performance.
2. The network nodes that are currently in your environment. Whether a Gbit router, a managed Gbit switch, an unmanaged Gbit switch,... etc, all palying a role in optimum performance. But most importanly, it will depend on what setting a target node has in its NIC. For example, if flow control is not disabled throughout the network, there might still be some degraded performance between some nodes.
====
So to eliminate the effects of the MVEBU box network settings on other connecting nodes, I think I will need to revisit this issue and ensure the kernel driver will configure the NIC with flow control disabled, as a start.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 11/21/2020 10:03PM by bodhi.
I think your test proved that the optimum performance was achieved. Usually if we get 800-900 Mbs with iperf test, that's all we can do in real world usage. It is quite near the theoretical bandwidth.
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58602 [ 4] 0.0-10.0 sec 976 MBytes 818 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58604 [ 4] 0.0-10.0 sec 946 MBytes 793 Mbits/sec [ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 58606 [ 4] 0.0-10.0 sec 947 MBytes 793 Mbits/sec 192.168.7.48 is mirabox with new dtb. Kernel 5.8.5 ~800Mb/s level
So the bottom line, 2 important factors:
1. The network driver settings in this kernel. I'd suspect that when you turn off flow control, you will get even better network performance.
2. The network nodes that are currently in your environment. Whether a Gbit router, a managed Gbit switch, an unmanaged Gbit switch,... etc, all palying a role in optimum performance. But most importanly, it will depend on what setting a target node has in its NIC. For example, if flow control is not disabled throughout the network, there might still be some degraded performance between some nodes.
====
So to eliminate the effects of the MVEBU box network settings on other connecting nodes, I think I will need to revisit this issue and ensure the kernel driver will configure the NIC with flow control disabled, as a start.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 11/21/2020 10:03PM by bodhi.
|
Re: armada 370 L2 cache November 22, 2020 02:36AM |
Registered: 6 years ago Posts: 359 |
disable / enable flow control, no big difference.
--------------------------------------------------------------
Booted mirabox original firmware, installed iperf
root@mirabox-debian:/media/usb0# uname -a
Linux mirabox-debian 3.2.36 #5 Sun Oct 6 21:30:02 EDT 2013 armv7l GNU/Linux
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60203
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60204
[ 4] 0.0-10.0 sec 1.10 GBytes 937 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60205
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
--------------------------------------------------------------
Booted mirabox original firmware, installed iperf
root@mirabox-debian:/media/usb0# uname -a
Linux mirabox-debian 3.2.36 #5 Sun Oct 6 21:30:02 EDT 2013 armv7l GNU/Linux
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60203
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60204
[ 4] 0.0-10.0 sec 1.10 GBytes 937 Mbits/sec
[ 4] local 192.168.7.28 port 5001 connected with 192.168.7.48 port 60205
[ 4] 0.0-10.0 sec 1.10 GBytes 938 Mbits/sec
|
Re: armada 370 L2 cache November 22, 2020 03:09AM |
Admin Registered: 12 years ago Posts: 17,893 |
Thanks David,
I've looked at the Mirabox stock boot log again today. I think this must be the reason you got 900's Mbs in stock vs 800's in Debian. Apparently, stock kernel has a patch for IO coherency.
I will build the new kernel 5.9.3 with danitool patch, and see if that will make up for the difference.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I've looked at the Mirabox stock boot log again today. I think this must be the reason you got 900's Mbs in stock vs 800's in Debian. Apparently, stock kernel has a patch for IO coherency.
[Mon Mar 11 08:36:03 2019] Aurora L2 Cache Enabled [Mon Mar 11 08:36:03 2019] Support IO coherency.
I will build the new kernel 5.9.3 with danitool patch, and see if that will make up for the difference.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 22, 2020 03:13AM |
Registered: 6 years ago Posts: 142 |
Hi bodhi,
Here the output of 'ethtool' from both of my Netgear RedyNAS RN102 boxes:
I also did 2 more kernel performance tests using 'dd' only. Generating 1 GiB of zeros and discarding them takes 1.7 s on both boxes:
Generating 128 MiB of random numbers takes 5 s with your kernel and 40 s with the stock kernel:
I guess Marvell Armada 370 SoC's hardware support for random number generation was activated above, and that Netgear didn't care to add it, neither to '/dev/random' nor to '/dev/hwrng':
Regards,
Trond Melen
Here the output of 'ethtool' from both of my Netgear RedyNAS RN102 boxes:
root@debian:~# uname -a Linux debian 5.8.5-mvebu-370xp-tld-1 #1.0 SMP PREEMPT Mon Aug 31 00:00:32 PDT 2020 armv7l GNU/Linux root@debian:~# ethtool --version ethtool version 4.19 root@debian:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yes
root@rn102:~# uname -a Linux rn102 4.4.190.armada.1 #1 SMP Mon Oct 28 02:07:39 UTC 2019 armv7l GNU/Linux root@rn102:~# ethtool --version ethtool version 3.16 root@rn102:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: external Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yesSo your kernel does not support "1000baseT/Half", while Netgear's kernel does not support (nor advertise) "pause frame use". Further, your transceiver is reported as "internal", while Netgear's kernel reports it as "external". Both of which cannot be true, right?
I also did 2 more kernel performance tests using 'dd' only. Generating 1 GiB of zeros and discarding them takes 1.7 s on both boxes:
root@debian:~# dd if=/dev/zero of=/dev/null bs=32k count=32768 32768+0 records in 32768+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.7174 s, 625 MB/s root@debian:~# dd if=/dev/zero of=/dev/null bs=32k count=32768 32768+0 records in 32768+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.7253 s, 622 MB/s
root@rn102:~# dd if=/dev/zero of=/dev/null bs=32k count=32768 32768+0 records in 32768+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.70022 s, 632 MB/s root@rn102:~# dd if=/dev/zero of=/dev/null bs=32k count=32768 32768+0 records in 32768+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.69149 s, 635 MB/s
Generating 128 MiB of random numbers takes 5 s with your kernel and 40 s with the stock kernel:
root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 4.83643 s, 27.8 MB/s root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 5.05595 s, 26.5 MB/s root@debian:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 5.0566 s, 26.5 MB/s
root@rn102:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 40.2958 s, 3.3 MB/s root@rn102:~# dd if=/dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 40.3769 s, 3.3 MB/s root@rn102:~# /dev/urandom of=/dev/null bs=32k count=4096 4096+0 records in 4096+0 records out 134217728 bytes (134 MB, 128 MiB) copied, 40.2967 s, 3.3 MB/sThat is a 700% performance increase! I'm very happy to be able to report some, for you, encouraging performance numbers.
I guess Marvell Armada 370 SoC's hardware support for random number generation was activated above, and that Netgear didn't care to add it, neither to '/dev/random' nor to '/dev/hwrng':
root@rn102:~# ls -alF /dev/hwrng crw------- 1 root root 10, 183 Nov 22 08:54 /dev/hwrng root@rn102:~# hexdump -C -n 8 /dev/hwrng hexdump: /dev/hwrng: No such device
Regards,
Trond Melen
|
Re: armada 370 L2 cache November 22, 2020 04:57AM |
Admin Registered: 12 years ago Posts: 17,893 |
Trond,
Ah, stock kernel has flow control disabled by default. That helps in negotiating with the node at the other end (whether it is a switch or NIC). I'm not sure why stock set it to "external", the LAN chip is part of the Armada 370 SoC.
Cool!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 11/22/2020 04:59AM by bodhi.
Quote
So your kernel does not support "1000baseT/Half", while Netgear's kernel does not support (nor advertise) "pause frame use". Further, your transceiver is reported as "internal", while Netgear's kernel reports it as "external". Both of which cannot be true, right?
Ah, stock kernel has flow control disabled by default. That helps in negotiating with the node at the other end (whether it is a switch or NIC). I'm not sure why stock set it to "external", the LAN chip is part of the Armada 370 SoC.
Quote
That is a 700% performance increase! I'm very happy to be able to report some, for you, encouraging performance numbers.
Cool!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 11/22/2020 04:59AM by bodhi.
|
Re: armada 370 L2 cache November 22, 2020 04:13PM |
Admin Registered: 12 years ago Posts: 17,893 |
Hi Trond,
Please do this in stock and Debian for this box, and also on the PC/laptop that you use for testing iperf
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Please do this in stock and Debian for this box, and also on the PC/laptop that you use for testing iperf
ip link show
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: armada 370 L2 cache November 22, 2020 08:06PM |
Registered: 6 years ago Posts: 142 |
Hi bodhi,
Regards,
Trond Melen
root@rn102:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 532
link/ether 12:34:56:78:90:ab brd ff:ff:ff:ff:ff:ff
tme@debian:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
link/ether 34:56:78:90:ab:cd brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/tunnel6 :: brd ::
tme@t470s:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 12:34:12:34:12:34 brd ff:ff:ff:ff:ff:ff
4: wlp58s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 56:78:56:78;56:78 brd ff:ff:ff:ff:ff:ff
42: wwan0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 90.ab:90.ab:90.ab brd ff:ff:ff:ff:ff:ff
Regards,
Trond Melen
