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 eas

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

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

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 issu

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 a

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.