MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Mon Apr 06, 2020 7:33 am

With reference to my earlier post https://www.raspberrypi.org/forums/view ... 5#p1637260 after much hunting about it seems the wifi drivers failing to compile are down to invalid Module.symvers files for kernels 5.4.29-v7+ and 5.4.29-v7l+.

Rather than preparing the kernel source for compiling the drivers using commands

Code: Select all

make mrproper
make bcm2709_defconfig #or bcm2711_defconfig
make modules_prepare
and then copying the relevant Module.symvers file to the kernel source directory from the github repo, I used commands

Code: Select all

make mrproper
make bcm2709_defconfig #or bcm2711_defconfig
make ARCH=arm -j4
so fully compiled the kernel which created it's own Module.symvers file. This file now contained the value __stack_chk_guard which was missing in the Module.symvers files in the github repo (hexxeh/rpi-update and raspberry/firmware) and causing the driver compiles to fail.

Then when compiling the wifi drivers they compiled OK and checking the Module.symvers files the value causing the previous errors, __stack_chk_guard, was now present in the Module.symvers file.

So no idea why there should be such a problem but it appears the Module7.symvers and Module7l.symvers files in the github repos are invalid.

EDIT: raised an issue at raspberry/firmware git repo.


MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

frankdrn
Posts: 5
Joined: Fri Apr 03, 2020 3:02 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Mon Apr 06, 2020 11:22 am

Hyperpixel4 rectangular works on a 3B+. Display and touchscreen look good.

I2S output is working with a Phat Beat on Pi Zero W and 3B. The phatbeat python library fails though with a Runtime Error from RPi.GPIO when using add_event_detect. That seems like a general problem with RPi.GPIO trying to use add_event_detect on Pi 4, 3B+, 3B or Zero W (haven't tried anything else) but it's not a problem in 4.19.113.

Code: Select all

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/phatbeat/__init__.py", line 45, in _exit
    clear()
  File "/usr/lib/python3/dist-packages/phatbeat/__init__.py", line 137, in clear
    setup()
  File "/usr/lib/python3/dist-packages/phatbeat/__init__.py", line 325, in setup
    GPIO.add_event_detect(button, GPIO.FALLING, callback=_handle_button, bouncetime=200)
RuntimeError: Failed to add edge detection
Frank

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

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 7:06 pm

Pushed update with fix for core and cpu clocks not being boosted when busy.

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

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 7:17 pm

With today's release it should no longer be necessary to use dtoverlay=vc4-kms-v3d-pi4 on a Pi 4 - the usual dtoverlay=vc4-kms-v3d should also work. If you want to use the real KMS driver, that is - the original vc4-fkms-v3d still works as well.

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

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 8:02 pm

dom wrote:
Tue Apr 07, 2020 7:06 pm
Pushed update with fix for core and cpu clocks not being boosted when busy.
Does that fix the SPI problems with the TV HAT?
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

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

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 8:16 pm

DougieLawson wrote:
Tue Apr 07, 2020 8:02 pm
Does that fix the SPI problems with the TV HAT?
No.

noee
Posts: 18
Joined: Thu Nov 21, 2019 5:30 pm

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 8:23 pm

dom wrote:
Tue Apr 07, 2020 7:06 pm
Pushed update with fix for core and cpu clocks not being boosted when busy.
Yep, looks fixed. Just running 32bit kernel so far. One thing, not sure if I missed it, my monitor (TV) has defaulted back to 4K and I had changed it to 1080P, but since the "next" kernel/firmware with vc4-kms-v3d, I can't find how to change resolution.

Is it just not available yet with kms?

edit: eeek, figured it out.

jahboater
Posts: 5632
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Moving Linux Kernel to 5.4

Tue Apr 07, 2020 10:36 pm

noee wrote:
Tue Apr 07, 2020 8:23 pm
dom wrote:
Tue Apr 07, 2020 7:06 pm
Pushed update with fix for core and cpu clocks not being boosted when busy.
Yep, looks fixed. Just running 32bit kernel so far.
Fixed for me too (Raspbian Lite) with the 64-bit kernel.
Pi4 8GB running PIOS64

darksavior
Posts: 11
Joined: Sat Jul 25, 2015 7:56 am

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 2:07 am

The gamecon drivers fail to install with this new kernel. I did update to the "latest" 5.4. Installed the kernel headers with rpi-source and make headers_install INSTALL_HDR_PATH=/usr.

Pi4. Retropie on top of raspbian-lite buster. 32bit kernel.
Retropie-Setup log: https://pastebin.com/1yL6nijR
/var/lib/dkms/db9_gpio_rpi/1.2/build/make.log https://pastebin.com/pqm0YT2j
/var/lib/dkms/gamecon_gpio_rpi/1.4/build/make.log https://pastebin.com/PiXc1M3K

Another question, is hdmi_enable_4kp60=1 not working with kms? It shows up as 30hz.

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 9:11 am

@PhilE, @Dom,

Seems I'm not the only one having issues with the faulty Module7(7l).symvers files in the 5.4 kernel.

Surely it shouldn't be a problem getting it fixed, should it?

darksavior wrote:
Wed Apr 08, 2020 2:07 am
The gamecon drivers fail to install with this new kernel. I did update to the "latest" 5.4. Installed the kernel headers with rpi-source and make headers_install INSTALL_HDR_PATH=/usr.

Pi4. Retropie on top of raspbian-lite buster. 32bit kernel.
Retropie-Setup log: https://pastebin.com/1yL6nijR
/var/lib/dkms/db9_gpio_rpi/1.2/build/make.log https://pastebin.com/pqm0YT2j
/var/lib/dkms/gamecon_gpio_rpi/1.4/build/make.log https://pastebin.com/PiXc1M3K

MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

hjimbens
Posts: 75
Joined: Fri May 24, 2013 9:05 am

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 9:31 am

dom wrote:
Thu Apr 02, 2020 7:30 pm
5.4 also includes... and support for HEVC video decode using V4L2 on Pi4.
Will the ffmpeg that is in the current 2020-02-13 Raspbian image automagically detect this, pick this up and suggest AV_PIX_FMT_DRM_PRIME in get_format?
Is V4L2 support for the H264 block also available in this kernel? And also for the Pi3?

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 10:09 am

MrEngman wrote:
Wed Apr 08, 2020 9:11 am
Surely it shouldn't be a problem getting it fixed, should it?
Suggestions for the fix are welcome.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 10:13 am

hjimbens wrote:
Wed Apr 08, 2020 9:31 am
[Will the ffmpeg that is in the current 2020-02-13 Raspbian image automagically detect this, pick this up and suggest AV_PIX_FMT_DRM_PRIME in get_format?
Is V4L2 support for the H264 block also available in this kernel? And also for the Pi3?
Stateful v4l2 (supporting firmware codecs like h264, mpeg2, mpeg4, vc1) should be supported by current ffmpeg and 5.4 kernel on all Pi models.

Stateless v4l2 (which is needed for hevc) isn't in upstream ffmpeg yet, and isn't in raspbian.
This ffmpeg tree should support it if you want to compile your own.

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 10:28 am

dom wrote:
Wed Apr 08, 2020 10:09 am
MrEngman wrote:
Wed Apr 08, 2020 9:11 am
Surely it shouldn't be a problem getting it fixed, should it?
Suggestions for the fix are welcome.
Well, when I do a full compile of the kernel for kernel versions -7+ and -7l+ the Module.symvers file that is generated includes the value __stack_chk_guard that is missing from the Module7(7l).symvers files in the Raspberry/firmware github repo.

How this happened I've no idea but whoever created these files with the missing value maybe needs to look at how they did it and figure out what happened. Maybe they compiled a wrong version of the kernel source?


MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 10:37 am

hjimbens wrote:
Wed Apr 08, 2020 9:31 am
dom wrote:
Thu Apr 02, 2020 7:30 pm
5.4 also includes... and support for HEVC video decode using V4L2 on Pi4.
Will the ffmpeg that is in the current 2020-02-13 Raspbian image automagically detect this, pick this up and suggest AV_PIX_FMT_DRM_PRIME in get_format?
AFAIK The Raspbian version won't yet. Technically HEVC isn't officially supported by the mainline kernel as yet as they haven't confirmed they're happy with the control structures. I believe https://github.com/popcornmix/FFmpeg/tree/kodi_v4l2_1 is dom's latest dev branch.
hjimbens wrote:Is V4L2 support for the H264 block also available in this kernel? And also for the Pi3?
https://github.com/raspberrypi/linux/tr ... 2835-codec

Code: Select all

pi@raspberrypi:~ $ modinfo bcm2835-codec 
filename:       /lib/modules/5.4.29-v7l+/kernel/drivers/staging/vc04_services/bcm2835-codec/bcm2835-codec.ko
alias:          platform:bcm2835-codec
version:        0.0.1
license:        GPL
author:         Dave Stevenson, <dave.stevenson@raspberrypi.org>
description:    BCM2835 codec V4L2 driver
srcversion:     0089DC9D931B034B4CEB952
depends:        v4l2-mem2mem,bcm2835-mmal-vchiq,videodev,videobuf2-v4l2,videobuf2-common,mc,videobuf2-dma-contig
staging:        Y
intree:         Y
name:           bcm2835_codec
vermagic:       5.4.29-v7l+ SMP mod_unload modversions ARMv7 p2v8 
parm:           decode_video_nr:decoder video device number (int)
parm:           encode_video_nr:encoder video device number (int)
parm:           isp_video_nr:isp video device number (int)
parm:           disable_bayer:Disable support for Bayer formats (bool)
parm:           debug:activates debug info (0-3) (uint)
present and correct
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.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 10:44 am

@MrEngman I don't think this is simple finger trouble - it looks more like a difference in compiler versions having an affect on builds of newer kernels. I'll report back soon with the results of some tests.

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 11:05 am

PhilE wrote:
Wed Apr 08, 2020 10:44 am
@MrEngman I don't think this is simple finger trouble - it looks more like a difference in compiler versions having an affect on builds of newer kernels. I'll report back soon with the results of some tests.
Thanks.

Just for info I compile my drivers on a Pi 3B+ using gcc (Raspbian 4.9.3-14) 4.9.3 for kernels +, -v7+ and -v7l+ and aarch64-linux-gnu-gcc-5.4.0 (GCC) 5.4.0 for kernel -v8+.


MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 11:25 am

The problem is triggered by the following commit, introduced in the 5.2 kernel:
[ https://git.kernel.org/pub/scm/linux/ke ... d82b2ccddc ]

Code: Select all

commit 189af4657186da08a2e79fb8e906cfd82b2ccddc
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Dec 6 09:32:57 2018 +0100

    ARM: smp: add support for per-task stack canaries
    
    On ARM, we currently only change the value of the stack canary when
    switching tasks if the kernel was built for UP. On SMP kernels, this
    is impossible since the stack canary value is obtained via a global
    symbol reference, which means
    a) all running tasks on all CPUs must use the same value
    b) we can only modify the value when no kernel stack frames are live
       on any CPU, which is effectively never.
    
    So instead, use a GCC plugin to add a RTL pass that replaces each
    reference to the address of the __stack_chk_guard symbol with an
    expression that produces the address of the 'stack_canary' field
    that is added to struct thread_info. This way, each task will use
    its own randomized value.
    
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Emese Revfy <re.emese@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: kernel-hardening@lists.openwall.com
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
Reverting that commit (a slightly messy operation) brings back the __stack_chk_guard on 5.2 and later kernels, proving the connection.

So the question now becomes, why are your builds expecting __stack_chk_guard to be present for SMP platforms when it shouldn't be?

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 12:51 pm

PhilE wrote:
Wed Apr 08, 2020 11:25 am
The problem is triggered by the following commit, introduced in the 5.2 kernel:
[ https://git.kernel.org/pub/scm/linux/ke ... d82b2ccddc ]

Code: Select all

commit 189af4657186da08a2e79fb8e906cfd82b2ccddc
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Dec 6 09:32:57 2018 +0100

    ARM: smp: add support for per-task stack canaries
    
    On ARM, we currently only change the value of the stack canary when
    switching tasks if the kernel was built for UP. On SMP kernels, this
    is impossible since the stack canary value is obtained via a global
    symbol reference, which means
    a) all running tasks on all CPUs must use the same value
    b) we can only modify the value when no kernel stack frames are live
       on any CPU, which is effectively never.
    
    So instead, use a GCC plugin to add a RTL pass that replaces each
    reference to the address of the __stack_chk_guard symbol with an
    expression that produces the address of the 'stack_canary' field
    that is added to struct thread_info. This way, each task will use
    its own randomized value.
    
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Emese Revfy <re.emese@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: kernel-hardening@lists.openwall.com
    Acked-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
Reverting that commit (a slightly messy operation) brings back the __stack_chk_guard on 5.2 and later kernels, proving the connection.

So the question now becomes, why are your builds expecting __stack_chk_guard to be present for SMP platforms when it shouldn't be?
Sorry but I don't understand what that commit is all about. My knowledge of coding is very very limited. Can you possibly explain what stack canary and SMP platform are?

I assume kernels +, -v7+ and -v7l+ to be compiled with the same compiler version and -v8+ with a 64bit compiler so why do Module.symvers and Module8.symvers include __stack_chk_guard and Module7.symvers and Module7l.sysmvers do not include __stack_chk_guard.

When I fully compile the -v7+ and -v7l+ kernels so the compile creates the Module.symvers file they both include __stack_chk_guard.

Are you saying -v7+ and -v7l+ kernels are for SMP platforms and + and -v8+ kernels are not for SMP platforms?

Sorry but I'm feeling really dumb as I'm find it hard understanding this stuff. Is there anything you would like me to look at to try and figure out what is happening?

I have logs of the compiles which show a number of warnings which need sorting out, although these do not stop drivers for kernels + and -v8+ compiling, and the final error regarding __stack_chk_guard for kernels -v7+ and -v7l+. Searching the compiled files, *.o files, in the driver I'm currently working on shows around 68 files which include the value __stack_check_guard.

Thanks for your time in looking at this issue.

MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 12:58 pm

Stack protection is a compiler feature that helps to guard against buffer overflows. SMP stands for Symmetric Multi Processing, which you can think of as support for multi-core platforms (which BCM2836, BCM2837 and BCM2711 are, but BCM2835 isn't). The commit is saying that the old way of doing stack protection isn't ideal in multi-core systems, so it introduces a new way - per-task stack protection. When that is enabled, __stack_chk_guard stops being a symbol and gets turned into some inline code.

I'll comment again when I've figured it all out, but I think you understand now that bigger forces are at work than a bad release.

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 1:36 pm

PhilE wrote:
Wed Apr 08, 2020 12:58 pm
Stack protection is a compiler feature that helps to guard against buffer overflows. SMP stands for Symmetric Multi Processing, which you can think of as support for multi-core platforms (which BCM2836, BCM2837 and BCM2711 are, but BCM2835 isn't). The commit is saying that the old way of doing stack protection isn't ideal in multi-core systems, so it introduces a new way - per-task stack protection. When that is enabled, __stack_chk_guard stops being a symbol and gets turned into some inline code.

I'll comment again when I've figured it all out, but I think you understand now that bigger forces are at work than a bad release.
Thanks @PhilE

Not sure I do fully understand, guess my brain is just getting rather old and worn out :oops:

Anyway if there's anything you would like me to try or any info I can supply just ask.


MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

HiassofT
Posts: 282
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 2:02 pm

PhilE wrote:
Wed Apr 08, 2020 12:58 pm
Stack protection is a compiler feature that helps to guard against buffer overflows. SMP stands for Symmetric Multi Processing, which you can think of as support for multi-core platforms (which BCM2836, BCM2837 and BCM2711 are, but BCM2835 isn't). The commit is saying that the old way of doing stack protection isn't ideal in multi-core systems, so it introduces a new way - per-task stack protection. When that is enabled, __stack_chk_guard stops being a symbol and gets turned into some inline code.

I'll comment again when I've figured it all out, but I think you understand now that bigger forces are at work than a bad release.
This could be triggered by different gcc plugin support (eg different gcc versions, native vs cross-compiling etc). comparing actual kernel configs should show if GCC_PLUGINS and STACKPROTECTOR_PER_TASK were enabled during kernel / out-of-tree module builds.

We had a bit similar gcc-plugin related issue in LibreELEC but as we don't enable any of the security related features in kernelconfig yet we simply patched the kernel build system to not use gcc plugins https://github.com/LibreELEC/LibreELEC.tv/pull/4212

so long,

Hias

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 2:11 pm

Yes, is does seem to be controlled by the GCC plugins system. I have three build environments at my fingertips - one which enables STACKPROTECTOR_BY_TASK and two which don't. The common factor seems to be that the plugin supporting environment has g++, while the others don't. I think the build system is faulty in this respect - it appears to be trying to choose a compiler for the gcc plugin support, but the error triggered by the g++ test is preventing it from falling back to gcc.

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

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 2:49 pm

There's some advanced kernel build hackery in milhouse's patch, but I'm prepared to chance it. ;-)

An equivalent patch is now in rpi-5.4.y, and the resulting Module.symvers does have __stk_chk_guard on all build hosts (and identical md5sums).

MrEngman
Posts: 4020
Joined: Fri Feb 03, 2012 2:17 pm
Location: Southampton, UK

Re: Moving Linux Kernel to 5.4

Wed Apr 08, 2020 3:25 pm

@PhilE,

I've managed to find a fix so the wifi drivers compile, with -v7+ and -v7l+ no longer failing because of the missing __stack_chk_guard in the Module7(7l).symvers files.

Looking at the link @HiassofT pointed to and following some other links I found this link https://askubuntu.com/questions/870244/build-linux-4-9 and then this one http://lkml.iu.edu/hypermail/linux/kern ... 03341.html

I then installed the package gcc-4.9-plugin-dev

Code: Select all

sudo apt update
sudo apt install gcc-4.9-plugin-dev
Now when I run the script to compile my wifi drivers they all compile without any errors.

Whether this is the right thing to do I don't know but at least it fixed my issue for the moment.


MrEngman
Simplicity is a prerequisite for reliability. Edsger W. Dijkstra

Please post ALL technical questions on the forum. Please Do Not send private messages.

Return to “Advanced users”