Myy

Nice ! No more horrors in dmesg logs ?

Do you have the entire dmesg that comes with it ? Maybe there's some message like a broken MMU or IOMMU. Or some other messages that might indicate that the problem is not directly within panfrost. Also, did you try this patch : https://github.com/jernejsk/LibreELEC.tv/blob/linux56/packages/linux/patches/amlogic/amlogic-0001-FROMLIST-drm-panfrost-Don-t-try-to-map-on-error-faul.patch This might just crash the driver earlier though. EDIT : The patch is actually mainlined. Here's the commit (and patch) : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panfrost/panfrost_mmu.c?id=eb9d8ddbc107d02e489681f9dcbf93949e1a99a4

Looks like some memory unit not prepared correctly, based on the first faults. Did you try showing this to the folks at irc://#panfrost@irc.freenode.net ?

I extracted the HDMI patch and added it to my repository. Tested it with my screen and it works... However, as I said, I got a very standard screen (1080p) So... now, the whole idea is how to make you test this patch. @TonyMac32 do you have some time this week to prepare a kernel with this patch ?

Got it. It's this one : https://github.com/jernejsk/LibreELEC.tv/blob/updates/projects/Allwinner/patches/linux/0005-cedrus-improvements.patch#L706

Ok, turns out that the kernel was unable to find the UUID I asked for the root partition, and was waiting "forever". So, it boots, but I still can't compile FFMPEG correctly. I'm trying to determine which patch added "num_entry_point_offsets" to "struct v4l2_ctrl_hevc_slice_params"

So, I tried to adapt @Kwiboo and @jernej patches on my 5.6 branch, but this made the kernel fail to boot for no visible reason. Since I were able to boot it without the VPU patches, I'm convinced that it's their readaptation that broke something. The patches applied are here : https://github.com/Miouyouyou/RockMyy64 If someone wants to play with them and determine which one break the boot process.

Hmm, I'll try to extract and test this patch, see if that doesn't generate issues with standard HDMI screens. Then see how to let you test it on your adapter. https://github.com/jernejsk/LibreELEC.tv/blob/updates/projects/Rockchip/patches/linux/default/linux-0006-experimental.patch#L610 I'm surprised by the outstanding amount of HDMI patches that LibreELEC.tv has for Rockchip. This might need an entire directory specific for HDMI patches at this point.

Are you cross-compiling or compiling directly on the hardware ? In the second case, just set -march=, -mcpu= and -mtune= to native. Edit : Also forget about the FPU flags for ARMv8. Most ARMv8 processors are equipped with hardware FPU units.

Greetings, Here's a quick and very dirty way to use the NVMe disk for the whole system, except the boot files and kernels which will be read from the SDCard. This method is UNSUPPORTED. Meaning that if you follow this procedure and your system broke, catched fire and start attacking you in your sleep, it's on you ! The reason I keep booting on the SDCard are : This makes boot issues easier to deal with since all the files are more easily accessible. It's easy to quickly read a SDCard from a PC using a SDCard reader USB dongle bought from the local store. Meanwhile mounting a NVMe<->USB readers are not that common. It's pretty much guaranteed that the bootloader knows how to boot a SDCard. The procedure is documented here : https://gist.github.com/Miouyouyou/e78f4caa9ce3fea72430dca57a00449b Here's a copy of its content : Moving most of the system (but not the kernel) onto the NVME disk This document describes how to make the system : boot on a SDCARD load the kernel from the SDCARD mount a NVMe partition as / use / for the whole system and applications In this document folder and directory mean the same thing. The whole idea is to be able to edit the boot files easily (kernel, boot configuration, ...) in case something goes wrong, while benefiting from NVMe read/write speeds for you daily application usage. The procedure described is not "THE BEST", just the one I used that worked in my case. Here are the steps I followed to do that : Prepare a SDCARD with an Armbian image, using Etcher. Install a NVMe M.2 disk on the rear side of the NanoPC T4. Put the SDCARD in the NanoPC T4 SDCARD slot. Boot Armbian and configure your first user. Note : The 'root' account password is 1234 on first boot Create a "Linux root (ARM 64)" partition (and maybe a swap partition if you want) on the NVMe disk. Note : Linux root (ARM 64) ID is B921B045-1DF0-41C3-AF44-4C6F280D3FAE Note : The disk can be accessed through /dev/nvme0n1 Note : I used cfdisk for that matter, but any decent partitioning software will do. Format the NVMe root partition using mkfs.ext4 For example, if you just made one partition, the device node will be : /dev/nvme0n1p1 and so the command will be : mkfs.ext4 /dev/nvme0n1p1 Mount your NVMe root partition on /mnt. For example, if you just made one partition, the device node will be : /dev/nvme0n1p1 and so the command will be : mount /dev/nvme0n1p1 /mnt Do a filesystem copy of / into /mnt, while ignoring special files created on boot-time : rsync -a -H --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /mnt Use blkid on your NVMe root partition to get its UUID. For example, if you just made one partition, the device node will be : /dev/nvme0n1p1. And so the command will be : blkid /dev/nvme0n1p1 In my case, the command output was : /dev/nvme0n1p1: UUID="cbe70e76-9690-4f69-ab6e-23b887531628" TYPE="ext4" PARTUUID="c4a2536b-5092-0b4b-8178-c4215a52ac4b" Edit /mnt/etc/fstab and replace the UUID part of the line about / by the UUID of your NVMe root partition, that you just got from the last command. The line in question is somewhat like this : UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 In my case, I modified it so that it looked like this : UUID=cbe70e76-9690-4f69-ab6e-23b887531628 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 Do a copy of /boot/armbianEnv.txt like this : cp /boot/armbianEnv.txt /boot/armbianEnv.working Edit /boot/armbianEnv.txt and replace the UUID in the line rootdev=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx by the UUID of your NVMe root partition. In my case, the line was modified like this : rootdev=UUID=cbe70e76-9690-4f69-ab6e-23b887531628 Reboot and see if it worked. If it didn't, you'll have to remove the SDCard from the NanoPC T4, read it from a Linux PC, mount the boot partition, delete boot/armbianEnv.txt and copy boot/armbianEnv.working over boot/armbianEnv.txt. Then you'll be able to retry the procedure from the point were we get the UUID of the NVMe partition (step 7). If it's working, though, it's not finished ! In order to make kernel upgrades possible, we'll have to link the NVMe root partition /boot folder to the SDCard root partition /boot folder. Use blkid on your SDCard root partition, in order to get its UUID. blkid /dev/mmcblk1p1 In my case the output was : /dev/mmcblk1p1: UUID="c5dcbfc7-886b-4c98-ac2a-4d26eec089e8" TYPE="ext4" PARTUUID="d808ef5d-01" Create a directory /sdcard : mkdir /sdcard Do a backup of your /etc/fstab : cp /etc/fstab /etc/working_fstab Add an entry to /etc/fstab to mount the content of the SDCard boot partition to /sdcard automatically. In my case the UUID of that partition was c5dcbfc7-886b-4c98-ac2a-4d26eec089e8 so the line added was : UUID=c5dcbfc7-886b-4c98-ac2a-4d26eec089e8 /sdcard ext4 defaults,noatime,nodiratime,commit=600,nodev,noexec 0 1 Adapt according to your configuration. Test your /etc/fstab configuration by doing : mount /sdcard If that doesn't work, check back your /etc/fstab. If you messed up, cp /etc/working_fstab /etc/fstab Backup the /boot directory : mv /boot /unused_boot Link your SDCard boot partition boot folder to /boot : ln -s /sdcard/boot /boot Reboot one last time And now you should be able to upgrade your kernel while booted on your NVMe disk, while still being able to access the upgrade kernel and boot configuration from the SDCard. This is very useful when a kernel upgrade broke your system. That way, you just have to remove the SDCard, read it from a Linux computer, replace the broken kernel or edit /etc/armbianEnv.txt to boot temporarily on the SDCARD in order to repair the issue. Improvements /sdcard should only be mounted when boot files have to be updated. This avoid softwares trying to access the SDCard for no reasons.

Could you do this on the working part : cat /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes Also, by default, if you can connect the board via Ethernet to a DHCP server and then access tthat DHCP server (if you connect it directly to a box, check the box web UI, it generally has information about connected machines), you might be able to connect the Tinkerboard running a mainline kernel using : ssh root@ip_of_the_tinkerboard The default password is 1234

Try to get a 4.4 kernel on this board and we'll try to analyze the HDMI (PLL) frequencies used by this kernel, and then see if we can replicate them on modern 5.x kernels. It seems that PLL configuration for HDMI resolutions other than 720p, 1080p, 1440p and 2160p are still not mainlined... However, I don't own any screen that differs from these resolutions, making it really hard to test.

Hmm, there's no RAM leak visible on the logs... However, the panfrost driver is still spamming like crazy. Once the network drop happens, if you down and up the interface again, the system becomes unstable again ? Anyway, there seems to be three issues : * Panfrost spamming * Network drops * Potential memory leak leading to system crashes. I'll try to put up a network test and see if that also happen with 5.6 kernels.

What level of physical access would the attacker have ? If he can load the USB Gadget Mass Storage module, g_mass_storage , then yes, he would be able to mount any file or block device throug the USB-OTG connection. https://superuser.com/questions/1062991/linux-usb-mass-storage-emulation That's not an automatic setup, though. I don't have a Rock64 board here, so I don't know if such setup has been added on standard Armbian images for Rock64 devices.

In order to enumerate the major issues that are *still* valid now, I'm creating a 'crash dump' thread. The idea is simple, if your RK3399 board crashed recently, you just : Write what happened during the crash; Provide the link you got from sudo armbianmonitor -u , after the crash happened; Provide the content of /var/log/kern.log (if this file is present on your system) (attach it or copy the content on pastebin and link it here). No discussion here. Feel free to create a new dedicated thread afterwards to talk about the problem you encountered. Minor issues are welcome too, if they trigger a BUG message in your logs. Just state that it's a minor issue.

On some RK3288 boards, using the bootloader, it's possible to mount the eMMC as a 'pendrive' through the USB port. However, it just pass the whole drive to the remote system, which then have to mount the partitions itself. But maybe that's not the question. You're wondering if, when the system is booted, someone can plug your Rock64 board on a laptop like an USB drive, and start reading files from the encrypted partitions ?

Alright then, I'll see if I can test that this week-end. If we can have some Video acceleration on mainline kernels, with Panfrost kicking in, the only issue left with mainline kernels should be the cameras.

Alright. Still the same version of FFMPEG ? I remember that some of your patches were integrated by the FFMPEG team, but I don't know if they were all integrated. I tried brezillion version of FFMPEG, since he played with FFMPEG and the VPU too, but he got that too many branches on his git, and the rare ones I tested still had a few issues here and there.

So the main lacklusters for 5.x kernels are : VPU, Cameras... and NPU maybe ? Nobody was able to test the Hantro VPU code staged into mainline kernels ? @Kwiboo were you able to test video hardware decoding on mainline kernels with RK3399 boards (using any distro whatsoever) ?

Does anyone have a spare Hard Drive/SSD and a RockPro and can fire a stress test on the disk for a few minutes ? If that doesn't do anything, try a disk stress test + a CPU stress test.

From what I can read from the backtrace, the issue appears while invoking the 'probe' function of the snd-mtpav driver so... If you still have the same issue, could you try to blacklist snd-mtpav ( add "blacklist snd-mtpav" in /etc/modprobe.d/blacklist ). Of course, you might have no sound during the test.

By looking at the logs again, two things are sure : - The RAM got eaten by some process, same thing for the swap. - The CPU are overheating. Try to fire some system monitor thingy while watching a video, and have a look at the RAM consumed. If it goes up constantly, until reaching a point where everything goes to a crawl then crashes, we know it's due to a memory leak :/ . Given how Panfrost is invoking memory "shrinking" like crazy, I don't know if it's the real culprit, or if it just panicking.

If you still have this bug, is it possible to scroll up and get the beginning of the error. The main issue with kernel panics is that the kernel tends to output a stacktrace for each CPU... The least used ones being displayed at the bottom. So I still don't know what caused a NULL pointer dereference in the first kernel panic mentionned.

So Saturday 4th April on IRC then ? For chat services, I tried setting up a Synapse Matrix chat system using Docker these last days... It works, as long as you disable the whole "federation" thing, since the server will go down if anybody reaches a federated crowded room... That said, Matrix+Riot offers web conferencing with chat services, file exchange, Android chat app, ... I still have to test Rocket.chat though, which might be better for that task (no configuration hassles, it seems).

Hmm, it seems that panfrost might be the culprit. These "Purging ... bytes" come from the panfrost driver... $ grep "Purging " * -r drivers/s390/char/vmlogrdr.c: * Purging has to be done as separate step, because recording drivers/gpu/drm/msm/msm_gem_shrinker.c: pr_info_ratelimited("Purging %lu bytes\n", freed << PAGE_SHIFT); drivers/gpu/drm/msm/msm_gem_shrinker.c: pr_info_ratelimited("Purging %u vmaps\n", unmapped); drivers/gpu/drm/i915/gem/i915_gem_shrinker.c: pr_info("Purging GPU memory, %lu pages freed, " drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c: pr_info_ratelimited("Purging %lu bytes\n", freed << PAGE_SHIFT); drivers/scsi/ibmvscsi/ibmvfc.c: ibmvfc_dbg(vhost, "Purging all requests\n"); drivers/scsi/qla2xxx/qla_mbx.c: "Chip Reset in progress. Purging Mbox cmd=0x%x.\n", fs/ocfs2/dlm/dlmthread.c: mlog(0, "%s: Purging res %.*s, master %d\n", dlm->name, fs/coda/cache.c:/* Purging dentries and children */ tools/perf/builtin-buildid-cache.c: pr_debug("Purging %s: %s\n", pathname, err ? "FAIL" : "Ok"); Maybe the GPU, or the GPU driver starts acting up and crashes the whole machine after a while... However I have no clear idea on how to test that... the best way would be to load a WebGL benchmark and let it go, while unplugging the network, to be sure that it's the real culprit. Try running glmark2-es2 benchmark for an hour maybe ? or some other OpenGL ES benchmark and see if the slow down and crash happen ? Two of the first results for "WebGL benchmark" on Google : http://luic.github.io/WebGL-Performance-Benchmark/benchmark/cubes.html https://crypt-webgl.unigine.com/game.html Maybe the panfrost spam is just a red herring, I don't know.