tionebrr

Good move guys. Have a good one.

@cu6apumOh I clearly bookmarked that thread. It would be great to see your notes in a recap yes.

Guys, try to run your helios in whatever mode but always under 1.4GHz. I have mine set to performance and throttling from 400MHz to 1.4GHz. Uptime is 9 days now. Only two of the CPU cores can run above 1.4GHz (see these posts for reference) and that might be one of the cause of the crashes.

I can confirm, I'm running with a 400MHz to 1.4GHz range; up since 9 days.

Not sure. I changed both policies to 1.6GHz and I get the same min/max as you: Changed back to 1GHz and both policy are back the same again. Okay, and I just noticed that not all core have the same frequencies available: So maybe the policies are made to fit the available frequencies? And yep, setting the min max to 1.4GHz makes both policies equal. Not sure why some cores doesn't accept 1.6 and 1.8GHz tho. Isn't this supposed to be the same clock for every core?

I had instability too, I just dialed back on the performances and it hasn't crashed in a while. However, throttling is disabled. I fixed the cpufreq at about 1GHz. Hadn't had the time to do more testing.

@gprovost It still crashes but only after a lot more time (days). It may be a separate issue because those crashes are not ending in a blinking red led. I even suspect that the system is still partially up when it happens, but didn't verified. I've found an old RPi 1 in a drawer yesterday, so I will be able to tell more the next time it happens.

Thanks @aprayoga I'm testing this right now with governor 'ondemand' and throttling the full frequency range. Edit 7h later: Just crashed. Going back to 1800MHz locked.

Hello all, I've suspected that the freezes could be related to throttling, so I restricted the governor to only one frequency (1.8GHz) and I hadn't had a freeze since. Kind of a hammer workaround but well...

Thanks for the answer @aprayoga. Alright this I understand. Too bad for the 2.5G chips... This is interesting... I'm a hardware guy so I have no clue about how the interrupt control registers are un-masked by the kernel, and what the suspend procedure looks like. But there is several scenarios possible if the Phy is acting weird with its interrupt pin: The 1G Phy is reset before suspend, which pulls INTB low, which triggers the event, and the driver clears the interrupt before suspending? Is this possible guys?

Thanks a lot@aprayoga I'm not sure I understand which firmware you are talking about. Is this the firmware on the 2.5Gbit chip? If I understand correctly, the 1G Phy interrupt is not opendrain and is actively pushing up the shared interrupt pin preventing the 2.5G Phy to pull down? Can you share the manufacturer ref of both phys? I would love to take a look at the datasheets out of curiosity. A quick fix might be to scratch the 1G PHY int trace on the board XD

Good trick ;p

So if I understand correctly: the memory caching I've seen is not actually managed by ZFS but by the kernel?

Hello all, I'm relying quite heavily on RSS for my news feed. However I can only see two feeds on the armbian forum: New threads and posts. As you can imagine, I get quite a lot of pings for the post feed, and I'm not able to follow previous threads from the New threads feed. Is there more feeds or is it possible to add a feed per thread to the forum?

Read speed are quite hard to measure. If you test the read speed of the same file multiple times, ZFS will cache it. I'm getting up to 1GBps read speed after reading the same files 4 times in a row. Your file might also be cached if you just wrote it. By the way if someone knows how to flush that cache that would be helpful to run tests.