slymanjojo

@gprovost Been Running stable since 21.02.3 Buster. cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand No VDD tweaks.

@ShadowDance Thanks for sharing. Not certain what would make the system non responsive.... - I did play with the with my external enclosures to have HD's spin down with specified timer. ** And thank you for reminding me, looks like I had already asked the same question. (I must be getting old) The constant seems to be IRQ of 8. Tried: cat /proc/interrupts (nothing showing for 8) -Any idea how to determine what is being impacted? (fan, USB etc..)

Curious if anybody else with tick-stop error? Not certain if this applies; the only change is installing Docker and Pi-Hole containerized. A quick read seems related to a soft interrupt of 8; - The only solution I could find by googling; is: "Add nohz=off to the kernel parameters during boot to disable it." Can I safely ignore this error message; or should I do this nohz=off to the kernel parms?

@aprayoga Thanks for the feedback. I've left everything (rootdev) on the eMMC for now. I was contemplating installing omv; Is there enough space on eMMC ?? I assume omv is installed as a service and I could move it and use a symbolic link.

Interesting my differs with the added usb quirks: verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=e31a658f-424d-4411-9c4d-e96f42117d3f rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x331a:u,0x0bc2:0x3322:u,0x0bc2:0xab38:u,0x0bc2:0xab44:u,0x0bc2:0xab45:u

Note: I used the armbian-config tool on Buster. with the same outcome.

Yes, Boot Device eMMC , System/Rootfs using SATA drive. For some reason I was not able to recover using my previous SDcard; Downloaded latest build and rebooted without issue: from SDcard. I ended up resolving my issue by running armbian-config and moved boot and system onto the eMMC. I did not want to go through the reformatting of my SATA drive. (no option using tool to install without reformatting) This permitted me to mount and access the older rootfs and copy over my fstab, smb.conf etc... over to the new location eMMC. There was probably an easier solution? possibly just re-create this armbianEnv.txt and point my rootfs back to my SATA drive. Not knowing the integrity of what failed during the upgrade... I did notice a wack of missing files. during the upgrade. I had to act fast; I was not anticipating to have any issues with this upgrade. Thanks for all your replies.... I will admit I was caught with my pants down. Curious; What would be the suggested method to move my rootfs back to my SATA drive without reformatting (currently ext4)?? basically go back to my initial config with boot on eMMC and rootfs on SATA. Thanks in advance.

I have the same issue after upgrading....... stuAck in Starting Kernel; all lights solid blue and no heart beat. --snip-- Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 13856663 Bytes = 13.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f51af000, end f5ee5f97 ... OK Loading Device Tree to 00000000f5132000, end 00000000f51aefff ... OK Starting kernel ... --end snip- Sorry if this is NOOB question; where can I find this armbianEnv.txt ? when performing upgrades is this file backed up anywhere? How do I go about getting my system back online? Any help would be much appreciated.

@ShadowDance Thanks for the reply. I have not been getting many of these so I will keep monitoring this over the next few weeks. - Not certain if it was related to recent testing I was doing with: Jellyfin it was chewing-up plenty of CPU even with direct play -I have un installed it. Helos64 turns out to be a poor choice for streaming server (tested: emby, jellyfin, plexserver)

Anybody have an idea what these message being written to dmesg?! Linux Hell64 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux -snip- [Wed Dec 9 04:37:51 2020] NOHZ: local_softirq_pending 08 [Wed Dec 16 22:54:43 2020] NOHZ: local_softirq_pending 08 [Thu Dec 17 02:35:38 2020] NOHZ: local_softirq_pending 08 Anything to be alarmed about?

Gentlemen, **Issue solved. @gprovost; I tested with ext4 and now max out gigabit; PC --> Helios64 over SMB or FTP --> and. USB 3.1 UAS - I had no idea how bad NTFS was, and how much of a penalty hit. ** Thanks for testing, saved me the trouble of trying to tweak samba and mocking up things for no reason. @Werner; Yes my main concern was portability and flexibility ; I have two 8bay DAS enclosures with 8TB disks all partitioned with NTFS. and I do use WIN 10. - I might fall into the lazy category but having 23 disks of at least 8TB; to backup and restore this amount of data is a daunting task. sheer amount of time required to backup and restore.... - I read up on zfs; I was very tempted but seems some folks complaining of some issues in other posts. - As you mentioned about WIN10 and ext4. I did find Ext2Fsd but have not tested this yet. do you know of any win10 solution for rw access to zfs? Gentlemen, thank you for your great support and help. Enjoying my learning experience: This Helios64 turning out to be a great project!!! Cheers!

Thanks for your response! No.. Not using OMV. (Was not certain if I loaded OMV if it would wipe out my huge collections of Movies/TV-Shows so played it safe; I think I read somewhere OMV will not work with NTFS and will want to reformat.) - 5x SATA mounted using fstab. Here are the results of the FTP tests. I get 39.57MB/s (far cry than expected 113MB/s over GIG) but consistent with my SMB tests. -snip- 226 Transfer complete. ftp: 17242487284 bytes sent in 435.70Seconds 39573.77Kbytes/sec. ftp> -end snip- ** Do you think the issue is SMP affinity????? If yes; any suggestions? Looking at cat /proc/interrupts; CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 27: 1701696 0 0 0 0 0 GICv3 44 Level eth0 I can see eth0 is served by CPU0 (INT 27) could not find which interupt is being used by sata; I assume also served by CPU0 ? Tried reading a little on SMP affinity and on CONFIG_HOTPLUG_CPU. Not sure what tweaking is required if any!? *** should I entertain to move the eth0 27 INT over to CPU1 ? *** Is this how it is done? echo "2" > /proc/irq/27/smp_affinity I have no idea what I am doing; Please advise... will this be optimized in upcoming Kernel 5.9? or... any suggestions for tweaking would be very helpful.

Linux Hell64 5.8.17-rockchip64 #20.08.21 SMP PREEMPT Sat Oct 31 08:22:59 CET 2020 aarch64 GNU/Linux I've been testing the performance and comparing to another NAS I have (WD PR4100) and the Helios64 performance has not been fairing well. Setup are almost identical on the same switch connected gig ethernet. Using SAMBA ,NO Raid. Testing with SATA drives HD's previously formatted for NTFS. and UAS USB 8 Bay DAS. Reading from Helios64 to Windows 10 PC I achieve expected 113MB/s and from USB attached to Helios 110MB/s. Writing speeds are very poor and as can be expected worse on the directly attached USB DAS. WIN10 -> Helios64 eth0 SAMBA ----------------------------- Test 1= ~ 45MB/s Test 2= ~ 41MB/s WIN10 -> Helios64 USB (UAS NTFS) Test 3= ~ 8-38MB/s (Fluctuate like a yoyo back and forth between 8 and 38MB/s) To give you a comparison with my WD PR4100 IN10 -> WD PR4100 NAS GIG eth0 SAMBA ---------------------------------- Test 1= ~ 109MB/s (write) Test 2= ~ 105MB/s (write) PR4100 -> WIN10 PC GIG eth0 SAMBA ------------------------------------ Test 3= ~ 112-123MB/s (Read) Test 4= ~ 113MB/s (Read) If I run the hdparm -tT on the directly attached and USB drives the performance is as expected. Trying to determine why such the poor performance from the helios64 NAS compared to the WD PR4100. /dev/sdc: (Directly attached SATA drive; NTFS) Timing cached reads: 2478 MB in 2.00 seconds = 1238.83 MB/sec Timing buffered disk reads: 710 MB in 3.01 seconds = 236.11 MB/sec /dev/sdm: (USB UAS DAS) Timing cached reads: 2240 MB in 2.00 seconds = 1120.03 MB/sec Timing buffered disk reads: 550 MB in 3.01 seconds = 182.87 MB/sec

Thanks I've downgraded to Linux Kernel 4.4 to test it out; will use referenced URL thank you. Is there an ETA for 5.9? Again thanks for your support.

Has anybody got DAS mode working using USB-C ? Using: Armbian 20.08.21 Buster with Linux 5.8.17-rockchip64 I was not certain, I thought I read it was supported. I was hoping to use Windows 10 via USB 3.1 --> Helios64 USB-C to copy large video library. Note; using UART via COM3 is working as expected. Note; in windows I do remember seeing some USB error loading some USB driver; would it be related to some missing driver?int Any successful implementation of USB DAS interface; I would be happy to hear from you.