Mangix

  • Content Count

    50
  • Joined

  • Last visited

Everything posted by Mangix

  1. @karamikeThe issue has been found and fixed. You should update to a more recent kernel (latest legacy or current kernel). I'm on 5.9.14 right now. Works flawlessly.
  2. 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).
  3. 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.
  4. 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
  5. kernel 5.9.12 has btrfs fixes. Sounds like the bug is something else though.
  6. 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.
  7. Maybe btrfs does something special.
  8. 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.
  9. 2 degrees higher CPU temperatures were reported on a WRT3200ACM. That's a router with no fans. In other words, no difference.
  10. DFS patches were removed for current and legacy. dev still has them. I assume builds will be out soon if they're not out already.
  11. 2 days uptime without DFS patches. No issues to report. Marked as solved. I assume new kernels will be out if they're not already.
  12. 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.
  13. Hmm I thought there were specific armbian packages. OK then.
  14. 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.
  15. Ah I see what you mean now. Any testing I do or don’t do will have to wait. My gut tells me these *new* patches have the same problem.
  16. 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 to
  17. 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.
  18. ksmbd is a more performant version of Samba. Located here: https://github.com/cifsd-team/cifsd and https://github.com/cifsd-team/ksmbd-tools Given that most devices supported by Armbian are underpowered, it would be great to get this installable via apt.
  19. @Heisathhow do I build dev kernels? compile.sh only shows current and legacy.
  20. 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...
  21. @kratz00my theory is a kernel problem. I had months of uptime with kernel 4.19.63. Unfortunately, I don't have the original .deb file.
  22. I will need to do more testing. .65 rebooted multiple times today... @Heisathso I actually install OpenMediaVault on top of armbian with https://github.com/OpenMediaVault-Plugin-Developers/docs/blob/master/Adden-A-Installing_OMV5_on_Armbian.pdf Under OMV, I install Portainer and then install https://hub.docker.com/r/linuxserver/qbittorrent
  23. 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.