Compiling error due to patched kernel drivers

1

Greetings,

because I want to test IPFire (Mini Appliance) with more recent wifi-modules (also Qualcomm Atheros Chipsets), I need to patch the ath11k and ath12k driver within the linux-kernel. The patched versions of the drivers are already part of more recent stable linux-kernels like 6.8 or 6.9 but not of the longterm 6.6 IPFire uses for obvious reasons.

The patch is necessary because of the limited MSI vectors of the Mini Appliance or more specific the well aged AMD-based architecture. :slight_smile:

I tried it with the patch files from patchwork.kernel.org for ath11k

https://patchwork.kernel.org/project/linux-wireless/cover/20201223030225.2345-1-cjhuang@codeaurora.org/

and ath12k

https://patchwork.kernel.org/project/linux-wireless/cover/20231120101543.4369-1-quic_kangyang@quicinc.com/

or version 2

https://patchwork.kernel.org/project/linux-wireless/cover/20231121021304.12966-1-quic_kangyang@quicinc.com/

as well as created some own patchfiles with “diff -Naur” (between the old and new “ath11k”-folder and the old and new “ath12k”-folder respectively, within linux-kernel/drivers/net/wireless/ath/)

I copied the patchfile to /src/patches/linux/ in the IPFire source structure and made an entry in the linux-lfs.

The patching itself works without any problems but at the near end, the compilation fails when the linux kernel is about to be built (stage2 at the very end, just before building the installer).

The _build.ipfire.log just spits out

make[3]: *** [scripts/Makefile.build:480: drivers] Error 2
make[2]: *** [/usr/src/linux-6.6.32/Makefile:1913: .] Error 2
make[1]: *** [Makefile:234: ___sub-make] Error 2
make[1]:Leaving directory '/usr/src/linux-6.6.32'
make: *** [linux:143: /usr/src/log/linux-6.6.32-ipfire] Error 2

As far as I understand (I’m not a pro, not even a semi) the output is hierarchic (make[1] fails because of make[2], which fails because of make[3]) and it points to the files and lines where the error occures.

make[3] → linux-kernel/scripts/Makefile.build line “480” → with reference to the “drivers”-subfolder

make[2] → linux-kernel/Makefile line “1913” → with reference to the linux-kernel-folder itself

make[1] → I don’t understand

and the last “make” → I guess it points to the linux-lfs (line 143 is where the patch-file is referenced).

Unfortunately, I cannot find any further information about why specifially the build failes (what file or function in a file is causing the process to break).

As Build Environment I use IPFire 186 itself (not on the APU-Board, but on a Lenovo Thinkpad) and without the patched ath*k-folders it works just fine.

Any ideas for a motivated non-programmer?

Greetings

Alex

2

I would look further back in the _build.ipfire.log file.

The messages you have look to be the final messages but usually there will be more detail some lines earlier in the log but some sections have to finish processing first and hence they fill the gasp between the original error message and the final bits at the end of the log file.

Typically when you have errors like this then you will have an initial error and then other errors that are due to the fact that the first error has occurred.

I would typically search in the _build.ipfire.log file for Error 2 to find the original notification of this that usually gives a few more clues, although sometimes cryptic, about what has caused the error.

1 Like
3

Hey @bonnietwin,

thank you very much, your hint did the trick! :slight_smile: I splitted the log-files for a more comfortable search and found the actual error. Turned out that there are some changed naming conventions and functions in the patched driver, which the LTS-linux kernel does not “know”. After some research and twiddle and research and twiddle I had to realize that there are way too many dependencies/cross-references and it would just not work (at least with my limited knowledge) with the old kernel.

So I ended up using the most recent stable kernel (6.9.7) as basis for my IPFire, which worked out pretty good. I had to update the linux-patches of IPFire (wrote a patch file for the patches files :smiley:), exluded one obsolete one and added two patches to udev because of missing superblock identifiers. ([v2,3/3] package/systemd: add the missing superblock identifiers - Patchwork)

I also implemented the most recent firmware (from June 2024) and adjusted the config file with the one from IPFire (so that the same parts are excluded).

Everything worked out great, the only problem left, is that there were a ton of “Cannot write - No space left on device”-error when the script is building the flash-image and trying to create the “/var”-folders.

It’s not that important to me because I only need the *.iso (which is created without any problems) but I would like to understand this, too.

So I had a look at the flash-image-lfs and found, that there are three devices created for the building-process

# /boot:  512 MB - OFFSET
# /    : 1800 MB
S_BOOT := $(shell echo $$(( 1048576 - $(S_OFFSET) )))
S_ROOT := 3773292

ifeq "$(EFI)" "1"
 S_EFI = 65536 # 32 MB
else
 S_EFI = 0

I increased the last one to 3600 MB and corrected the S_ROOT-block for it (needed a little calculation but with the help of the IPFire-log everything worked out). Now the log does not spit out the specific errors for every file / directory anymore but just ends up with one short “no space left on device”-message. I increased the size (doubled it) and blocknumber (another calculation) again but still one short message “no space left on device” at the near end.

If I exlude the making of the flash-image, everything works out great, I have my *.iso and everything’s fine but again, I would like to understand.

Space on disk is more than enough (over 100GB), so where is my fallcy?

Greetings and thanks in advance

Alex

4

Hey @bonnietwin,

I just wanted to say thank you again! I managed to get a WiFi7-module running in my little MiniAppliance. I know, I know, it definitely is way over the top but since the pricing between those Wifi-modules is not that different, I figured… why not… :smiley: … also, it was another challenge with a lot of learning. :nerd_face:

Anyway, your hint guided me into the right direction, so thanks! :slight_smile:

Greetings

Alex

5

Glad I was able to help.

Good to hear you were successful.