You are not logged in.
Hello everyone!
Since the release of the latest linux-vfio (6.12.10-1) patch, I've been trying to compile it without success. Several versions before this one compiled and installed without any hiccups, so it's a new frontier for me. I'm not sure how to properly proceed. I have a very surface level of familiarity with Linux still, but I use it and try to learn about it everyday.
There are several points during the compilation where errors appear. They all prompt me to report a bug at Arch Linux Gitlab, however they seem to be having spam related problems at the moment and currently the registration process is manual. I fear my problems may be trivial and I wouldn't like to bother them if possible given those circumstances. Is my fear justified, or should I go ahead and follow the compilator's instructions to submit the bug report?
Is it okay to ask for help on this issue over here, on this forum, if I've been explicitly asked to report at gitlab? I know it's weird to ask, but I'm really not sure which course of action would be most proper.
Thank you!
Last edited by halfapage (2025-01-27 22:22:06)
Offline
Could you post the actual error?
Offline
1. What is the exact error?
2. It is wise that you posted here first. AUR package bug tracking is not done at Arch Gitlab cause the package is not supported officially by Arch.
Offline
Thank you for replies! I'm glad I haven't bothered anyone directly on gitlab then, I'll keep that information in mind!
I only now realised that I never directed makepkg to store the log files, so I'll run compilation again and post the logs then.
Thank you!
Offline
I either don't know how to make makepkg properly produce a log file, or I'm looking for it in a wrong directory. I will try to figure this out. In the meantime, I'll simply copy and paste the final error from the terminal:
make[3]: *** [scripts/Makefile.build:478: drivers/net] Error 2
make[2]: *** [scripts/Makefile.build:478: drivers] Error 2
make[1]: *** [/home/halfapage/linux-vfio/src/linux-6.12.10/Makefile:1937: .] Error 2
make: *** [Makefile:224: __sub-make] Error 2
==> ERROR: A failure occurred in build().
Aborting...
Generally, the errors seem to be semi random, but they are always related to drivers.
I'll post the proper log file when I'll learn how to produce it.
Offline
Mod note: moving to AUR Issues.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
This is still a half measure, but here is the final 1065 lines of the terminal output. I'm still looking to post full log.
Offline
`makepkg` has the --log option which will log the output of each stage to a file.
sound/soc/intel/common/soc-acpi-intel-jsl-match.c:117:1: internal compiler error: in pop_scope, at c/c-decl.cc:1443
117 | EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_jsl_machines);
| ^~~~~~~~~~~~~~~~~
0x1fabd46 internal_error(char const*, ...)
???:0
0x6d971b fancy_abort(char const*, int, char const*)
???:0
0x6f6a94 pop_file_scope()
???:0
0x7e611a c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues> for instructions.
make[6]: *** [scripts/Makefile.build:229: sound/soc/intel/common/soc-acpi-intel-jsl-match.o] Error 1
make[5]: *** [scripts/Makefile.build:478: sound/soc/intel/common] Error 2
make[5]: *** Waiting for unfinished jobs....
Is the system generally stable?
Offline
Yes, I've been using that option. Makepkg has of course been properly generating the outputs this whole time, and it is me who was looking for them in a wrong directory.
I got some log files, but now for some reason the compilation does not gracefully end with an error message, it straight up crashes the PC every time. I can't collect a whole log still, but I will be retrying.
Compilation crashes for this package have been happening before too, but for a few days back I have been blessed with graceful error exits. Guess not anymore.
The system is definitely not stable at the moment. The troubles began right about the middle of january. The new version of linux-vfio came out (18.01.2025), but it is somewhat coincident with other critical packages being upgraded as well. The system crashes quite often while playing games that have been running before without any issues, and while I'm trying to compile linux-vfio. I've been trying to downgrade upgraded packages I suspected of being related to the problems before to no avail. That is why I'm fixated on linux-vfio being the culprit behind the instability - it is the only thing I cannot upgrade. That is of course not a judgement based on knowledge - I am not a sufficiently aware user at all.
My system is built on AMD Ryzen 5 8600G with built in Radeon 760M graphics. iGPU is used for Arch, but I also have an old GTX960 passed through for a win10 VM. That is the reason why I would like to continue to use linux-vfio.
Offline
I see something strange. The version in the AUR is mismatching with the kernel config page provided by Arch which is at 6.13.
In any case, this means it'll be futile to try to diagnose this issue UNTIL linux-vfio 6.13 is in the AUR since the kernel config noted in the PKGBUILD is grabbing a config designed for 6.13 instead of 6.12.10
Offline
CC [M] drivers/gpu/drm/radeon/atombios_crtc.o
sound/soc/intel/common/soc-acpi-intel-jsl-match.c:117:1: internal compiler error: in pop_scope, at c/c-decl.cc:1443
0x1fabd46 internal_error(char const*, ...)
./include/linux/module.h:385:9: internal compiler error: Segmentation fault
0x1fabd46 internal_error(char const*, ...)
CC [M] drivers/gpu/drm/i915/gem/i915_gem_internal.o
/tmp/cch4J3FH.s: Internal error (Segmentation fault).
drivers/gpu/drm/i915/display/intel_frontbuffer.c:350:1: internal compiler error: in pop_scope, at c/c-decl.cc:1443
0x1fabd46 internal_error(char const*, ...)
isn't about kernel version mismatches - the compiler fails.
I mean, picking the proper kernel config certainly won't harm (notably since the AUR package also seems to provide one), but the compiler isn't allowed to segfault for some bad config file.
* Are you running OOM?
Do you have (physical) swap space (swapfile is gonna do)
* What compiler do you use? llvm? gcc? Which version?
* How many parallel compilation jobs do you use?
Does it work w/ -j1, https://wiki.archlinux.org/title/Makepk … ompilation ?
Offline
* I don't seem to run out of memory. After a while I started running htop during the compilation to monitor core and memory usage. The memory stays filled at ~10-12GB (from 27GB available, I've got 32GB RAM, but some of it is reserved for iGPU), but I'm not sure if memory usage doesn't spike just before the crash. I have no swap configured, should I reconsider?
* The compiler used is gcc 14.2.1.
* I tried reducing threads to one, prompted by wiki and other threads I've found. Weirdly enough, it seems to crash relatively even sooner in the process. Here is a log of a failed one threaded compilation. I also tried using all twelve available threads, as well as other combinations in between.
Offline
Weirdly enough, it seems to crash relatively even sooner in the process.
during RTL pass: expand
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c: In function ‘sdma_v2_4_enable’:
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c:371:13: internal compiler error: Segmentation fault
371 | static void sdma_v2_4_enable(struct amdgpu_device *adev, bool enable)
| ^~~~~~~~~~~~~~~~
0x1fabd46 internal_error(char const*, ...)
???:0
0x7cc292982fa8 calloc
???:0
0xff53d7 find_replaceable_exprs(_var_map*)
???:0
0xe6f974 rewrite_out_of_ssa(ssaexpand*)
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
AMD Ryzen 5 8600G
https://wiki.archlinux.org/title/Ryzen#Troubleshooting - try to increase the core voltages (or limit the maximum frequency)
Single core load allows the GPU to run that core faster… and into that problem.
You could also run memtest86+ but RAM stress is higher for parallel jobs, so this is now less likely.
You can maybe "makepkg -e" yourself through the crashes but that won't work if some make clean/mrproper are invoked and I'm not sure whether I'd generally trust such build either.
Offline
I have turned off all auto tuning boosters I could find, and you were right. The compilation goes as far as it can without any segmentation faults or hangs, like before.
Now I have complete logs to share, thank you!
There is lots of errors related to aic7xxx drivers. It sure looks like a missing semicolon or such haha. I tried opening the driver and make files, and look at places the compiler points at, but it is way beyond me to understand.
What would be a good course of action now?
Newbie warning ahead: would it be okay to just omit this driver, if I have searched through a list produced by lshw and did not find any sort of Adaptec device? Or could it potentially break something anyway? Should I look into why there is something wrong with those files/their interaction with compiler?
Offline
"Adaptec AIC77XX/78XX SCSI Host Bus Adapter driver" - I'm pretty sure I had one in the 90ies for a scanner and a zip drive (an oversized floppy that could store a majestic amount of 100MB…)
The definition is probably in https://elixir.bootlin.com/linux/v6.13/ … 7xxx.h#L49 but that header doesn't exist.
I'm not sure how that module compiles at all.
Offline
A whippersnapper, eh?
Thank you, I have learned a lot. Came with one problem, left with two solved haha.
Compiled and installed beautifully.
Last edited by halfapage (2025-01-27 22:23:26)
Offline
out of curiosity - the wiki states
VFIO — The Linux kernel and a few patches written by Alex Williamson (acs override and i915) to enable the ability to do PCI Passthrough with KVM on some machines.
so - is there any specific reason you acutally NEED the vfio kernel which doesn'T properly work otherwise with the standard kernel? do you just use it because you THINK you may have to because you do play around with VMs? have you actually tried to just use the regular stock linux kernel? does it break something? does the vfio build fixes something that doesn'T work with the standard kernel?
as you have an amd based system that i915 stuff doesn'T apply anyway as that'S for intels igpu - and as these transition from the regular "intel hd" to xe/arc I doubt it will be any relevance in the future (unless it's kept as the base instead of starting someting new with a new name)
what do you use the windows vm for with that passedthrough gpu? gaming? I'm not sure but I guess you can get pretty much everything running on linux directly without the VM overhead at all - antoher option could be dual booting
I somewhat have a feeling of "something smells about you using the vfio build for unkown / the wrong reason" ...
Offline
Thank you for asking. You are most probably correct!
I would swear that it helped me with IOMMU grouping issues of my GTX960, but it seems it couldn't be true at all. I went ahead and removed linux-vfio and checked the grouping - it's still in tact. The VM still runs perfectly as well.
I use Windows mainly for software I have to keep up with for work related reasons. I unfortunately can't ditch them for now, and running them through compatibility layers was sadly not reliable. As a bonus, I also use it for older games I could not make run smoothly on Arch in a time efficient manner. Games that are fun to have, but not worth a lengthy time investment.
I switched to VM from dual booting, because rebooting to switch OS is very distracting in a work flow. Everything I can run on linux, I run on linux, and I don't want it duplicated on a Windows instance. This setup caused a slurry of inconveniences and inefficiencies.
Without GPU passed through, the performance was very poor. I could pass the iGPU, but then I couldn't use programs on a VM and Arch at the same time, which is a goal.
This setup with looking glass is working super well for me. The seamlessness of it is uncanny. The graphics, the sound, the controls are all buttery smooth, native.
Offline
I see ... well I guess a VM with an older gpu actually is one of the best options for your specific use case
I was just a bit puzzled as for why you're using the vfio-build as its a specific build for a specific use case as mentioned in the wiki and the linked story at https://lwn.net/Articles/499240/ - which is back from 2012
the mainline kernel made quite some progress in terms of virtualization and so did modern hardware
hence: unless one really need the specific changes included in the vfio build there's pretty much no reason to use it over standard mainline kernel
I don't question its likely nishe usecase - but I had a feeling you may use it for the wrong reason - hence my rather simple solution to your question was: just use the mainline standard kernel and don't bother with the vfio build
and as seth noticed: modern kernel versions bring along so many driver for so many old hardware hardly anyone still use its quite bloaty and briddle - with the entire card house collapsing due to something noone had a look at in two decades
anyway - nice to read you were able to solve your issue no matter how
Offline