Moving Linux Kernel to 5.10

[RonR]

Should be showing:

Code: Select all

root@raspberrypi:~# uname -a
Linux raspberrypi 5.9.0-v8+ #1351 SMP PREEMPT Wed Oct 14 12:50:37 BST 2020 aarch64 GNU/Linux

looks like multiboot do not support kernel 5.9

regards.

MultiBoot works absolutely perfectly with the 5.9 Kernel in all regards:

Capture.JPG (57.55 KiB) Viewed 3730 times

[gtechn]

Hello,

I installed the 5.9 V8 kernel, and then enabled the full KMS driver. I then (because I like some danger) ran `sudo apt install kde-standard` and selected SDDM as default display manager when asked.

I logged and everything worked almost perfectly! I opened up KDE, and all I can say is Wow. Some of the animations are a little on the slow side, but everything seems to work as you'd expect, and all of the animations (even the fade when moving windows) work. Completely usable. I didn't have to disable the compositor or any of the hacks required on older Pis. I am on a Pi 4 2GB, but it just is really cool that it works out-of-the-box like that.

If there is a downside, it's not quite as snappy as the Raspberry Pi Desktop (though surprisingly good), and the downsides of using KMS instead of FKMS (as mentioned earlier and in other posts) apply.

Image:
https://paste.pics/AEJ0V

[dom]

I logged and everything worked almost perfectly!

That's the advantage of moving to kms. In theory more stuff "just works".
Just some of this has been designed for rather more powerful desktop machines,
so performance may suffer, but good to hear it's working pretty well for you.

[RonR]

I logged and everything worked almost perfectly!

That's the advantage of moving to kms. In theory more stuff "just works".

Dom,

I use Lite vastly more than Desktop, so I usually use VNC on those occasions that I bring up Desktop.

I just noticed that when using kms instead of fkms, Preferences -> Screen Configuration -> Configure -> Screens does not allow setting a resolution when using VNC. I don't know if kms is interesting without a real monitor, but I thought it was worth mentioning.

[Bluestang]

@dom @6x9,

I installed upstream MESA while on the vc4-fkms-v3d display stack (it now has the RPi4 Vulkan driver) and GLXINFO -B reported the updated 20.3 MESA version as expected.

However, when I switched over to the vc4-kms-v3d stack, GLXINFO -B reports MESA 19.3.2 and the llvmpipe driver is active instead (software).

I am also getting errors with getting RetroPie to run in the console with vc4-kms-v3d. SDL2 is throwing me an error that the video driver could not add a display.

vc4-fkms-v3d works just fine though. Thoughts?

UPDATE: Looks like it was a config.txt issue, I was enabling the KMS driver but I also was disabling the KMS audio driver and leaving the default Broadcom driver enabled. (i.e. vc4-kms-v3d,noaudio) I went back and disabled the Broadcom audio driver and enabled the KMS audio driver and EmulationStation started from the console without issue.

I even got RetroArch working with the RPi4 Vulkan driver in X11 with a few emus that I know already work. Hopefully, the MESA devs will get the Vulkan driver working in the console soon.

I used the config above for my use case because the KMS audio driver doesn't seem like it will ever support audio mixing from more than one source. In the 5.4 kernels, you could disable the KMS audio driver and leave the Broadcom audio driver enabled w/o any issues.

Is this expected behavior, are we going to have to use all firmware video/audio drivers or KMS video/audio but not both moving forward?

EDIT: I am using a RPi4 (4GB) on the 5.9 kernel.

[kerry_s]

Did you remove dtparam=audio=on from config.txt?

nope, didn't know i needed to.

Mentioned in the link about the arm side hdmi alsa in the first post.

still can't get sound to work from hdmi.
am i missing something?

[PhilE]

Just a side note to say not to use the "-pi4" versions of overlays explicitly - use the normal version, e.g. "dtoverlay=vc4-kms-v3d", and the firmware will select the Pi4 variant when appropriate.

[kerry_s]

Just a side note to say not to use the "-pi4" versions of overlays explicitly - use the normal version, e.g. "dtoverlay=vc4-kms-v3d", and the firmware will select the Pi4 variant when appropriate.

okay, just followed the directions.
for now i just uncommented "dtparam=audio=on" so i can use the 3.5 jack with speakers. that's the only thing i've undone.
any other tips?

[PhilE]

If you remember where you saw the instructions I'll try to get them updated.

[kerry_s]

If you remember where you saw the instructions I'll try to get them updated.

it was the post you pointed me to.
viewtopic.php?f=29&t=269769&p=1636828#p1636828

so has anyone got hdmi sound to work?

[PhilE]

You mistook me for dom - that's made my week.

I've edited the post, and will try to correct others as I find them.

[kerry_s]

You mistook me for dom - that's made my week.

I've edited the post, and will try to correct others as I find them.

aww, come on, you guys can be twins. his name is a green colour, your name is a green colour, he's a moderator, your a moderator, from my point of view you all look alike.

[hippy]

Further to my regression test failure, I have minimised my assembly language failure to ...

Code: Select all

                .data
main:           .globl  main

                mov     r0,#0
                mov     r7,#248
                svc     0

That runs on 5.4, starts and exits as expected, but not on 5.9 where it throws a segmentation error.

If I remove the ".data" it runs on 5.9 but removing that doesn't work with my earlier code which still fails with a segmentation error on 5.9 so there's still something else.

[DougieLawson]

An odd thing happened at 4 o'clock this morning.

Code: Select all

Oct 16 04:29:40 discovery kernel: [317958.394035] kworker/u8:6: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=/,mems_allowed=0
Oct 16 04:29:41 discovery kernel: [317958.394057] CPU: 0 PID: 1921 Comm: kworker/u8:6 Tainted: G         C        5.4.70-v8+ #1348
Oct 16 04:29:41 discovery kernel: [317958.394060] Hardware name: Raspberry Pi 3 Model A Plus Rev 1.0 (DT)
Oct 16 04:29:41 discovery kernel: [317958.394106] Workqueue: brcmf_wq/mmc1:0001:1 brcmf_sdio_dataworker [brcmfmac]
Oct 16 04:29:41 discovery kernel: [317958.394111] Call trace:
Oct 16 04:29:41 discovery kernel: [317958.394120]  dump_backtrace+0x0/0x148
Oct 16 04:29:41 discovery kernel: [317958.394124]  show_stack+0x24/0x30
Oct 16 04:29:41 discovery kernel: [317958.394131]  dump_stack+0xd8/0x158
Oct 16 04:29:41 discovery kernel: [317958.394138]  warn_alloc+0xf4/0x160
Oct 16 04:29:41 discovery kernel: [317958.394142]  __alloc_pages_slowpath+0xbc4/0xbe0
Oct 16 04:29:41 discovery kernel: [317958.394146]  __alloc_pages_nodemask+0x2ac/0x328
Oct 16 04:29:41 discovery kernel: [317958.394152]  alloc_slab_page+0x1d8/0x600
Oct 16 04:29:41 discovery kernel: [317958.394156]  new_slab+0x2a0/0x368
Oct 16 04:29:41 discovery kernel: [317958.394161]  ___slab_alloc.constprop.0+0x1b0/0x698
Oct 16 04:29:41 discovery kernel: [317958.394165]  __slab_alloc.isra.0.constprop.0+0x68/0xc8
Oct 16 04:29:41 discovery kernel: [317958.394170]  __kmalloc+0x358/0x360
Oct 16 04:29:41 discovery kernel: [317958.394176]  bcm2835_dma_create_cb_chain+0x68/0x350
Oct 16 04:29:41 discovery kernel: [317958.394181]  bcm2835_dma_prep_slave_sg+0x10c/0x330
Oct 16 04:29:41 discovery kernel: [317958.394187]  bcm2835_mmc_transfer_dma+0xd4/0x280
Oct 16 04:29:41 discovery kernel: [317958.394191]  bcm2835_mmc_request+0xa0/0xb8
Oct 16 04:29:41 discovery kernel: [317958.394197]  __mmc_start_request+0x88/0x1e0
Oct 16 04:29:41 discovery kernel: [317958.394201]  mmc_start_request+0x88/0xb0
Oct 16 04:29:41 discovery kernel: [317958.394205]  mmc_wait_for_req+0x74/0x108
Oct 16 04:29:41 discovery kernel: [317958.394210]  mmc_io_rw_extended+0x1f4/0x2e8
Oct 16 04:29:41 discovery kernel: [317958.394215]  sdio_io_rw_ext_helper+0xf4/0x230
Oct 16 04:29:41 discovery kernel: [317958.394219]  sdio_readsb+0x44/0x58
Oct 16 04:29:41 discovery kernel: [317958.394246]  brcmf_sdiod_skbuff_read.isra.0+0xbc/0xc0 [brcmfmac]
Oct 16 04:29:41 discovery kernel: [317958.394270]  brcmf_sdiod_recv_pkt+0x7c/0x90 [brcmfmac]
Oct 16 04:29:41 discovery kernel: [317958.394294]  brcmf_sdio_dataworker+0xdcc/0x2298 [brcmfmac]
Oct 16 04:29:41 discovery kernel: [317958.394300]  process_one_work+0x1c0/0x478
Oct 16 04:29:41 discovery kernel: [317958.394304]  worker_thread+0x50/0x428
Oct 16 04:29:41 discovery kernel: [317958.394309]  kthread+0x118/0x150
Oct 16 04:29:41 discovery kernel: [317958.394315]  ret_from_fork+0x10/0x18
Oct 16 04:29:41 discovery kernel: [317958.394318] Mem-Info:
Oct 16 04:29:41 discovery kernel: [317958.394329] active_anon:36995 inactive_anon:37029 isolated_anon:0
Oct 16 04:29:41 discovery kernel: [317958.394329]  active_file:100 inactive_file:123 isolated_file:32
Oct 16 04:29:41 discovery kernel: [317958.394329]  unevictable:4 dirty:0 writeback:0 unstable:0
Oct 16 04:29:41 discovery kernel: [317958.394329]  slab_reclaimable:4137 slab_unreclaimable:5854
Oct 16 04:29:41 discovery kernel: [317958.394329]  mapped:78 shmem:45 pagetables:1310 bounce:0
Oct 16 04:29:41 discovery kernel: [317958.394329]  free:17029 free_pcp:45 free_cma:13054
Oct 16 04:29:41 discovery kernel: [317958.394337] Node 0 active_anon:147980kB inactive_anon:148116kB active_file:400kB inactive_file:492kB unevictable:16kB isolated(anon):0kB isolated(file):128kB mapped:312kB dirty:0kB writeback:0kB shmem:180kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Oct 16 04:29:41 discovery kernel: [317958.394347] DMA free:68116kB min:16384kB low:20480kB high:24576kB active_anon:147980kB inactive_anon:148116kB active_file:428kB inactive_file:484kB unevictable:16kB writepending:0kB present:458752kB managed:424304kB mlocked:16kB kernel_stack:2976kB pagetables:5240kB bounce:0kB free_pcp:180kB local_pcp:64kB free_cma:52216kB
Oct 16 04:29:41 discovery kernel: [317958.394350] lowmem_reserve[]: 0 0 0 0
Oct 16 04:29:41 discovery kernel: [317958.394357] DMA: 628*4kB (UEC) 475*8kB (UEC) 340*16kB (UEC) 220*32kB (UEC) 230*64kB (UEC) 104*128kB (UEC) 46*256kB (C) 12*512kB (C) 1*1024kB (C) 1*2048kB (C) 0*4096kB = 67816kB
Oct 16 04:29:41 discovery kernel: [317958.394388] 8951 total pagecache pages
Oct 16 04:29:41 discovery kernel: [317958.394394] 8616 pages in swap cache
Oct 16 04:29:41 discovery kernel: [317958.394398] Swap cache stats: add 263667, delete 255051, find 14735/15337
Oct 16 04:29:41 discovery kernel: [317958.394401] Free swap  = 0kB
Oct 16 04:29:41 discovery kernel: [317958.394403] Total swap = 1048572kB
Oct 16 04:29:41 discovery kernel: [317958.394406] 114688 pages RAM
Oct 16 04:29:41 discovery kernel: [317958.394408] 0 pages HighMem/MovableOnly
Oct 16 04:29:41 discovery kernel: [317958.394411] 8612 pages reserved
Oct 16 04:29:41 discovery kernel: [317958.394414] 16384 pages cma reserved
Oct 16 04:29:41 discovery kernel: [317958.394420] SLUB: Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)

That's on a 3A+ running the 64-bit kernel. It's back to 5.4.70 for the moment.

[dom]

An odd thing happened at 4 o'clock this morning.
...
That's on a 3A+ running the 64-bit kernel. It's back to 5.4.70 for the moment.

Can you describe what was running at the time? Bluetooth? Let us know if you find a sequence that makes it fail on demand.

[dom]

Further to my regression test failure, I have minimised my assembly language failure to ...

What do you believe that code should do? It's generating a software interrupt. What code do you think is handling that?
Searching for that code snippet showed up a use in the bare metal forum here.
I don't think it's valid under linux.

[DougieLawson]

An odd thing happened at 4 o'clock this morning.
...
That's on a 3A+ running the 64-bit kernel. It's back to 5.4.70 for the moment.

Can you describe what was running at the time? Bluetooth? Let us know if you find a sequence that makes it fail on demand.

At those early hours in the morning all that was running is my Zappi API program that pulls my power usage data from my car charger (on an hourly cron job). There was also some regular postfix action going on. Bluetooth isn't active on that one.

Things went badly wrong after that first failure and that machine was totally unresponsive at 11:00 today. I'll install pastebin and grab the whole kernel log for you.

[PhilE]

@hippy The latest version of the v7 armstubs disable the secure monitor call, which may be the cause of the change of behaviour. What are you trying to achieve with it?

[DougieLawson]

Full kernel log from midnight 16th Oct until the point where I rebooted at 5.4.70 at http://paste.debian.net/1167411

BTW, the python pastebinit program is broken in Buster with python 3.7.

[6by9]

UPDATE: Looks like it was a config.txt issue, I was enabling the KMS driver but I also was disabling the KMS audio driver and leaving the default Broadcom driver enabled. (i.e. vc4-kms-v3d,noaudio) I went back and disabled the Broadcom audio driver and enabled the KMS audio driver and EmulationStation started from the console without issue.

I even got RetroArch working with the RPi4 Vulkan driver in X11 with a few emus that I know already work. Hopefully, the MESA devs will get the Vulkan driver working in the console soon.

I used the config above for my use case because the KMS audio driver doesn't seem like it will ever support audio mixing from more than one source. In the 5.4 kernels, you could disable the KMS audio driver and leave the Broadcom audio driver enabled w/o any issues.

Is this expected behavior, are we going to have to use all firmware video/audio drivers or KMS video/audio but not both moving forward?

EDIT: I am using a RPi4 (4GB) on the 5.9 kernel.

Fixed already - https://github.com/raspberrypi/linux/co ... f77ee56c9a

I can't comment on mixing - alsa should be able to do it, and I believe LibreElec/Kodi have sorted out the correct alsa.conf file to deal with the majority of the encapsulation stuff. I'd need to have a hunt for the file, and we really ought to get RaspiOS updated to have the updated file.

[LTolledo]

I want to join the fray.... bu the phobia I've suffered when 5.4 broke my usage of the KVM switch still lingers.....

[dom]

I can't comment on mixing - alsa should be able to do it, and I believe LibreElec/Kodi have sorted out the correct alsa.conf file to deal with the majority of the encapsulation stuff. I'd need to have a hunt for the file, and we really ought to get RaspiOS updated to have the updated file.

LibreELEC/Kodi only appears as a single alsa client so doesn't require mixing at alsa level.
I believe a sound server is required for mixing (e.g. pulse audio or JACK).
The firmware was used as a sound server before kms where we allowed up to 8 alsa clients and firmware mixed them together.

[hippy]

@hippy The latest version of the v7 armstubs disable the secure monitor call, which may be the cause of the change of behaviour. What are you trying to achieve with it?

It was copy-and-pasted code which was meant to terminate a Linux userland program. Seemed to work and still does AFAICT, so that doesn't seem to be my issue - Added : Almost certainly copied from here - viewtopic.php?p=1396350#p1396350

The issue seems to be that 5.9 no longer allows code and data to be mixed in the .data section. The segmentation fault is AFAICT trying to execute code in that .data section. I should have realised it's a 'fails on first instruction' sooner.

Of course, putting it all in the .text section means writes to data in that section then give segmentation fault errors so the refactoring has to be a little more extensive. I started a separate thread and seem to have a workround -

viewtopic.php?f=72&t=288403

So we can can forget abut my issue here, except to the extent that others may have code which falls into the same 'won't work with 5.9, did with 5.4' category.

Thanks though for your efforts to assist and identify the issue.

[PhilE]

An inability to execute data sounds like an improvement to me, increased security being the likely intention behind the change.

[hippy]

An inability to execute data sounds like an improvement to me, increased security being the likely intention behind the change.

I can't argue with that, but it does break currently working code.