Moving Linux Kernel to 5.10

[Gavinmc42]

Pi3 and Pi4 decode HEVC in totally different ways. Pi4 has dedicated hardware. Pi3 reuses H264 hardware that it can, but otherwise uses the VPU and QPUs to accelerate other parts of the decode.

I thought the Pi4 was using the Arm cores to decode H.265?
Is there "dedicated" hardware for this?

[6by9]

Pi3 and Pi4 decode HEVC in totally different ways. Pi4 has dedicated hardware. Pi3 reuses H264 hardware that it can, but otherwise uses the VPU and QPUs to accelerate other parts of the decode.

I thought the Pi4 was using the Arm cores to decode H.265?
Is there "dedicated" hardware for this?

Yes.
See driver at https://github.com/raspberrypi/linux/tr ... dia/rpivid, enabled via https://github.com/raspberrypi/linux/bl ... verlay.dts. It uses the V4L2 stateless decoder API.

[Aardappeltaart]

Title of #4112

So why are you commenting there when your problem is on a Pi4? Conflating unrelated issues is not helpful.

Because of this?
viewtopic.php?f=66&t=251645&start=475#p1830032

And because maybe the Github issue is related, and the title is just not 100% correct. In OP 4112 it is stated that RPI4 is playing HEVC files fine, which is not the case.

Pi3 and Pi4 decode HEVC in totally different ways. Pi4 has dedicated hardware. Pi3 reuses H264 hardware that it can, but otherwise uses the VPU and QPUs to accelerate other parts of the decode.

I just give a plausible reason why Pi4 users are commenting on the github thread.

Maybe it's not clear to users that the RPI3/RPI4 issues are not related: HEVC playback is broken on kernel 5.10, that's what they experience.

[greg.ooi]

For HEVC 4K video playback/hardware decoding ... try
Libreelec 10.0 (build 19.1.0) compiled 2021-06-04 RPI4
GPU: V3D 4.2
OpenGL : OpenGL ES 3.1 Mesa 21.0.3
(Linux Kernel 5.10.x)

https://test.libreelec.tv/
https://test.libreelec.tv/LibreELEC-RPi ... d15.img.gz

HEVC playback was seamless and impressive. Just works on RPI4 and CM4 4G mem.

[dickon]

I've had 8b 4k HEVC playback on 5.10.17-v8+ flawlessly in vlc on the console. Works well.

[dom]

There's a potential fix for the 1-pixel wrap issue when using kms in latest rpi-update kernel.
If you are currently seeing this issue, then we'd be interested in reports of behaviour after updating.

[chrisy]

There's a potential fix for the 1-pixel wrap issue when using kms in latest rpi-update kernel.
If you are currently seeing this issue, then we'd be interested in reports of behaviour after updating.

I was seeing this immediately before the update. Updated, rebooted, and now it's OK. I'll report back if it breaks again.

[bunklung]

Can dtoverlay=vc4-kms-v3d be used on 5.10.17-v7l+ #1421 without ill effects?

I recall testing this a while back and got a black screen on a PI4.

Thanks.

[andrum99]

Can dtoverlay=vc4-kms-v3d be used on 5.10.17-v7l+ #1421 without ill effects?

I recall testing this a while back and got a black screen on a PI4.

Thanks.

The best way to answer that is to run it: fire up that spare SD card

[bunklung]

It's using an SSD, so I don't know how it would be recovered which is why I am asking.

[private]

There's a potential fix for the 1-pixel wrap issue when using kms in latest rpi-update kernel.
If you are currently seeing this issue, then we'd be interested in reports of behaviour after updating.

I am running ArchlinuxARM with the RPI 64bit kernel (5.10.46, commit 9b672c5441497337f286686122a6f17fd7985cc2) and EEPROM

Code: Select all

BOOTLOADER: up to date
   CURRENT: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
    LATEST: Thu Apr 29 16:11:25 UTC 2021 (1619712685)
   RELEASE: critical (/lib/firmware/raspberrypi/bootloader/critical)

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

I can confirm that the 1-pixel-wrap issue no longer persists.

[CaptainMidnight]

Just as an observation, latest rpi-update kernel build (5.10.50) 64bit appears to cause a firmware timeout trace on boot up, but otherwise results in a working system. Out of the 3x test units (2x Pi4B2 and 1x Pi4B8) which are used for general upgrade and kernel/firmware upgrade testing, only the Pi4B2 units encountered this issue. All units are configured for headless operation.

Details of the crash report : -

Code: Select all

 
[    3.389628] ------------[ cut here ]------------
[    3.389639] Firmware transaction timeout
[    3.389708] WARNING: CPU: 1 PID: 187 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xdc/0x108
[    3.389710] Modules linked in: cfg80211 rfkill 8021q garp stp llc vc4(+) cec v3d drm_kms_helper gpu_sched drm drm_panel_orientation_quirks raspberrypi_hwmon i2c_brcmstb snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd syscopyarea sysfillrect sysimgblt fb_sys_fops backlight uio_pdrv_genirq uio nvmem_rmem i2c_dev aes_neon_bs sha256_generic aes_neon_blk crypto_simd cryptd ip_tables x_tables
[    3.389793] CPU: 1 PID: 187 Comm: systemd-udevd Not tainted 5.10.50-v8+ #1438
[    3.389796] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
[    3.389800] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[    3.389804] pc : rpi_firmware_transaction+0xdc/0x108
[    3.389809] lr : rpi_firmware_transaction+0xdc/0x108
[    3.389811] sp : ffffffc011f7b720
[    3.389813] x29: ffffffc011f7b720 x28: ffffffc01132e010 
[    3.389819] x27: 0000000000000000 x26: ffffff804462fb00 
[    3.389824] x25: ffffff80408f4d80 x24: ffffffc011a11008 
[    3.389829] x23: 0000000000001000 x22: ffffff80408f4d80 
[    3.389835] x21: 00000000ffffff92 x20: ffffffc01140f6c8 
[    3.389840] x19: ffffffc011298948 x18: 0000000000000000 
[    3.389845] x17: 0000000000000000 x16: 0000000000000000 
[    3.389851] x15: 0000000000000000 x14: 0000000000000000 
[    3.389856] x13: 00000000fffede56 x12: ffffffc011325480 
[    3.389861] x11: 0000000000000003 x10: ffffffc01130d440 
[    3.389866] x9 : ffffffc0100e6500 x8 : 0000000000017fe8 
[    3.389871] x7 : c0000000ffffefff x6 : ffffffc011f7b380 
[    3.389876] x5 : 0000000000000001 x4 : 0000000000000000 
[    3.389881] x3 : 0000000000000001 x2 : 0000000000000000 
[    3.389886] x1 : 6a1f6cab7ab59000 x0 : 0000000000000000 
[    3.389892] Call trace:
[    3.389897]  rpi_firmware_transaction+0xdc/0x108
[    3.389901]  rpi_firmware_property_list+0xc0/0x180
[    3.389905]  rpi_firmware_property+0x78/0x110
[    3.389942]  vc4_drm_bind+0x298/0x2c0 [vc4]
[    3.389946]  try_to_bring_up_master+0x170/0x1d8
[    3.389949]  component_master_add_with_match+0xbc/0x108
[    3.389965]  vc4_platform_drm_probe+0xd0/0x108 [vc4]
[    3.389969]  platform_drv_probe+0x5c/0xb0
[    3.389974]  really_probe+0xec/0x3c0
[    3.389977]  driver_probe_device+0x60/0xc0
[    3.389981]  device_driver_attach+0x7c/0x88
[    3.389984]  __driver_attach+0x60/0xe8
[    3.389988]  bus_for_each_dev+0x7c/0xd0
[    3.389991]  driver_attach+0x2c/0x38
[    3.389994]  bus_add_driver+0x194/0x1f8
[    3.389998]  driver_register+0x6c/0x128
[    3.390001]  __platform_driver_register+0x50/0x60
[    3.390016]  vc4_drm_register+0x50/0x1000 [vc4]
[    3.390021]  do_one_initcall+0x54/0x2d0
[    3.390026]  do_init_module+0x60/0x248
[    3.390029]  load_module+0x1fd8/0x2238
[    3.390032]  __do_sys_finit_module+0xbc/0xf8
[    3.390035]  __arm64_sys_finit_module+0x28/0x38
[    3.390040]  el0_svc_common.constprop.2+0xac/0x1d0
[    3.390044]  do_el0_svc+0x2c/0x98
[    3.390050]  el0_svc+0x20/0x30
[    3.390054]  el0_sync_handler+0x90/0xb8
[    3.390057]  el0_sync+0x180/0x1c0
[    3.390060] ---[ end trace e8f8b40ee759d27c ]---

All 3x test units run PiOS 64bit, 1x Pi4B2 runs Lite only, the other and the Pi4B8 run the desktop version. These units are used for development and upgrade testing as well as other fixed functionality - backup imaging is always conducted before testing both general and kernel/firmware upgrades so any issues found are easily and can quickly be negated/restored.

In initial testing, reverting the Pi4B2 units to kernel build 5.10.46, boot without any sign of firmware timeout trace reports within dmesg boot logs. I haven't had any further available testing time yet to try narrowing down to a specific kernel/firmware commit, between 5.10.46 and 5.10.50.

Edit: No longer an issue after the update to newer commit 5.10.52.

[alfman]

Since some versions my dual screen setup doesn't work any more. For this setup I'm using a LG-display with two HDMI inputs in a split mode.
The latest working version is about 5.10.46-v8+.
Today I gave 5.10.52-v8+ via rpi-update a try and booting resulted in a completely black screen. By disconnecting HDMI-2 and a new reboot I got it working - but after reconnecting HDMI-2 the system crashed. I can only provide a crash picture taken by a mobile phone. What is the maximum file size for attachments? The picture has 5 MB, I have to resize it.

[aBUGSworstnightmare]

Since some versions my dual screen setup doesn't work any more. For this setup I'm using a LG-display with two HDMI inputs in a split mode.
The latest working version is about 5.10.46-v8+.
Today I gave 5.10.52-v8+ via rpi-update a try and booting resulted in a completely black screen. By disconnecting HDMI-2 and a new reboot I got it working - but after reconnecting HDMI-2 the system crashed. I can only provide a crash picture taken by a mobile phone. What is the maximum file size for attachments? The picture has 5 MB, I have to resize it.

Resolution wise it's 640x480pixels. Use some picture hosting app or i.e. google drive if you want to share/link a bigger size picture.

[dom]

Since some versions my dual screen setup doesn't work any more. For this setup I'm using a LG-display with two HDMI inputs in a split mode.
The latest working version is about 5.10.46-v8+.

Sounds like this issue which is being investigated.

[alfman]

Thanks Dom, you are right.
Can you inform us please, when this fix is integrated and available via rpi-update?

[airon11]

Today I got the updated kernel to version 5.10.52 in my raspberry pi 4 and CEC commands with my tv stopped working ..my tv is actually not recognized from raspberry...same tv same cable as before updating the kernel ..
Any help or ideas? Thanks

[CaptainMidnight]

Today I got the updated kernel to version 5.10.52 in my raspberry pi 4 and CEC commands with my tv stopped working ..my tv is actually not recognized from raspberry...same tv same cable as before updating the kernel ..
Any help or ideas? Thanks

Unless you need an enhancement included in the newer kernel more, you could easily revert to the previous kernel version you were using, until the CEC functionality you are trying to use is/maybe restored in a newer kernel.

[dom]

Today I got the updated kernel to version 5.10.52 in my raspberry pi 4 and CEC commands with my tv stopped working ..my tv is actually not recognized from raspberry...same tv same cable as before updating the kernel ..

Can you confirm if the issue occurred after just updating the kernel package?
I believe there was also an update to the libcec package a week or two back.

You can get back to the previous stable firmware/kernel with:

Code: Select all

sudo rpi-update e7785df5

although before doing that, I'd suggest disconnecting all hdmi leads form TV. Unplug it from mains for a minute. Connect just the Pi to hdmi. Power on TV. Power on Pi. Check if that is working. If it is, then connect other hdmi devices (one at a time, checking if cec still works).

How are you using cec? cec-client, cec-ctl, kodi or other?

[airon11]

I am using cec-client...
Yes everything was working and after kernel update stopped working...
I actually solved the cec issue going to KMS instead of FKMS video driver...
With KMS I got the cec tv working again...
Just noticed also that new kernel changed my input device node in dev, so I had to change also other scripts looking for keypresses...

Tv has no other HDMI devices connected...only raspberry...

[DougieLawson]

Unless you need an enhancement included in the newer kernel more, you could easily revert to the previous kernel version you were using, until the CEC functionality you are trying to use is/maybe restored in a newer kernel.

It's less than easy when they've pushed it out 5.10.52 with the raspberrypi-kernel and raspberrypi-bootloader packages.

What is really needed is more documentation and traces for how it fails, fix forward is always a better strategy than reverting to out-of-date stuff.

[gemani]

Another issue with the new kernel is that qBittorrent becomes very unstable when downloading, it crashes frequently and causes logouts from the UI. I've reverted the kernel using the rpi-update command in this thread, and the problem goes away so it is definitely a kernel issue.

[iceman20k]

I can confirm that CEC doesn't work just after the kernel update. Tried to unplug, also switched hdmi port, all with no effect - cec is gone for me. I'm using Yatse with my mobile phone now for Kodi, but not being able to use my normal tv remote for Kodi anymore is pain This "cec-issue" should be investigated...

Also i had "gpu_mem=512" in my config.txt. The pi did not boot up with that with new kernel. I removed that on advice and the pi booted again, but it did not play 1080p videos and also "hang" on some YouTube videos. I tried "gpu_mem=256" then, and it plays everything again. Maybe useful for some people

The error in kodi.log when trying to play 1080p videos without gpu_mem=256 was:

Code: Select all

WARNING: CMMALVideo::GetPicture - ret(0) pics(0) inputs(0) slept(500) queued(0.16) (0.16:0.00) full(0) flags(4000000) preroll(1) eos(0 2/-1)
ERROR: CMMALVideo::dec_control_port_cb Error (status=2 ENOSPC)

[dom]

Code: Select all

WARNING: CMMALVideo::GetPicture - ret(0) pics(0) inputs(0) slept(500) queued(0.16) (0.16:0.00) full(0) flags(4000000) preroll(1) eos(0 2/-1)
ERROR: CMMALVideo::dec_control_port_cb Error (status=2 ENOSPC)

Was the video h264? Was it interlaced? I suspect you could get away with a smaller value than 256. Does 128 work?

[iceman20k]

Was the video h264? Was it interlaced? I suspect you could get away with a smaller value than 256. Does 128 work?

ffprobe says:

Code: Select all

Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 50 tbc (default)

I will try with 128, thanks. Anyway, for now i am pretty fine with 256 since i got the 4GB pi. I am running "a lot" stuff on my pi including some lxc containers etc, and still i am around 20% mem usage I know, safe as much ram as possible is the way, and the right way. But Kodi/video streaming is still the main task of this pi so i'm fine with dedicating resources to it