DavidGF

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 I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64. For me this is quite good already even tho CESA only supports some "relatively old" ciphers. Hope this helps other people!

Are we supposed to upgrade our PSU? Are they all failing or was it a bad batch? Thanks!

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 disappointed at this device. I used to have a Zyxel NSA320 and worked so well for so many years (and counting!) even tho it was very slow Overall I think might be safer to go for an Intel platform, they are usually rock solid reliable, upstream Linux support, etc. Anyway thanks for your software efforts and support, appreciatted. PS Forgot to ask, does the new Debian Focal armbian release ship any new kernel? I hope there's some fixes soon

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 SoC temperature (I think!) Thanks!

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?

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

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] mvneta f1070000.ethernet eth0: Link is Down [191719.750764] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [192245.025907] mvneta f1070000.ethernet eth0: Link is Down [192247.066877] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [195015.773833] mvneta f1070000.ethernet eth0: Link is Down [195020.893592] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [195093.594020] mvneta f1070000.ethernet eth0: Link is Down [201080.502476] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [201080.592561] ata2.00: exception Emask 0x10 SAct 0x40000000 SErr 0x380000 action 0x6 frozen [201080.592568] ata2.00: irq_stat 0x08000000, interface fatal error [201080.592575] ata2: SError: { 10B8B Dispar BadCRC } [201080.592585] ata2.00: failed command: READ FPDMA QUEUED [201080.592602] ata2.00: cmd 60/00:f0:28:5b:f6/01:00:19:01:00/40 tag 30 ncq dma 131072 in res 40/00:f0:28:5b:f6/00:00:19:01:00/40 Emask 0x10 (ATA bus error) [201080.592607] ata2.00: status: { DRDY } [201080.592616] ata2: hard resetting link [201081.067429] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [201081.069568] ata2.00: configured for UDMA/133 [201081.069591] ata2: EH complete [201081.098432] ata2.00: exception Emask 0x10 SAct 0x1 SErr 0x300000 action 0x6 frozen [201081.098438] ata2.00: irq_stat 0x08000000, interface fatal error [201081.098445] ata2: SError: { Dispar BadCRC } [201081.098452] ata2.00: failed command: READ FPDMA QUEUED [201081.098468] ata2.00: cmd 60/00:00:28:5b:f6/01:00:19:01:00/40 tag 0 ncq dma 131072 in res 40/00:00:28:5b:f6/00:00:19:01:00/40 Emask 0x10 (ATA bus error) [201081.098473] ata2.00: status: { DRDY } [201081.098485] ata2: hard resetting link [201081.581866] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [201081.584000] ata2.00: configured for UDMA/133 [201081.584021] ata2: EH complete [201081.608251] ata2.00: exception Emask 0x10 SAct 0x40000 SErr 0x300000 action 0x6 frozen [201081.608257] ata2.00: irq_stat 0x08000000, interface fatal error [201081.608263] ata2: SError: { Dispar BadCRC } [201081.608273] ata2.00: failed command: READ FPDMA QUEUED [201081.608289] ata2.00: cmd 60/00:90:28:5b:f6/01:00:19:01:00/40 tag 18 ncq dma 131072 in res 40/00:90:28:5b:f6/00:00:19:01:00/40 Emask 0x10 (ATA bus error) [201081.608294] ata2.00: status: { DRDY } [201081.608302] ata2: hard resetting link [201083.575530] mvneta f1070000.ethernet eth0: Link is Down [201092.108849] ata2: softreset failed (1st FIS failed) [201092.108856] ata2: hard resetting link [201093.085525] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [201093.087647] ata2.00: configured for UDMA/133 [201093.087669] ata2: EH complete [201123.506839] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [201123.888855] ata2: limiting SATA link speed to 1.5 Gbps [201123.888866] ata2.00: exception Emask 0x10 SAct 0x80 SErr 0x380000 action 0x6 frozen [201123.888871] ata2.00: irq_stat 0x08000000, interface fatal error [201123.888878] ata2: SError: { 10B8B Dispar BadCRC } [201123.888886] ata2.00: failed command: READ FPDMA QUEUED [201123.888903] ata2.00: cmd 60/00:38:08:c1:ef/01:00:19:01:00/40 tag 7 ncq dma 131072 in res 40/00:38:08:c1:ef/00:00:19:01:00/40 Emask 0x10 (ATA bus error) [201123.888908] ata2.00: status: { DRDY } [201123.888918] ata2: hard resetting link [201124.363551] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [201124.365795] ata2.00: configured for UDMA/133 [201124.365821] ata2: EH complete [201132.723242] mvneta f1070000.ethernet eth0: Link is Down [201135.794425] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [201138.865790] mvneta f1070000.ethernet eth0: Link is Down [201141.933754] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

@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.

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 f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [82266.140770] mvneta f1070000.ethernet eth0: Link is Down [82269.204030] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [82273.301606] mvneta f1070000.ethernet eth0: Link is Down [82275.346281] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [82277.400309] mvneta f1070000.ethernet eth0: Link is Down [82281.490395] mvneta f1070000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [82525.192593] mvneta f1070000.ethernet eth0: Link is Down [82527.234861] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [82537.477555] mvneta f1070000.ethernet eth0: Link is Down [82545.668087] mvneta f1070000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [159979.389745] hrtimer: interrupt took 22241 ns [280304.142020] mvneta f1070000.ethernet eth0: Link is Down [280307.208683] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [428513.940938] TCP: request_sock_TCP: Possible SYN flooding on port 6881. Sending cookies. Check SNMP counters. [852021.596335] TCP: request_sock_TCP: Possible SYN flooding on port 2000. Sending cookies. Check SNMP counters. [1116437.428694] mvneta f1070000.ethernet eth0: Link is Down [1116439.474454] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [1116447.664646] mvneta f1070000.ethernet eth0: Link is Down [1116818.324191] mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx As you can see the last interruption happened for a few minutes and was only resolved after I manually unplugged and replugged the eth cable. But it happens every now and then for a few seconds, which is not super noticeable due to TCP hiding those 4-5s interruptions. Any ideas?

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 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq I think it has been running OK so far at 800MHz, I will wait a month or two to see whether it keeps stable. If that's the case then I'll switch to max-freq 1.6G and see whether the DFS code has an issue, by letting it pick the right freq on his own. Does that sound good? WIll be a long experiment but I can't do more testing with it, since I need it to serve a variety of services (it actually server production traffic believe it or not)

Is marvel_xor used for anything other than raid? i only use raid 0/1 which doesn't have any kind of parity operation.

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) but it gets in some weird loop triggered via interrupts? Looking at the patches it seems non-trivial, since the other CPU could be offline or many other weird things as well as race conditions could happen. I hope that it can be resolved soon with the help of the backtrace! Glad it is possible to get a dump via serial also! Thanks both for you help!

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.

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 changed I suspect this might be a race condition or a similar thing. I will try to get a diff for this kernel vs vanilla and stare at the code. I might get lucky who knows! David