Jump to content

FrancisTheodoreCatte

Members
  • Posts

    4
  • Joined

  • Last visited

Everything posted by FrancisTheodoreCatte

  1. Sorry @gprovost, didn't see your message until today. Anecdotally, as soon as I reenabled the automatic CPU governor, the Helios4 kernel panicked within 8 hours. Unfortunately I didn't have the serial console open to catch a trace. Anyway, I rebooted my Helios4 with the Marvell XOR driver blacklisted. Nothing shows up under /proc/interrupts related to XOR now. Running a serial console again to hopefully get a trace if it crashes. Unrelated to the crashes, but I think I ran into a bug with the Debian Buster armhf build of btrfs-progs 4.20.1. Trying to delete subvolumes on my 17T btrfs volume is impossible-- btrfs subvolume delete gives me "ERROR: Could not statfs: Value too large for defined data type". I found a post from someone using Raspbian buster over on the Raspberry Pi forums with the same issue with large btrfs volumes: https://www.raspberrypi.org/forums/viewtopic.php?t=249873 I haven't tried btrfs-progs 4.7.3 from Stretch as they did to see if the problem persists, yet. If anyone else with a large array in a Helios4 with Debian Buster and a large btrfs volume could try creating and deleting a subvolume, I'd appreciate it. I'm assuming this would have to be filed as an Armbian bug report, or possibly upstream??
  2. Update; two straight days with no lockups after setting the CPU clock to 1.6GHz.
  3. I've pinned the clockspeed to 1.6GHz (800MHz makes Plex unhappy). I'll leave it for a while with the serial console open and see what happens. My experience has been at least a crash a day.
  4. After upgrading to the 4.19.104-mvebu kernel I also started experiencing the same complete cpu lockups, but here's the kicker: the lockups are continuing, even after downgrading to kernel 4.14.171-mvebu. Easy way for me to trigger it is by running echo check > /sys/block/md0/md/sync_action I managed to catch the CPU stall via the serial console: https://pastebin.com/C8yCQMAn Here's the output from armbianmonitor -u: http://ix.io/2h03 edit: same lockup still happens when running an md data-check even after downgrading further, to 4.14.153-mvebu.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines