ketominer Posted May 6, 2019 Posted May 6, 2019 On 5/1/2019 at 10:48 PM, ketominer said: no luck. I'm starting to wonder if this is all not about something someone mentioned earlier, being that it's the u-boot settings slowing down the RAM that fix the problem... https://transfer.nodl.it/4bgnD/armbianmonitor.txt OK definitely not u-boot related as rc9 and rc10 has the exact same one. So the answer is somewhere in the kernel... digging deeper.
ketominer Posted May 6, 2019 Posted May 6, 2019 (edited) 4 minutes ago, ketominer said: OK definitely not u-boot related as rc9 and rc10 has the exact same one. So the answer is somewhere in the kernel... digging deeper. and when browsing the differences between the kernels, I come up with this which looks pretty promising... https://github.com/ayufan-rock64/linux-kernel/commit/063c10147b3cfc326adda195f004b130dbd11ff6 -- scrap that, it's for the 3399 so not related Edited May 6, 2019 by ketominer
Tido Posted May 7, 2019 Posted May 7, 2019 On 5/1/2019 at 10:52 AM, ketominer said: These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian work perfectly well with Ayufan kernel. Let's go back to your original point, above. Can you reproduce the situation where everything works?
ketominer Posted May 23, 2019 Posted May 23, 2019 OK after a long and painful investigation with pine64 and other people doing distributions for them + members of the community, the problem is that by default the memory runs "full" speed which is way above specs, as it should be running at 800 MHz max. We need the dmc driver and being able to setup the max clock for the memory to run these boards in good conditions.
ketominer Posted May 28, 2019 Posted May 28, 2019 Just switched to the latest nightly... seems to fix things a lot
suberimakuri Posted May 28, 2019 Posted May 28, 2019 Armbian nightly? I didn't realise it was getting built, off to check I go! :d The latest ayufan pre release suggests memory speed locked to 1600? For rockpro64 I guess? https://github.com/ayufan-rock64/linux-build/releases
ketominer Posted May 28, 2019 Posted May 28, 2019 Actually even the stable armbian is way better, it now has dmc and the ram is clocked at 768*2! Just double checked with a few fresh installs + upgrade
suberimakuri Posted May 28, 2019 Posted May 28, 2019 "Stable Armbian" being the version from February here https://dl.armbian.com/rock64/ ??
ketominer Posted May 28, 2019 Posted May 28, 2019 1 minute ago, suberimakuri said: "Stable Armbian" being the version from February here https://dl.armbian.com/rock64/ ?? yup. Armbian_5.75_Rock64_Ubuntu_bionic_default_4.4.174.7z
arox Posted June 29, 2019 Posted June 29, 2019 Hello, I received a Rock64 board 2G two days ago and suffered the most impressive failure ever : panic, freeze, failed restart, segfault ... I tried all I was able 2 think off : 3 different PSU, 3 SD card and an USB drive, 3 armbian version (and the last from yesterday) and an openelec image ... Someone got an idea - an old kernel ? - or should I consider the board defective and throw it away ? The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...)
TonyMac32 Posted June 30, 2019 Posted June 30, 2019 7 hours ago, arox said: The board was sold by "ameridroid" and is labeled :ROCK64_V2.0 2017-0713 (Quite old no ...) Not that old, although the V3 is out. Which image did you use?
arox Posted June 30, 2019 Posted June 30, 2019 Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z LibreELEC-RK3328.arm-9.1.001-rock64.img.gz Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump. One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board !
ketominer Posted June 30, 2019 Posted June 30, 2019 10 hours ago, arox said: Armbian_5.88_Rock64_Debian_stretch_default_4.4.180.7z Armbian_5.75_Rock64_Debian_stretch_default_4.4.174.7z LibreELEC-RK3328.arm-9.1.001-rock64.img.gz Armbian_5.88_Rock64_Ubuntu_bionic_default_4.4.180.7z Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182.7z The last one "seemed" a bit more stable but freezed and needed reset for rebooting and finally it crashed with mundane stack dump. One symptom is that after a crash, or just a shutdown, the board enter an endless loop of panic at startup - needs reset? or cool down? or unplug/discharge? I even cannot find a safe method to restart the board ! Try going with the 4.4.180, it's the one that gives me the best results (although not on 100% of the boards)
arox Posted June 30, 2019 Posted June 30, 2019 1 hour ago, ketominer said: Try going with the 4.4.180, it's the one that gives me the best results (although not on 100% of the boards) The board is gone to the bin ... I already try 4.4.180. Last, I tryed ayufan strech version from pine.org links : constant reboot ! Very frustrating ! From now on, never anyone of those buggy hardware anymore : raspberry or espressif. Thanks and bye at everybody !
TonyMac32 Posted June 30, 2019 Posted June 30, 2019 1 hour ago, ketominer said: (although not on 100% of the boards) @Igor :-/ @arox speaking personally (not "for Armbian") the Rock64 is a troubled piece of hardware, there are 3 revisions in the wild, each one with differences not addressed by the vendor to work together. Other options with more consistency and a bit more conservative release approach will yield better results.
znoxx Posted July 2, 2019 Posted July 2, 2019 Hi all. Need help. Updated today from 4.4.180 -> 4.4.182 Now getting permanent problem with bypassing network interface to LXC container (worked flawlessly on 4.4.180). sudo lxc-device -n tbng add wlx0092d00ddb46 command failed: Operation not supported (-95) lxc-device: tbng: tools/lxc_device.c: main: 172 Failed to add wlx0092d00ddb46 to tbng Same for trying to pass phy0 to network namespace zno@armbox:~/_working_kernel$ sudo iw phy phy0 set netns 7094 command failed: Operation not supported (-95) I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure). Thanks in advance for your help.
Igor Posted July 2, 2019 Posted July 2, 2019 4 hours ago, znoxx said: I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure). Driver for 8188 was changed with this commit. It should be better but I guess it could also be as step back
znoxx Posted July 2, 2019 Posted July 2, 2019 3 hours ago, Igor said: Driver for 8188 was changed with this commit. It should be better but I guess it could also be as step back Igor, thanks for confirmation. Looks like pure driver issue. I put good old ralink 5370. Works like charm and my macos started to connect to AP, instead of password loop on Realtek 8188EU. One small thing, not indeed rockchip related - diode on ralink usb wifi does not blink =). Bad thing - my heap of unused Realtek 8188eu adapters just got bigger.
Igor Posted July 2, 2019 Posted July 2, 2019 3 minutes ago, znoxx said: Bad thing - my heap of unused Realtek 8188eu adapters just got bigger. I try to keep wireless support as good as possible, but time to play with is always a problem. I am happy that most of my test devices work quite well and I will check if something can be done regarding 8188EU when time permits. Perhaps its time to make an upgrade to AC capable 8812 or at least 8811 ?
znoxx Posted July 2, 2019 Posted July 2, 2019 3 hours ago, Igor said: I try to keep wireless support as good as possible, but time to play with is always a problem. I am happy that most of my test devices work quite well and I will check if something can be done regarding 8188EU when time permits. Perhaps its time to make an upgrade to AC capable 8812 or at least 8811 ? Well, my "demand" is quite exotic. Not so many people use wifi dongle inside LXC container. Not sure one should invest his own time into _such_ investigation. Regarding the speed - container runs "TorBox" (http://tbng.ml), and TOR does not give you super-fast connection. But well, indeed it's time for upgrade to something more 2019 related.
lomady Posted September 27, 2019 Posted September 27, 2019 Sharing a bit of feedback: I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things. Hope this helps. 1
TonyMac32 Posted October 1, 2019 Posted October 1, 2019 On 9/27/2019 at 1:55 PM, lomady said: I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 Sigh... My guess (entirely guessing, I have not looked yet), is that we or Mainline fixed the Rev 3, which broke the Rev 2. I am not entirely pleased at the significant hardware changes made by Pine in this case, it is causing problems... 2
Tamás Faragó Posted October 14, 2019 Posted October 14, 2019 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!
martinayotte Posted October 15, 2019 Posted October 15, 2019 17 hours ago, Tamás Faragó said: This is driving me crazy! Which revision ? Mine, which is Rev 1.1, is now up since 60 days with kernel 5.2.0, although not running much applications. I'm planning to upgrade to 5.4.0-rc1 soon ... EDIT: The upgrade to 5.4.0-rc1 is now done ...
WrongWorld Posted October 15, 2019 Posted October 15, 2019 19 hours ago, Tamás Faragó said: Anyone has a reliable kernel version for the rock64? For which OS? I have a Rock64 V2 running 24/7 Ubuntu Bionic with kernel 4.4.192 (Armbian Bionic 5.98), which I have recompiled myself to add back a driver, and it seems pretty stable as of now. With the previous versions I used to have some sporadic zram0 errors, but it's now two days of uptime since my last reboot and I haven't seem them.
Tamás Faragó Posted October 16, 2019 Posted October 16, 2019 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).
jpegxguy Posted October 16, 2019 Posted October 16, 2019 I've been using Arch Linux Arm with the generic linux-aarch64 kernel for a while now on my LibreComputer Renegade. Works nicely and I don't have to stay with an outdated vendor kernel. That said, I use it as a headless server. I don't know what limitations there would be when it comes to graphics performance.
Tamás Faragó Posted October 23, 2019 Posted October 23, 2019 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 failed! err=-22, page=31 Oct 23 00:08:26 hattusa kernel: [ 307.008483] Buffer I/O error on dev zram0, logical block 31, async page read Oct 23 00:08:51 hattusa kernel: [ 332.477720] zram: Decompression failed! err=-22, page=31 Oct 23 00:08:51 hattusa kernel: [ 332.477738] Buffer I/O error on dev zram0, logical block 31, async page read Oct 23 00:09:00 hattusa kernel: [ 340.704780] zram: Decompression failed! err=-22, page=31 Oct 23 00:09:00 hattusa kernel: [ 340.704799] Buffer I/O error on dev zram0, logical block 31, async page read
Tamás Faragó Posted October 25, 2019 Posted October 25, 2019 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: Spoiler and again Spoiler
daviddyer Posted November 5, 2019 Posted November 5, 2019 Well, the specs of rock64 looks good, until you use it to do some actual work... It even can't survive make -j 4 for aria2
Recommended Posts