Jump to content

slymanjojo

Members
  • Posts

    16
  • Joined

  • Last visited

Posts posted by slymanjojo

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

     

  2. 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?

     

     

  3. On 2/14/2021 at 9:33 PM, aprayoga said:

    Did you see any error during upgrade? If there is no error, then it should be safe to reboot.

     

    There is no automated method that i'm aware of.

    You could modify the rootdev=UUID= to point to UUID of the SATA partition.

    Modify /etc/fstab on the SATA drive, find line with /media/mmcboot , change the existing UUID to UUID of the eMMC

     

     

    sudo blkid

    use the value of UUID not PARTUUID

     

     

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

     

  4. On 2/8/2021 at 4:17 AM, FloBaoti said:

    Here is mine (not yet upgraded) :

     

     

    Maybe problem could be on rootdev UUID ? For me it refers to /dev/mmcblk1p1

    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
     

  5. On 2/8/2021 at 1:08 AM, SIGSEGV said:

    I'm having the same issue once Armbian gets installed to eMMC using the armbian-config tool [Armbian 21.02.1 Focal]

    Boots fine with the image on the microSD card, but it won't finish booting when on the eMMC (all lights solid blue and no heart beat).

     

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

  6. On 2/7/2021 at 10:51 PM, gprovost said:

    @slymanjojo Is your install on microSD card or eMMC ?

    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.

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

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

     


  9. 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?

  10. Gentlemen, 

    **Issue solved.   :thumbup:  

     

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

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

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

     

     

  13. On 11/15/2020 at 11:49 PM, gprovost said:

    In the upcoming Armbian 20.11 (Linux Kernel 5.9) USB-C DAS mode will be supported.

     

    For now only Linux Kernel 4.4 supports it, you can see how to set it up on our wiki : https://wiki.kobol.io/helios64/usb/#usb-under-linux

     

    I think this section of our wiki is not easy to find, we will have to move it a more obvious place :P

    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.

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

     

     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines