Mangix

  • Content Count

    50
  • Joined

  • Last visited

Posts posted by Mangix

  1. It should probably be tested beforehand.

     

    Again, he tested "iperf -P 4" with swconfig on an armada device. He doesn't remember if it was the armada 37x or 38x. Clearfog devices are only the latter I believe.

     

    edit: ehm I'm getting full speeds when I tested this. I think he tested this on the older 37x platform.

     

    edit2: second posibility: iperf from one device connected to the switch to another connected to the switch. I tested from the helios device itself to a router (mvebu 385 platform running OpenWrt).

  2. Unrelated but one of the patches that I removed seems to actually be useful.

     

    I just talked to Felix Fietkau and according to him, it seems the mvneta driver does not do any hardware queue configuration, leading to a nasty performance problem. Testable with iperf -P 4. Not iperf3.

     

    Although the equipment he tested on did have a switch. The Helios4 does not.

     

    I don't think the way I'm using mine it matters a whole lot though.

  3. Is it me or it the mv_xor driver being loaded late?

     

    ```

    [    0.007976] xor: measuring software checksum speed
    [    0.164062] xor: using function: arm4regs (2534.000 MB/sec)
    [    0.316068] raid6: neonx8   xor()  1096 MB/s
    [    0.452063] raid6: neonx4   xor()  1378 MB/s
    [    0.588069] raid6: neonx2   xor()  1610 MB/s
    [    0.724066] raid6: neonx1   xor()  1346 MB/s
    [    0.860075] raid6: int32x8  xor()   328 MB/s
    [    0.996072] raid6: int32x4  xor()   369 MB/s
    [    1.132082] raid6: int32x2  xor()   332 MB/s
    [    1.268063] raid6: int32x1  xor()   285 MB/s
    [    1.268067] raid6: .... xor() 1610 MB/s, rmw enabled
    [    1.665163] mv_xor f1060800.xor: Marvell shared XOR driver
    [    1.694139] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
    [    1.694257] mv_xor f1060900.xor: Marvell shared XOR driver
    [    1.722115] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )

    ```

     

    I see that /proc/interrupts shows no action despite me using RAID5.

     

    edit: from looking at kernel source, it seems btrfs uses xor_blocks instead of async_tx. The former seems software only.

  4. I tried to install ZFS on my Helios 4. Gave me some 32-bit kernel error. So btrfs it is.

     

    Anecdote: my Helios 4 has survived probably over 100 kernel freezes (because of broken DFS patches) and btrfs scrub finds no problems. bittorrent verify also shows no problems.

     

    Overall, I'm satisfied with btrfs. Now as a user of OMV, I would love OMV 6 with btrfs support :).

     

    edit: I will also note this is with RAID5, which is strongly recommended against.

  5. Is that btrfs raid5?

     

    edit: I just had a thought. Since the Helios 4 is underclocked, I wonder if placing it back to the stock clocks would make the DFS patches work.

     

    Then again, I do remember my Turris Omnia freezing as well.

     

    Never mind.

  6. 15 hours ago, FredK said:

    OTOH After the upgrade to 5.8.18, containing the DFS patches, my installation is up and running for 4 days now.

    Are there any negative implications to be expected after the release of the new kernels without DFS management?

    2 degrees higher CPU temperatures were reported on a WRT3200ACM.

     

    That's a router with no fans. In other words, no difference.

  7. I'm running btrfs scrub currently without the DFS patches. 2 hours uptime and counting. Old or new DFS patches do not make a difference. They both cause freezing.

     

    edit: I should mention the reason I'm running btrfs scrub is because of all of these kernel freezes. I'm expecting to see errors. So far there are none. That's pretty impressive as there have been 100+ freezes.

     

    Anyway I'm done with these DFS patches. Whether or not they get removed, I'm building my kernels without them.

  8. Related: https://forum.openwrt.org/t/cpu-frequency-scaling-driver-for-mvebu-wrt3200acm-etc/2808/91

     

    Not looking good.

     

    edit: I got 18 hours uptime before I gave up. testing kernel 5.9 with that PR on GitHub. Hopefully this works.

     

    dmesg shows this also:

     

    debugfs: Directory 'cpu1' with parent 'opp' already present!

     

    edit2: seems this dev 5.9 kernel has broken PWM. Fans are going at full speed. Otherwise, I went hard at it for ~3 hours. I can't get it to reboot. We'll see if it survives 24 hours. Looks like the turris people fixed something... or the last patch is what actually fixes things.

     

    edit3: I got impatient. Flashed a freshly built kernel with a new dtb. Fan works correctly now.

     

    edit4: bad news. Even these new patches cause freezing. Turns out this is easier to reproduce with btrfs scrub. It reboots within an hour.

  9. I thought Hannu moved to developing for ipq806x. Interesting...

     

    I love how he notes instability under heavy I/O. That's exactly what I experience.

     

    From what I see, patch 806 accomplishes the same as fix_time_drift_remove_global_timer.patch in a cleaner way.

     

    Anyway, I will be waiting to confirm 24 hour uptime before I try anything else.

     

    I also vote for removing these patches. We don't have these in OpenWrt. Stability is more important.

     

    edit: on that last note, a PR like that for OpenWrt will be rejected. We have problems with having too many patches. We don't need any that have no chance of making it upstream eventually.

     

    edit2: the Turris people have also sort of abandoned this patchset. They have it for their OpenWrt fork, but they use mainline openwrt in newer versions.

     

    edit3: I will note, this device has fans. I don't think temperature is ever a problem.

  10. so without the cpufreq patches, I can't get my Helios 4 to reboot. Problem solved looks like.

     

    edit: that's with kernel 5.8.18. I'm curious about 5.9 but looks like those cpufreq patches were the issue. They're not upstream and I only see armbian with them.

  11. I compiled my own 4.19.63 . So far, it's not rebooting. Fingers crossed that it can survive a day.

     

    If it does, kernel 4.19.64 and above are the problematic ones.

     

    The next step is to selectively revert potentially problematic commits and figure out which one is causing reboots.

     

    edit: I just realized that I never deleted the old cpufreq patches...

  12. I use qbittorrent ina docker container. Easily reboots the Helios4. Again, it's a kernel issue. .66 is the last one that does not reboot. 8 hours uptime so far. With all future kernels, I can barely get 2 hours.

     

    edit: just rebooted.

     

    I'm out of ideas at this point. I have a feeling it's a kernel configuration issue.

     

    I have no idea what config that 4.19.63 version has.