RonR
Posts: 2838
Joined: Tue Apr 12, 2016 10:29 pm
Location: US

Re: Moving Linux Kernel to 5.9

Thu Oct 15, 2020 5:52 pm

pasman1 wrote:
Thu Oct 15, 2020 9:52 am
RonR wrote:
Wed Oct 14, 2020 8:03 pm

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
Capture.JPG (57.55 KiB) Viewed 3730 times

gtechn
Posts: 161
Joined: Thu Jan 07, 2016 5:32 pm

Re: Moving Linux Kernel to 5.9

Thu Oct 15, 2020 6:05 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Thu Oct 15, 2020 6:41 pm

gtechn wrote:
Thu Oct 15, 2020 6:05 pm
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
Posts: 2838
Joined: Tue Apr 12, 2016 10:29 pm
Location: US

Re: Moving Linux Kernel to 5.9

Thu Oct 15, 2020 7:18 pm

dom wrote:
Thu Oct 15, 2020 6:41 pm
gtechn wrote:
Thu Oct 15, 2020 6:05 pm
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
Posts: 89
Joined: Sat May 30, 2020 8:43 pm

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 1:08 am

@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.

User avatar
kerry_s
Posts: 3927
Joined: Thu Jan 30, 2020 7:14 pm

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 5:17 am

dom wrote:
Thu Oct 15, 2020 10:28 am
kerry_s wrote:
Thu Oct 15, 2020 10:26 am
dom wrote:
Thu Oct 15, 2020 9:47 am
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?
Attachments
2020-10-15-191506_1680x1050_scrot.png
2020-10-15-191506_1680x1050_scrot.png (203.72 KiB) Viewed 3583 times

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4556
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 5:50 am

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.

User avatar
kerry_s
Posts: 3927
Joined: Thu Jan 30, 2020 7:14 pm

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 5:55 am

PhilE wrote:
Fri Oct 16, 2020 5:50 am
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. :D
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4556
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 6:00 am

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

User avatar
kerry_s
Posts: 3927
Joined: Thu Jan 30, 2020 7:14 pm

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 6:04 am

PhilE wrote:
Fri Oct 16, 2020 6:00 am
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4556
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 7:28 am

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.

User avatar
kerry_s
Posts: 3927
Joined: Thu Jan 30, 2020 7:14 pm

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 8:06 am

PhilE wrote:
Fri Oct 16, 2020 7:28 am
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. :lol:

hippy
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 9:29 am

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.

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 10:41 am

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.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 10:44 am

DougieLawson wrote:
Fri Oct 16, 2020 10:41 am
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 11:00 am

hippy wrote:
Fri Oct 16, 2020 9:29 am
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.

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 11:03 am

dom wrote:
Fri Oct 16, 2020 10:44 am
DougieLawson wrote:
Fri Oct 16, 2020 10:41 am
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.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4556
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 11:08 am

@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?

User avatar
DougieLawson
Posts: 42177
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 11:25 am

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.
Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.

The use of crystal balls and mind reading is prohibited.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 13009
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 11:46 am

Bluestang wrote:
Fri Oct 16, 2020 1:08 am
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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

LTolledo
Posts: 6657
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 1:19 pm

I want to join the fray.... bu the phobia I've suffered when 5.4 broke my usage of the KVM switch still lingers..... :(
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6062
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 2:45 pm

6by9 wrote:
Fri Oct 16, 2020 11:46 am
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
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 3:10 pm

PhilE wrote:
Fri Oct 16, 2020 11:08 am
@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.
Last edited by hippy on Fri Oct 16, 2020 3:26 pm, edited 1 time in total.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4556
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 3:20 pm

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

hippy
Posts: 12309
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Moving Linux Kernel to 5.9

Fri Oct 16, 2020 3:28 pm

PhilE wrote:
Fri Oct 16, 2020 3:20 pm
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.

Return to “Advanced users”