• Content Count

  • Joined

  • Last visited

About Mathias

  • Rank

Profile Information

  • Gender
  • Location
  • Interests
    Debian on RockPro64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. By the way, I've found another bug with the dev kernel (5.3.0-rc4): there is no possibility to control the fan anymore (/sys/class/hwmon/hwmon0/ does not exists anymore). It works fine on Ayufan's 5.3rc4 but not with Armbian's dev kernel.
  2. I don't know, this is Armbian's dev kernel for the Rockpro64: from apt-cache: linux-image-dev-rockchip64 - Linux kernel, version 5.3.0-rc4-rockchip64 (ie I haven't recompiled it, I just took the pre-compiled package). I'm also wondering if I'm the only one to have this problem or if this is really a bug in the dev kernel...
  3. I have always been using precompiled kernels from Armbian or Ayufan. Right now, I am on 5.3rc4 from Armbian, when I do 'cat /boot/config-5.3.0-rc4-rockchip64 | grep ZPOOL' I get 'CONFIG_ZPOOL=y'. Everything should work, I've also tried adding lz4 and lz4_compress to /etc/initramfs-tools/modules, reran initramfs and rebooted, to no avail... Here is by 'uname -a': Linux rockpro64 5.3.0-rc4-rockchip64 #5.96 SMP PREEMPT Thu Sep 5 17:01:09 CEST 2019 aarch64 GNU/Linux Mathias
  4. Hi! I've had for quite a while the following error messages at startup: [ 39.095667] zswap: default zpool zbud not available [ 39.095670] zswap: pool creation failed This has happened with various 5.0, 5.1, 5.2 and now 5.3 kernels. Any idea what I should do to fix it? Mathias
  5. Just out of curiosity (since I've also noticed this annoying behavior): the big cores' clocks should be initialized by the kernel at start or by the bootloader (uboot)? Ie is it something that should be fixed in the DTS or in uboot? Mathias
  6. Hi! On my RockPro64, I usually run Armbian with Ayufan's 5.1 kernel (it runs very well and after manually compiling the dtb file most of the error messages at startup are gone). I've tried a few days ago to run Armbian's dev kernel (5.0), and both the sdcard and my usb3 attached ssd could not be detected. The network was also missing. I have pasted the output of armbianmonitor -U here. Mathias
  7. I finally managed to understand why neither pine64 nor Ayufan could reproduce this bug: this has to do with usb autosuspend. On a freshly booted system, USB3 works perfectly fine. On a system that has been idle for a day (so the USB had time to suspend), the problem is back with tons of error messages as soon as I try to copy a few hundred Mb. This was also mentioned in this thread. [edit] The autosuspend is not the culprit... This has to do with some underpower, see this (long) thread. Sorry for the fake news and the disappointment!
  8. Replying even later... This definitely has to do with USB suspend (see this link): on a freshly booted system, no problems at all. On a system that has been running for a day (ie the USB had enough time to suspend), the problem is back with tons of error messages... [edit] The autosuspend is not the culprit... This has to do with some underpower, see this (long) thread. Sorry for the fake news and the disappointment!
  9. Jumping in a little late, but on the RockPro64 (also Rk3399), the same kind of problems happen (also very easily reproducible, it happens every single time under load). See my post on Pine64's forums. I am in contact with them (well, so far they just keep bouncing me around to another forum / email / person...) to try learning from them if they ever managed to get some sort of usb3 working on this board. Other people are also wondering if the hardware is the root cause of these issues...
  10. I'm sorry to jump into this thread, but I was wondering if there is any way to get a changelog for the kernels released by Armbian... I've just got an updated kernel to my RockPro64 (through apt dist-upgrade), but before I run some tests, I would like to have a look into the full changelog and I could not find a way to get one.
  11. I have replaced the cable by another one (freshly purchased and tested on my laptop), I still have the same problems. I've not been able to capture the backtrace this time, but at least I have some kernel messages showing how the kernel is fighting to make it work: some messages early on and then more later on (it fully crashed a few minutes later). Again, this is with kernel 4.4.174 and a JMS578 (patched firmware) based enclosure...
  12. @IgorThanks! Now I need to deliver... :-) @chweNo, I'm using a "noname" enclosure that is based around the JMS578. But again, it just works great when connected to my laptop (with Debian Buster) and always makes trouble on the RockPro. I wanted to make sure this is not a problem with power, so I used a 6A power supply (universal power supply designed for laptops) and got the same trouble. But I'll try again with this power supply and the "stable" 4.4 kernel and either come back with a big smile on my face or with a backtrace...
  13. @chweI've used the enclosure (based on JMicron JMS 578 chip) on my laptop to transfer almost 400G of data without any problems twice (with UAS mode, thanks to an updated firmware ) but as soon as it is connected to my RockPro, I can not transfer/read more than a few Gb (ie the nightly rsync of my hosted Nextcloud to my backup system was enough to trigger the bug). I've tried disabling uas (blacklisting it and checking that it was really used as "mass storage") but this was not enough to make it stable. So far, I've reverted to moving my Nextcloud to an sdcard (so the rsync does not find anything on the USB3 drive that needs syncing). If you want, I can provide a backtrace (I ssh to it and start copying data around, so when it goes down, I still have the backtrace in my ssh terminal). @IgorI would love to step in as board "maintainer" but so far, I don't have enough days as registered member... (and I can not promise to test all new stuff regularly, since I also use my board as a server, so I can not always afford to bring it down at any given time). In the mean time, I can start a thread in the forums to collect some links and information about the board.
  14. @anonymoustemp for me, no matter which kernel I use, USB3 is not stable. With Armbian's 4.4.173, I end up with kernel NULL pointer when performing "heavy" I/O on USB3 (here "heavy" means reading or writing a few Gb of data). With Ayufan's builts (4.20 or 5.0 kernels), I end up with filesystem corruption (and the system must be restarted because it is so messed up). @IgorThanks a lot for your explanations! I was actually wondering if I could offer to write some RockPro64 documentation somewhere in the wiki, Bu I am not sure where it would fit best. Would creating a RockPro64 "hardware notes" section be acceptable to the Armbian community? Thanks anyway for the good work! Mathias
  15. Mathias