• Content Count

  • Joined

  • Last visited

  1. Not sure whether it's a good idea to bump this thread but just my 2cts on this: CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf). In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get: - Plain access to disk: 180MB/s - LUKS2 + CESA: 140MB/s - LUKS2 (no CESA): 52MB/s
  2. Are we supposed to upgrade our PSU? Are they all failing or was it a bad batch? Thanks!
  3. Thanks for your responses! So far I can report my Helios crashes every day unless I do the fixed-frequency clock thingy. The workload is qbittrorrent and using ssh frequently through sshfs or alike. I notice only cause I mount some stuff on my PC, otherwise I tend to not notice the crashes since the watchdog does a pretty good job at restarting it (usually < 60s), so it you only see a 2min interruption (which external monitoring does not notice most of the time). Couple that with the ethernet issues (which yeah I haven't ruled out the cable...) I can say I'm quite disappointe
  4. Oh while we are at it. I haven't found info on the heatsink (I guess from your blog posts this is something more "custom made"?). Could you please share what kind of screws go on their holes? I got a 5cm fan (that seems to work well on 3.3V) and I'm trying to hold it with screws, but can't find the right size And is there any thread on typical temperature ranges for these things? I never know whether mine is too hot or too cold. I also don't like the fact that fancontrol uses the SoC temp for the big fans, since it should only try to keep HDDs cool, and it doesn't affect that much the So
  5. My env looks like: I think thats disabled right? I'm using the NOR flash for u-boot though, but my understanding is that once uboot boots the kernel, the SPI bus is not used anymore so it should be "off" right?
  6. What kind of power supply failure are we looking for here? Lower voltage than expected? I assume most of these stuff is working on the 3.3V rail, which should we quite isolated from fluctualtions on the 12V/5V rails. Also a multimeter won't be able to measure hight frequency power drops or noise on the DC supply. I'm just a bit surprised I guess that this could be the issue really
  7. Wait there's more, this time there's a SATA issue in the middle, so perhaps they are somehow related? Here comes the syslog: [155235.130866] mvneta f1070000.ethernet eth0: Link is Down [155238.204512] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [189215.220539] mvneta f1070000.ethernet eth0: Link is Down [189217.269545] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [190094.777185] mvneta f1070000.ethernet eth0: Link is Down [190097.845100] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [191713.602453
  8. @gprovost I changed the router port and seemed ok for a couple days but now again happening. (very short for like 2sec) I can only try the cable indeed, but it's a rather good cable and not longer than 10m, so it would be strange. What I don't get is why it fails without recover every month or so and I have to reconnect the cable manually. Shouldn't it keep trying to re-negotiate the eth link? So weird IMHO.
  9. So reporting back for my Helios. I haven't had any issues using fixed clock freqs. I set it to 800MHz and bump it to fixed 1.6GHz if I need to do more stuff on it. That also helps fans to run quieter so not so bad in the end. Now an issue I've been having every month or so is lost of network connectivity. The SPI screen shows the MAC addr when that happens (instead of the IP). The IP is fixed so no shenanigans there. I also have other devices on the wired connection so I'm assuming it's no the router nor cabling. A log looks like this: [82229.270768] mvneta f107000
  10. I can provide more info: a similar thing like this freeze had only happened me once previously (it ran for a year without issues at all!) That one was during the hot summer were I live, so I suspect load temp could have played a factor here. It's in a hot spot in the house. After the upgrade, which I believe it was March14, it happened at April 2nd, twice in the day. Also march 21st. So far I've experimented running it at 800MHz fixed, perhaps manually bumping it to 1.6G whenever I need to copy stuff in bulk, but only for a few minutes. I limit it by running: # echo
  11. Is marvel_xor used for anything other than raid? i only use raid 0/1 which doesn't have any kind of parity operation.
  12. What it doesnt make sense is that Francis is saying about downgrading still causing this right? Does the previous kernel have the patches for DVFS or that's only in this kernel? I recall the old kernel would be always running at either 1.6 or 800MHz right? I think I've never had a crash when setting max freq to 800MHz, which I do to reduce heat and noise while I'm not using the NAS actively (just serving). But from the trace it does look like a bug in the dvfs code. From the looks of it seems like the kernel is trying to signal the other CPUs (in this case just one other CPU) bu
  13. Sorry for that! There you go: https://pastebin.com/SQhse3qy Also my /boot/config-4.19.104-mvebu shows that CONFIG_CRASH_DUMP and CONFIG_KEXEC are not set, which make debugging this more complicated. Ideally I'd like to get a physical memory dump when this happens, since there's no logs that I can use.
  14. Hello there! Also having issues using the new kernel. The system just freezes so there's no point on looking at logs (nothing there even if you disable ram logs) or using the serial port (didnt try but the program that drives the screen stops working so I can only assume thr whole kernel went bananas!). This is indeed hapening since the kernel upgrade. Happened like 3 times y-day and a couple more in these last two weeks since I upgraded. I think I might just downgrade the old kernel for now. Also given that it doesnt crash consistently and that my workload has not