Tamás Faragó

Members
  • Content Count

    11
  • Joined

  • Last visited

  1. Hi Igor, that is going to be quite difficult. If it was easy the people over at the sunxi kernel would have updated the kernel already. Unfortunately I am stuck with this kernel. It is really unfortunate that the legacy images for jessie cubieboard were removed from the repo which made things a lot more difficult to figure out. Please find attached my diff that was needed to get it to work along with some comments. I realise that jessie support is dropped so most of these changes will not be merged but I think it's still good to have a look through. aptly-temp.conf is missing
  2. Hi Igor, I know Jessie is not supported but my board only works correctly with Jessie (cubieboard1 only works with mmc on the sunxi legacy 3.4 kernel. Stretch and higher don't work on on the 3.4 kernel as systems depends on >= 3.13). There is no jessie images on armbian so I decided to build my own (using he amazing armbian-tools!) from a historical version on git that still supports jessie. The problem is that tools like mmc-utils, u-boot-tools, etc are in the apt.armbian jessie repository which is gone. Is there an archive somewhere of the armbian jessie repo, and
  3. Well, your box hasn't crashed so it's good I'll compare the numbers once I'm at home. I tried 5.x before but it wouldn't recognise the USB3 port so I quickly have up. Might give it another shot! Although I'm a bit lost in the DTB world and wouldn't have a clue what to change.
  4. Interesting, maybe Ubuntu is doing something else? Can you try "sudo cat /sys/kernel/debug/mmc0/ios" ? You need to install stress-ng, eg. "apt install stress-ng". Thanks!
  5. Hey, thanks! That is useful! I will try 5.69, maybe it is more useful and I don't have to do the below. I have not been idle and did a lot of experimentation as well. With 5.98 at least the only thing that consistentlyDpkg::Use-Pty=0 helped is to underclock the CPU to 1.2GHz. It is pretty much stable even during heavy IO using the uas driver. @rock68 could you check your cpu, memory speeds and clock frequency for me as well as run a cpu test? sudo cat /sys/kernel/debug/mmc0/clock sudo cat /sys/class/devfreq/dmc/cur_freq sudo cat /sys/devices/system/cpu/
  6. So, I'm out of ideas now. I have done all of the above, in-fact mounted the whole filesystem (eg. /root) as RO so definitely there are no writes happening on the EMMC card (double checking with iostat -dzp 1). And _still_ the board crashes! This is debian Buster with Armbian 5.98 Linux 4.4.192-rockchip64. Debian Buster with Armbian Linux ttyS2 hattusa login: [ 136.670721] Unable to handle kernel paging request at virtual address 1dd659848 [ 136.670724] Unable to handle kernel paging request at virtual address 1dd644848 [ 136.670728] pgd = ffffffc0ec1f5000 [ 136.670739] [1dd64
  7. I am quite upset. Reading around more it looks like the FORESEE emmc cards sold on the rock64 shop are utter crap. The only reason I bought them from their shop because I trusted them to deliver good quality components with the board. Teaches me right. I contacted support about the card, they waived me off with "you only have 30 days guarantee, but anyways you should limit the number of writes to the card as otherwise you can kill it within a week". Thanks for that. I've read around a bit more and my last hope is a few more tweaks before I give up and just buy a raspberry pi. 1. Lower the
  8. Not much luck even with armbian. With any process that involves heavy IO (on the USB) the board just panics and dies. And by heavy IO I mean something like syncthing or resilio sync indexing my shared albums. I get this during boots ERROR: suspend_mode_handler: unhandled sip (0x1) ERROR: suspend_mode_handler: unhandled sip (0x4) Is there anyway I can debug this, or at least find out what the cause is? When the sbc dies: and again
  9. Thanks a lot, this helped immensely. I installed the latest ubuntu-bionic 5.90 headless version which was 4.4.182 kernel. After a system update it went up to 4.4.192 and things seem quite stable. Although during heavy USB3 disk access - like resilio-sync scanning - there is the occasional kernel panic, but the machine is usable. Oct 23 00:08:26 hattusa kernel: [ 307.008233] zram: Decompression failed! err=-22, page=31 Oct 23 00:08:26 hattusa kernel: [ 307.008290] zram: Decompression failed! err=-22, page=31 Oct 23 00:08:26 hattusa kernel: [ 307.008463] zram: Decompression fa
  10. Thanks guys. Any debian-based distribution would be fine, be it armbian, or ayufan version or even Ubuntu. I tried in the past to update to kernel 5 but it failed to recognize my usb3 hdd so I went back to version 4. I'll have to check the version of the board when I get home but I remember it saying v2 on the back (I bought it in March 2018).
  11. Anyone has a reliable kernel version for the rock64? Any I have tried are kernel panicking like crazy I cannot have it up longer than a few minutes. The most stable kernel I have 4.4.133 but even that does intermittently during (heavy) IO on the USB3. Power is supplied through the power supply from pine.org so that should be good. This is driving me crazy!