• Content Count

  • Joined

  • Last visited

Everything posted by Mangix

  1. Hmm I thought there were specific armbian packages. OK then.
  2. Related: 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!
  3. 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.
  4. 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
  5. 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.
  6. ksmbd is a more performant version of Samba. Located here: and Given that most devices supported by Armbian are underpowered, it would be great to get this installable via apt.
  7. @Heisathhow do I build dev kernels? only shows current and legacy.
  8. 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...
  9. @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.
  10. I will need to do more testing. .65 rebooted multiple times today... @Heisathso I actually install OpenMediaVault on top of armbian with Under OMV, I install Portainer and then install
  11. 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.
  12. Progress update: kernel 4.19.70 fails. .65 works. Testing .67 now. edit: .66 has not crashed yet. Will wait to see if it can stay alive for 12 hours. I'm trying to compile kernels based on commit. It doesn't seem to work though. I'm trying ``` --- a/config/sources/families/mvebu.conf +++ b/config/sources/families/mvebu.conf @@ -10,7 +10,7 @@ fi case $BRANCH in legacy) - KERNELBRANCH='tag:v4.19.66' + KERNELBRANCH='commit:46b306f3cd7b47901382ca014eb1082b4b25db4a' ;; ``` Which
  13. With the watchdog disabled, it does not reboot. I have a serial log with journalctl -f running. I can't see anything interesting. Anyway, I now conclude this is an upstream kernel issue. Given that I know kernel 4.19.84 works and .104 is broken, I will try to narrow the issue down. edit: nope. .84 reboots as well. Given that I know .63 works (I had multiple months of uptime), I'll try versions between .63 and .84. Starting with .70.
  14. The more I think about this the more I think it's the kernel and not the power supply. I have 4 laptop hard drives connected to my Helios4. Those only use 5V. I also only started having issues when I swapped out the kernel. Time to figure out how to build an old kernel looks like.
  15. @gprovostI bought mine in the last batch. It's been running every day. Any way to test the PSU? @HeisathLooks like no luck on the former. The latter throws an XML error.
  16. @FredKmore frequent than that.
  17. @gprovost That sounds bad. OTOH, it makes no sense that I started having these issues once I got off kernel 4.19.63. It would be interesting to bisect to see where between 4.19.84 and 4.19.104 it started failing. edit: actually, is there a .deb file for that version anywhere?
  18. watchdog is running. should I disable?
  19. Sigh false alarm. It still happens. I've learned that I can reproduce by downloading with qbittorrent in addition to watching a video connected through a Samba share. This actually reminds me of the time on my Turris Omnia that I managed to reboot the device just by watching a video through a Samba share. I wonder if the same thing is happening here... When I mentioned that I could do this with mvebu and Samba but not ksmbd, the DD-WRT developer told me it's a serious kernel issue if a userspace program can crash the kernel. I only installed linux-image-current-mvebu_20
  20. I found the issue. It's some local armbian patch that messing things up. I recently cloned and removed 5 pointless patches. That PR was merged. So I built that and same issue. Then I deleted a bunch of patches from the mvebvu-current directory. So far with this kernel, I am not getting any issues. My git status currently is this: ``` deleted: patch/kernel/mvebu-current/0044-gpio-report-all-gpios-in-debugfs.patch deleted: patch/kernel/mvebu-current/40-pci-add-irq-change-handler-sspl.patch
  21. Just happened again. Serial output shows nothing. First line is me connected and then just U-Boot. Looks like I'll have to compile my own kernel with most of the patches stripped out...
  22. Yeah. Once I got rid of kernel 4.19.63 to test newer ones, I can't get uptime longer than several hours. Maybe 2-3. As for serial, I don't have a spare laptop to hook up. Maybe I can think of something. I wonder if there's an Android app for this...
  23. I seem to have issues on my Helios 4 where it constantly reboots. I have no idea what happens just before. I assume some kind of kernel panic. Kernel 4.19.63 - works 4.19.84 - I believe works 4.19.104 and above - broken Newer ones are broken as well. This is most likely an issue with some local patch. Any way to view the history?
  24. ah not the same issue as mine then. I just tried the latest 4.19 and 5.4 kernel versions. both reboot randomly. Unfortunately now I need to find the old kernel that I was using...
  25. Is this a freeze or a random reboot? I experienced the latter during the 5.4 kernel cycle. Actually it seems to be some regression made during the 4.19 series. I'm still on 4.19.63-mvebu for that reason.