Mangix

  • Content Count

    57
  • Joined

  • Last visited

Everything posted by Mangix

  1. Weird. Are you saying those SD cards fail to boot with high speed support and succeed at normal? Weird thing is, I have a lexar SD card here that is not compatible (probably because it's UHS-1). My USB SD card reader can read it.
  2. Anyone know why it's not supported out of the box? The wiki provides a patch but does not mention why it's not upstream or in Armbian. The bus-width being 4 is also quite suspect. All the other Armada 38x devices have it at 8. Armada 37x ones have it at 4.
  3. Are you on the latest kernel?
  4. Yeah I know. I removed them. Simply posting for more info.
  5. Use this one: https://hub.docker.com/r/linuxserver/mariadb
  6. More info on DFS brokenness: https://gitlab.nic.cz/turris/openwrt/-/issues/347#note_195030
  7. A more performant alternative to AF_ALG... https://github.com/cotequeiroz/afalg_engine Not a solution to your issues unfortunately. IIRC, there was a way to overclock the helios to 2.0ghz or 1.8ghz. Don't remember the details.
  8. @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.
  9. 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).
  10. 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.
  11. 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
  12. kernel 5.9.12 has btrfs fixes. Sounds like the bug is something else though.
  13. 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.
  14. Maybe btrfs does something special.
  15. 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.
  16. 2 degrees higher CPU temperatures were reported on a WRT3200ACM. That's a router with no fans. In other words, no difference.
  17. 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.
  18. 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.
  19. 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.
  20. Hmm I thought there were specific armbian packages. OK then.
  21. 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.
  22. 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.
  23. 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