… it crashes all the same. Sigh.
Going to sleep, out of ideas for now.
1 Like
I just try enable crypto manager test, and reboot. Now my board is offline 
That’s fine, I will check the serial console on Monday.
1 Like
Using KMS for video playback gives an “almost” smooth 4k playback. Better than above wayland test at least.
gst-play-1.0 --videosink='kmssink bus-id=soc:display-subsystem' *2160p*mkv
the bus-id comes from /sys/bus/platform/devices/
1 Like
do you got the same?
[ 1.559102] usercopy: Kernel memory overwrite attempt detected to spans multiple pages (offset 0, size 47)!
[ 1.569915] kernel BUG at mm/usercopy.c:99!
[ 1.574518] Kernel BUG [#1]
[ 1.577584] Modules linked in:
[ 1.580941] CPU: 1 PID: 56 Comm: cryptomgr_test Not tainted 5.15.2-cwt-3.6.1-2 #1 e3984e3990034972d4e60d2cf44186bef1c33407
[ 1.593100] Hardware name: StarFive VisionFive V2 (DT)
[ 1.598748] epc : usercopy_abort+0x6e/0x70
[ 1.603266] ra : usercopy_abort+0x6e/0x70
[ 1.607774] epc : ffffffff8021e12c ra : ffffffff8021e12c sp : ffffffd0043f3930
[ 1.615727] gp : ffffffff81bdbe70 tp : ffffffe0c06fee40 t0 : ffffffff81c124ef
[ 1.623680] t1 : ffffffff80c07c30 t2 : 0000000000000000 s0 : 000000000000002f
[ 1.631633] s1 : ffffffe0c015cfe0 a0 : 000000000000005f a1 : e8c280eef4fced00
[ 1.639585] a2 : e8c280eef4fced00 a3 : 00000000ffffefff a4 : ffffffff81a3e6b8
[ 1.647538] a5 : 0000000000000fff a6 : ffffffff81a3e6d0 a7 : 0000000000000059
[ 1.655490] s2 : 0000000000000000 s3 : ffffffe0c015d00e s4 : 0000000000000000
[ 1.663442] s5 : 0000000000000000 s6 : ffffffe0c015d00f s7 : ffffffff8177d840
[ 1.671407] s8 : ffffffff8177d878 s9 : ffffffff81be2170 s10: 0000000000000000
[ 1.679369] s11: ffffffe0c015cfe0 t3 : 0000000000000075 t4 : ffffffffffffffff
[ 1.687332] t5 : 0000000000000007 t6 : 0000000000000000
[ 1.693176] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[ 1.701905] [<ffffffff8021e12c>] usercopy_abort+0x6e/0x70
[ 1.707848] [<ffffffff8021e400>] __check_object_size+0x2d2/0x352
[ 1.714462] [<ffffffff804a1638>] build_test_sglist+0x4f0/0x5b0
[ 1.720897] [<ffffffff80493f58>] crypto_has_alg+0x62/0x66
[ 1.726840] [<ffffffff804a23b8>] __alg_test_hash+0x2f0/0xfe8
[ 1.733089] [<ffffffff8049ed6a>] alg_test_hash+0xae/0x272
[ 1.739031] [<ffffffff8049dc82>] alg_test+0x146/0x316
[ 1.744590] [<ffffffff80c03cb2>] __schedule+0x68e/0x8c4
[ 1.750354] [<ffffffff8049daf0>] crypto_alg_put+0x30/0x34
[ 1.756295] [<ffffffff8049db16>] cryptomgr_test+0x22/0x48
[ 1.762234] [<ffffffff800333dc>] kthread+0x138/0x154
[ 1.767704] [<ffffffff800332a0>] kthread_blkcg+0x12/0x16
[ 1.773549] [<ffffffff80003a64>] ret_from_syscall_rejected+0x8/0xc
[ 1.780457] ---[ end trace 4ffa84279a9a2454 ]---
1 Like
Yeah, note:
Not identical (likely due to llvm vs gcc), but close enough.
There ware a bug related to crypto Linux Kernel Crypto API produces garbage for AES · Issue #25 · starfive-tech/VisionFive2 · GitHub, but it was fixed since Release VisionFive2 Software v2.10.4 · starfive-tech/VisionFive2 · GitHub.
I’m building the Python 3.11 as described in the issue 25, and will run the tests.
Update: The tests passed, skip 1.
1 Like
Maybe the old bug is back in some shape or form, maybe it’s broken in some new way.
I just saw that I didn’t enable two crypto options:
diff -r b4ee89944573 config
--- a/config Fri Sep 01 12:32:37 2023 +0700
+++ b/config Mon Sep 04 12:31:04 2023 +0700
@@ -7348,8 +7348,8 @@
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
-# CONFIG_CRYPTO_DRBG_HASH is not set
-# CONFIG_CRYPTO_DRBG_CTR is not set
+CONFIG_CRYPTO_DRBG_HASH=y
+CONFIG_CRYPTO_DRBG_CTR=y
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
So, the new kernel is being build with these two options, but I don’t think they are related to the bug you found. Anyway, please feel free to test the new kernel when the building is done.
2 Likes
@rvalles done, the new kernel is here: Release cwt16 3.6.1-2 · cwt/pkgbuild-linux-cwt-starfive-visionfive2 · GitHub
Now all Python LinuxKernelCryptoAPI tests are passed.
How about the kernel’s builtin CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n thing?
Booting my VF2, gonna try that kernel.
Ah, the last time I enabled that option, the kernel won’t boot.
Let me try enable it and start the build while I’m on the way home.
It boots, but it’s the same deal as usual. I enter the passphrase on boot to unlock the LUKS containing my /home, and it unlocks (meaning passphrase was correct), but I get garbage instead of the filesystem:
[root@starfive ~]# cryptsetup status linux-home
/dev/mapper/linux-home is active.
type: LUKS2
cipher: aes-xts-plain64
keysize: 512 bits
key location: keyring
device: /dev/nvme0n1p7
sector size: 512
offset: 32768 sectors
size: 1819723776 sectors
mode: read/write
[root@starfive ~]# file -sL /dev/mapper/linux-home
/dev/mapper/linux-home: data
I am going to try something to debug this, shortly. Want to be sure it’s the encryption system fault.
Followup, what I did is export the block device via nbd, import the block device on my linux laptop, and cryptsetup luksOpen there.
Turns out, it seems to have nothing to do with the new kernel’s cryptography after all.
[root@yukino rvalles]# file -sL /dev/mapper/linux-home
/dev/mapper/linux-home: data
And the data is garbage. What’s worse is that it looks like random data. It was an ext4 filesystem, but none of the superblocks are readable.
This was /home (lives in a partition in my nvme SSD), and the last thing I had done was install the three kernel packages that I had just built, systemctl poweroff, mount microsd on laptop, make a copy of the /boot stuff, update the microsd I had been using to boot from to the current official debian image, edit the extlinux menus and copy the kernels back to the updated microsd.
The old kernel doesn’t boot anymore (early panic before touching the disks), likely to do with newer updated spl/opensbi/u-boot.
There’s nothing actually important in that /home fortunately, but I do not know what happened to cause this result.
But I have some hypothesis.
The old kernel’s cryptography was somehow broken; Able to encrypt/decrypt… using the wrong key. Encrypted key support broken, XTS broken, who knows. The new kernel’s behavior is likely correct, so old data is decrypted into random-looking data.
Might even be related to the ancient bug you found and linked to.
I will sleep now, not sure how to proceed. I might want to try and boot the old kernel again somehow, or I might just nuke the partition and start again. I had nothing of value in there anyway.
2 Likes
FWIW, the 3.6.1-2 kernel mounts / accesses an old LUKS disk I made some time ago (created on x86_64).
1 Like
@rvalles with this kernel option, my board is offline again. I think it’s really not working for me.
1 Like
Good to know. I’ll just nuke my /home and start again.
Arch packages for hardware video encoding / decoding with the venc / vdec / jpu kernel modules.
Binaries and PKGBUILD
https://github.com/leuc/vf2-soft_3rdpart-aur/releases
https://github.com/leuc/ffmpeg-omx-aur/releases
All are required:
codaj12-3.6.1-1-riscv64.pkg.tar.zst
wave420l-3.6.1-1-riscv64.pkg.tar.zst
wave511-3.6.1-1-riscv64.pkg.tar.zst
omx-il-3.6.1-1-riscv64.pkg.tar.zst
ffmpeg-omx-4.4.4-1-riscv64.pkg.tar.zst
Example Usage:
/opt/ffmpeg-omx/bin/ffmpeg -vcodec h264_omx -i ~/in.264.mp4 -vcodec hevc_omx -b:v 8M ~/out.x265.mp4
Encoding speed is slightly above real-time.
Kernel: 5.15.2-cwt-3.6.1-1
PKGBUILD for gst-omx with patches will be next.
3 Likes
Fantastic!
RT encoding of hevc on a < £100 SBC is pretty amazing, especially if this is all open source. Can it encode at UHD OK?
Will try this ASAP! Thanks!
x265 UHD to x265 UHD speed=0.571x
x264 FHD to x265 FHD speed=2.08x
x265 FHD to x265 FHD speed=1.79x
Encoding to x264 is not supported.
Tried an odd “h264 (High), yuv420p(tv, bt709, progressive), 1280x690” as input and that failed.
2 Likes
Thanks for sharing those encoding stats.
-
Are you using a custom xorg.conf file? If so, what does it look like?
-
Are you using a display manager? Which one? Did you have to configure it get it to work? Do you have your DM configured to start on boot or do you start it manually?
-
Which Wayland compositors and/or X desktops/wms have you tested with ffmpeg-omx video playback? Have you tested UHD and/or 4K hevc playback on a 4K or UHD display?
I have installed the latest cwt but I haven’t been able to get lightdm to display anything yet on my 1080p display. I have tried the following config in /etc/X11/xorg.conf.d/10-fb.conf with no luck:
Section "Device"
Identifier "Screen0"
Driver "fbdev"
Option "fbdev" "/dev/fb0"
EndSection
The other big problem I have with this latest cwt is that I can’t run pacman -Syu because mesa-pvr-vf2 depends on an older llvm version.