@zerophase I've been having the (arguably) same problem since very long time (see e.g. https://bbs.archlinux.org/viewtopic.php?pid=1966653#p1966653), and that actually forced me to go back to the stock kernel since I never found a solution.
Search Criteria
Package Base Details: linux-ck
Package Actions
Git Clone URL: | https://aur.archlinux.org/linux-ck.git (read-only, click to copy) |
---|---|
Submitter: | graysky |
Maintainer: | graysky |
Last Packager: | graysky |
Votes: | 449 |
Popularity: | 0.35 |
First Submitted: | 2011-07-22 14:51 (UTC) |
Last Updated: | 2022-05-17 00:01 (UTC) |
Packages (2)
Latest Comments
snack commented on 2022-04-14 12:37 (UTC)
zerophase commented on 2022-04-14 12:31 (UTC)
Anyone else having issues getting Docker to start up with the CK kernel?
I've noticed issues with mounting archiso too.
graysky commented on 2022-04-14 11:45 (UTC)
Is anyone interested in testing the 5.17.y ck kernel? I'd like some broader feedback before I push it out to the AUR and to the repo. Please try it here if interested:
You can download a prebuilt package or build yourself.
Please post feedback good or bad to the repo-ck thread to keep it all in one place: https://bbs.archlinux.org/viewtopic.php?pid=2031356
graysky commented on 2021-09-14 17:15 (UTC)
It's not MuQSS, but the PKGBUILD now contains CK's hrtimer patch and the recommended 1000 Hz tick rate.
nTia89 commented on 2021-08-31 16:55 (UTC)
Kr1ss commented on 2021-07-22 09:15 (UTC)
I'm happy to go along with @air-g4p ! Thank you very much @graysky, and all contributors and commenters.
air-g4p commented on 2021-07-22 09:09 (UTC)
@graysky - WOW!! Today marks linux-ck's 10th Birthday!
Thank you very much for all your hard work during the past decade, graysky!
Your efforts are much appreciated...
Cheers
graysky commented on 2021-06-11 01:28 (UTC) (edited on 2021-06-11 01:28 (UTC) by graysky)
Pretty sure, delete the tar ball and re-download :p
vp1981 commented on 2021-06-11 00:19 (UTC)
@graysky, are you sure about b2sum checksum for 'more-uarches-20210610.tar.gz'? I downloaded it manually and checksum didn't match from PKGBUILD: 30d1df754608bb423cbc99c2097ad521baa091b9a3b39df4bd5c2d50c57eec54d8fa0e4a4a04b847c3d1b87ba682cadc8db45fabeefdc9ad7caaf8e77b96e41a tmp/kernel_compiler_patch-20210610.tar.gz
If the 'https://github.com/graysky2/kernel_compiler_patch' git repository is yours would it be feasible to use signed tags to accompany releases? In such cases signed tag would help others to simply change checksum in PKGBUILD. If it is too troublesome then don't bother with it.
snack commented on 2021-06-02 08:05 (UTC)
According to this:
https://www.infoq.com/news/2021/01/docker-engine-cgroups-logging/
the current version of docker should work with cgroups v2. So I guess it's some interplay between the CK patchset and cgroups v2 that breaks docker. Sadly, I got no reply from CK on his blog...
snack commented on 2021-05-28 06:40 (UTC)
@artafinde your suspect was correct. Setting the kernel parameter you suggested makes docker work again with linux-ck. I'm going to report this on CK's blog. Thanks.
artafinde commented on 2021-05-27 14:06 (UTC)
I suspect your issues has something to do with cgroups v2
. Try to replicate the issue after setting (temporarily) systemd.unified_cgroup_hierarchy=0
as a kernel param which forces the cgroup v1
behavior.
GAZ082 commented on 2021-05-27 13:46 (UTC)
@snack had your issue and also a system freeze with the latest release. First time after almost a year of using CK. Went back to Zen.
snack commented on 2021-05-27 06:38 (UTC)
@zerophase I'm not sure. For sure it's something inside the CK patchset (since the stock and many other patched kernels work fine), and it's not MuQSS (see e.g. the comment by Steven Barret on CK's blog stating that Liquorix with MuQSS works fine). I'd need to understand if there is some hope for this to be fixed, otherwise I'll have to ditch linux-ck.
zerophase commented on 2021-05-27 02:30 (UTC)
@snack It has been a bug for awhile. I tried reporting it about a year ago, when trying to author a custom arch install disk, and got some explanation from a guy that this is not a CK issue. (Wasn't CK)
snack commented on 2021-05-26 06:04 (UTC) (edited on 2021-05-26 06:05 (UTC) by snack)
I cannot start docker containers when using the current (5.12) linux-ck-skylake kernel. I get this error:
$ docker run --rm -it -p 80:80 ckulka/baikal:nginx
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: process_linux.go:508: setting cgroup config for procHooks process caused: load program: invalid argument: unknown.
With the stock Arch kernel it works, and seemingly also with other patched kernels like Liquorix (although I didn't try by myself).
I know that it is usually suggested to post to CK's blog for this kind of issue, and in fact I did it but from there I got the advice to post to AUR...
vp1981 commented on 2021-05-19 05:45 (UTC)
graysky> GCC 11 reorders things and since GCC 11 is in [core], I updated the PKGBUILD.
That was a culprit! I updated PKGBUILD, rebuild the package (linux-ck-sandybridge) and was able to boot with linux-ck-sandybridge kernel.
elektorronikci commented on 2021-05-18 18:47 (UTC) (edited on 2021-05-18 18:47 (UTC) by elektorronikci)
@graysky, thanks for your suggestion. There is not any problem for me, I had already corrected it when I saw it on nconfig. I mentioned about it just to inform.
graysky commented on 2021-05-18 17:43 (UTC)
@graysky, no it is GCC 10.2
Right, define an updated mirror and update your system :D
elektorronikci commented on 2021-05-18 17:02 (UTC)
@graysky, no it is GCC 10.2
thaewrapt commented on 2021-05-18 16:05 (UTC)
It could also happen on automation level, where the build system is still using old IDs. I'm building for Skylake right now so I can check if it's actually built for Skylake in the end.
thaewrapt commented on 2021-05-18 16:00 (UTC) (edited on 2021-05-18 16:02 (UTC) by thaewrapt)
Yeah, as I hadn't any issues myself I wanted to suggest "a wrong architecture" source of the problem since I've noticed a change of architecture IDs in the package. For example, I've used 25 for Skylake for quite a long time but in the very last release I see it numbered as 26.
graysky commented on 2021-05-18 15:53 (UTC)
@elektorronikci - Is your system up-to-date? GCC 11 reorders things and since GCC 11 is in [core], I updated the PKGBUILD.
elektorronikci commented on 2021-05-18 15:48 (UTC) (edited on 2021-05-18 15:51 (UTC) by elektorronikci)
There is a problem in the PKGBUILD subarch configuration. When I select Haswell, it was actually Broadwell in the .config file. That may cause boot problem because of some unimplemented machine codes.
vp1981 commented on 2021-05-17 08:46 (UTC)
Ok, I posted message on ck's blog.
I suspect an issue with ck patch and GCC11 but I don't understand why newer processors (haswell and skylake specifically) work.
vp1981 commented on 2021-05-17 03:01 (UTC)
@graysky, thanks I'll do that when I finish testing. I compiled linux-ck-sandybridge 5.12.2, 5.12.3 with the same configuration as 5.12.4 (but without 0002-drm* patch applied) but both kernels didn't boot.
graysky commented on 2021-05-17 00:51 (UTC)
Recommend you post to ck's blog and see what he thinks. I have no insights.
vp1981 commented on 2021-05-17 00:19 (UTC)
Similar situation here: my notebook with Intel Core i5 2410M can't boot with linux-ck-sandybridge 5.12.4 but works fine with distro linux 5.12.4. I locally built linux-ck package (though without patch 0002-drm...) with gcc 11 and config the same as for linux package. Seems that something affects "old" processors because on other hosts with Intel processors of haswell and skylake family both linux-ck-haswell and linux-ck-skylake 5.12.4 boot fine. I didn't tried 5.12.3 version but 5.12.2 worked. I'll try to build 5.12.2 and 5.12.3 for sandybridge and report results.
GAZ082 commented on 2021-05-15 20:45 (UTC)
Had to downgrade to 5.12.1-1-ck-nehalem because linux-ck-nehalem-5.12.4-1 freezes the system at boot when "Loading initial ramdisk".
zepar commented on 2021-05-14 01:35 (UTC)
Hello
I boot to a black screen with 5.12.3-2 on a Gemini lake CPU. Version 5.12.3-1 worked fine. (i'm using the bin version).
graysky commented on 2021-04-23 14:51 (UTC)
Report/ask on ck's blog: https://ck-hack.blogspot.com/
zerophase commented on 2021-04-23 14:18 (UTC) (edited on 2021-04-23 14:22 (UTC) by zerophase)
@coderkun It's probably something to do with Linux-ck I tried mounting the archiso build system for a custom installer, a year ago, and I can't do it on Linux-ck. Works fine on the default. I told CK about, but got no response. I also received message, from someone else, accusing me of causing the problem.
I think we have the same Arch default settings, other than the CK stuff. I don't see why this would be our fault. It's probably a bug in his code.
vltr commented on 2021-04-23 14:13 (UTC)
@coderkun, I already listed that on the forums: https://bbs.archlinux.org/viewtopic.php?pid=1967535#p1967535
I'm still looking for a solution for that, btw :-)
coderkun commented on 2021-04-23 06:58 (UTC)
For a week or two I have been getting the following error when trying to start a docker container:
Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: process_linux.go:458: setting cgroup config for procHooks process caused: can't load program: invalid argument: unknown
It work without error on Arch’s default kernel. Is anyone else experience the same and knows what the issue might be?
Thanks!
artafinde commented on 2021-04-22 10:00 (UTC)
@graysky: You can remove the hack for xz
since 70261 is fixed.
graysky commented on 2021-04-14 15:06 (UTC)
I sure love updating my kernel 4 times in a week, lol
@powerball253- Comments like this serve absolutely no purpose. In general, this package follows the progress of the official kernel which has bumped several times in the past week.[1] Further, no one is forcing you to rebuild a kernel you opted into using in the first place. Please don't spam the comments page with such statements.
graysky commented on 2021-04-02 13:32 (UTC)
@Kr1ss - Updated in 5.11.11-4, thanks.
Kr1ss commented on 2021-04-02 12:21 (UTC) (edited on 2021-04-02 12:41 (UTC) by Kr1ss)
@graysky - Currently, building fails in environments with a modified SRCDEST
folder. (EDIT/ For instance, mine is set to /tmp/makepkg/srcdest
)
linux-ck-5.11.11-3-x86_64-prepare.log
:
xz: /startdir/patch-5.11-ck1.xz: No such file or directory
==> ERROR: A failure occurred in prepare().
Aborting...
==> Removing installed dependencies...
checking dependencies...
[...]
Hence I'd like to suggest a little patch :
diff -U1 old/PKGBUILD new/PKGBUILD
--- old/PKGBUILD 2021-04-02 14:11:24.598889831 +0200
+++ new/PKGBUILD 2021-04-02 14:11:02.978925899 +0200
@@ -107,3 +107,3 @@
unlink "$srcdir/$_ckpatch.xz"
- xz -dc "$startdir/$_ckpatch.xz" > "$_ckpatch"
+ xz -dc "$SRCDEST/$_ckpatch.xz" > "$_ckpatch"
fi
Thank you, cheers !
artafinde commented on 2021-04-02 11:01 (UTC) (edited on 2021-04-02 11:01 (UTC) by artafinde)
@graysky: Thanks already using it - noticed the PR from sirlucian :) Thanks!
graysky commented on 2021-04-02 10:05 (UTC)
@Zalgo - 5.11.11-3 should fix this. See the forum thread for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1965531
graysky commented on 2021-04-02 10:05 (UTC)
@artafinde - with some help, the native option now works with Intel and AMD. You will have to select the correct option though:
...
33. Intel-Native optimizations autodetected by GCC (MNATIVE_INTEL) (NEW)
34. AMD-Native optimizations autodetected by GCC (MNATIVE_AMD) (NEW)
Zalgo commented on 2021-04-02 07:20 (UTC)
Thanks for the tip :) If i figure out a way to fix the PKGBUILD that doesn't require manual untarring I'll pose it here
graysky commented on 2021-04-01 20:20 (UTC)
That's odd. Makepkg doesn't seem to be untarring the patch. If you do it manually and add that to the source array, it works as expected.
Zalgo commented on 2021-04-01 17:26 (UTC)
This currently fails on my system with
Setting config...
sed: can't read ../patch-5.11-ck1: No such file or directory
==> ERROR: A failure occurred in prepare().
Aborting...
can anyone else reproduce? I'll test in a clean chroot
graysky commented on 2021-03-07 19:38 (UTC)
@artafinde - I need to dig deeper, but I think it will be difficult to assign a native CPU out of some configs.
For example, X86_INTEL_USERCOPY
config. I do that now but no other AMD chips are listed by upstream[1].
Further, I believe AMD chips should not be in the X86_P6_NOP
config[2] or X86_CMOV
config[3].
artafinde commented on 2021-03-07 18:50 (UTC) (edited on 2021-03-07 18:50 (UTC) by artafinde)
@graysky checksum for the gcc kernel patch is failing - needs an update.
I noticed the changes in the patch repo and it mentions one should not use native
on AMD chips. What's the reasoning behind this since the gcc 10 (and clang for what matters) can detect the cpu arch just fine:
$ gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1 -E -quiet -v - -march=znver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mwbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mclwb -mmwaitx -mclzero -mno-pku -mrdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-avx512vpopcntdq -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver2
vp1981 commented on 2021-02-23 23:59 (UTC)
@simona, AFAIU, graysky keeps config sync with linux package and these two are in linux-zen but not yet in linux.
simona commented on 2021-02-21 23:19 (UTC)
ashmem_linux and binder_linux missing?
vp1981 commented on 2021-02-08 00:53 (UTC)
@Krlss, same here.
@graysky, why not use git.kernel.org? Like that 0003-SUNRPC-Fix-NFS-READs-the-start-at-non-page-aligned-o.patch::https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=bad4c6eb5eaa8300e065bd4426727db5141d687d
P.S. I like the beginning of commit hash ;)
Kr1ss commented on 2021-02-07 19:15 (UTC) (edited on 2021-02-07 19:18 (UTC) by Kr1ss)
That's weird... Github doesn't always serve the exact same patch !
Sometimes when you download it, the object hashes are abbreviated to 13 characters and sometimes to 14.
That's why the b2sum didn't match here, the first time.
Kr1ss commented on 2021-02-07 18:43 (UTC)
@graysky pls disregard my last comment. Seems like I had an issue with an unclean chroot.
graysky commented on 2021-02-07 18:42 (UTC)
@Kr1ss - Matches here. It is pulled as a source/not included with package.
Kr1ss commented on 2021-02-07 18:30 (UTC) (edited on 2021-02-07 18:36 (UTC) by Kr1ss)
@graysky - The checksum of 0003-SUNRPC-Fix-NFS-READs-the-start-at-non-page-aligned-o.patch
doesn't match after the latest update. ;)
EDIT the file is missing from the AUR sources.
graysky commented on 2021-02-04 20:27 (UTC)
@artafinde - Yes, it was a typo. It doesn't hurt anything.
artafinde commented on 2021-02-04 20:03 (UTC) (edited on 2021-02-04 20:04 (UTC) by artafinde)
Latest update bumbed version to 5.10.13
but forgot to reset to 1
the pkgrel
- not a real issue, but just a reminde for next bump.
bryanjhv commented on 2021-01-09 02:30 (UTC)
@graysky thanks for the update but... I think it's missing a $
($pkgbase
instead of just pkgbase
).
graysky commented on 2021-01-09 02:07 (UTC)
@Distorted - It is undone in the PKGBUILD. Maintaining is easier if I take the Arch config as-is. See https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-ck#n133 and else where in the PKGBUILD other Arch specific calls are commented out.
graysky commented on 2021-01-09 02:03 (UTC) (edited on 2021-01-09 02:07 (UTC) by graysky)
@bryanjhv - sure, 5.10.5-2
Distorted commented on 2021-01-09 00:32 (UTC)
Why is CONFIG_DEBUG_INFO=y
set? It causes builds to use over 10GB in disk space.
bryanjhv commented on 2021-01-08 22:13 (UTC)
@graysky, is there possibility to change _package-headers
' depends
array using "$pkgbase"
instead of fixed 'linux-ck'
? I was building for silvermont
(changing $pkgbase
to linux-ck-silvermont
the way some repositories provide it), and didn't notice it until installing linux-ck-silvermont-headers
asked me to also install linux-ck
instead of linux-ck-silvermont
.
bryanjhv commented on 2021-01-08 22:05 (UTC) (edited on 2021-01-08 22:08 (UTC) by bryanjhv)
Ignoring the error would make things unpredictable. Just remove "-N" option so patch will try to reverse-apply and re-apply.
Kr1ss commented on 2021-01-03 11:14 (UTC)
@LucidComplex That would make it pass though also in situations where the patch
itself fails for a different reason. Not sure if that's what you want to achieve.
LucidComplex commented on 2021-01-03 10:47 (UTC)
prepare()
fails when patches have already been applied. I suppose you can append a || true
to the end of patch
commands in prepare()
to address this.
Kr1ss commented on 2021-01-02 21:24 (UTC) (edited on 2021-01-02 22:06 (UTC) by Kr1ss)
@graysky The checksum for config
doesn't match in the recent release.
EDIT/ Thank you fixing this so quickly ! :)
graysky commented on 2021-01-02 20:36 (UTC)
My bad... git push didn't respond for some reason.
Scimmia commented on 2021-01-02 19:32 (UTC)
I haven't found 5.10.4-2, but as long as linux-headers isn't in the provides array anymore, I'm fine with it.
graysky commented on 2021-01-01 14:33 (UTC)
@scimmia - Please review 5.10.4-2 and comment
Scimmia commented on 2021-01-01 14:24 (UTC)
If packages require that and aren't building against the 'linux' package, they're poorly packaged and should be fixed there, not hacked around here.
graysky commented on 2021-01-01 14:20 (UTC)
At one time there was a need to have the linux-ck-headers package provide linux-headers. Thought it had to do with other packages requiring for actual linux-headers package which is wrong if a user is running linux-ck not linux.
Scimmia commented on 2021-01-01 13:58 (UTC)
See the previous link, this should not be providing linux-headers. Packages saying they provide themselves makes no sense, either.
graysky commented on 2021-01-01 13:53 (UTC)
@Scimmia - Context? "Fixed?"
Scimmia commented on 2021-01-01 13:22 (UTC)
3 updates and the provides has not been fixed. Is there a problem, graysky?
Scimmia commented on 2020-12-11 15:51 (UTC)
Please see the warning here: https://wiki.archlinux.org/index.php/Kernel/Arch_Build_System#Modifying_the_PKGBUILD
graysky commented on 2020-11-28 11:41 (UTC) (edited on 2020-11-28 11:42 (UTC) by graysky)
@nTia89 - fixed in 5.9.11-2 https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=1ab6b24512b14ba2abd23f6e8774d315eed6931a
nTia89 commented on 2020-11-28 08:14 (UTC)
If anyone as issues with suspend/poweroff, this is the reason why: https://bugs.archlinux.org/task/68762 Just to share
graysky commented on 2020-10-20 13:10 (UTC)
@nTia89 - My bad. Order of events in the PKGBUILD matter. Fixed in 5.9.1-2
nTia89 commented on 2020-10-20 08:58 (UTC)
Since last update, there is no more the interactive micro-architecture selection before compilation. Does anyone have the same issue?
air-g4p commented on 2020-08-24 08:36 (UTC)
LOLs!!! I cannot fucking keep up!
IIRC:
- First we had a fucked up 'unfuck-xx' patch
- Then the fucked up unfuck-xx patch got unfucked
- Then @graysky accidentally fucked up something else
- Finally, @graysky unfucked the most recent fuck up
The bottom line: @graysky, happy to report that linux-ck 5.7.17-1 built and installed without any fuck ups! Cheers!
Kr1ss commented on 2020-08-23 13:33 (UTC)
Working fine here.
Thx a lot @ooo & @graysky, cheers !
graysky commented on 2020-08-23 12:07 (UTC)
@ooo - Thanks for the fix. I do not have time to build/test. Can someone please verify that 5.7.17-1 works as expected?
ooo commented on 2020-08-23 11:02 (UTC) (edited on 2020-08-23 11:15 (UTC) by ooo)
@graysky Apparently the error with 5.7.17 was fixed in zen-kernel already, although I didn't test it myself yet.
See the commits from 2020-08-22 at https://github.com/zen-kernel/zen-kernel/commits/5.7/muqss
EDIT: Applying the fix from zen-sources actually gets a bit confusing, so to make this a little simpler, first apply this to patch-5.7-ck1, to make it apply cleanly against 5.7.17: https://pastebin.com/uMMJJq3y
Then apply this to fix the build: https://github.com/zen-kernel/zen-kernel/commit/e7113f2c1d56962d4afabc627ad761c138f5b858
graysky commented on 2020-08-21 13:15 (UTC)
5.7.17 introduces some changes that break the ck1 patch. If someone wants to take a look at that and share a solution, that would be good. I am busy at the moment.
enihcam commented on 2020-08-20 23:19 (UTC)
graysky commented on 2020-08-20 17:27 (UTC) (edited on 2020-08-20 17:27 (UTC) by graysky)
Yes, I fucked it up, should be fixed with https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=473e18c7ccdec2e641eab76ffcf93e87ff6140a1
You don't need to rebuild unless you have [testing] enabled or have it enabled in a clean build root btw.
Kr1ss commented on 2020-08-20 17:11 (UTC) (edited on 2020-08-20 17:16 (UTC) by Kr1ss)
The recent pkgrel
bump broke the validity of the config
checksum, @graysky. Could you update that pls ?
Thank you !
air-g4p commented on 2020-08-09 15:18 (UTC) (edited on 2020-08-09 15:25 (UTC) by air-g4p)
@graysky - 5.7.14-1-ck compiled and installed without issue. Good work, done here!
Kr1ss commented on 2020-08-07 13:02 (UTC)
@graysky I'm running 5.7.14-1-ck
right now, built w/ localmodconfig
.
Looks fine so far, thx.
graysky commented on 2020-08-07 12:39 (UTC)
I cannot reboot now so can someone verify that 5.7.14-ck1 is working properly for me? A small adjustment to ck1 was required.
mrkline commented on 2020-07-31 01:06 (UTC) (edited on 2020-07-31 01:07 (UTC) by mrkline)
Inexplicably, this I ran into the SHA256 issue on one of my machines but not the other. I diffed the two versions of unfuck-ck1.patch
- check it out:
--- unfuck-ck1.patch.works 2020-07-30 18:00:17.955122911 -0700
+++ unfuck-ck1.patch.borked 2020-07-30 18:01:49.000000000 -0700
@@ -8,7 +8,7 @@
1 file changed, 11 insertions(+)
diff --git a/kernel/sched/MuQSS.c b/kernel/sched/MuQSS.c
-index 18a9b4a23e44e..c55c158e8b8e4 100644
+index 18a9b4a23e44ea..c55c158e8b8e42 100644
--- a/kernel/sched/MuQSS.c
+++ b/kernel/sched/MuQSS.c
@@ -3246,6 +3246,17 @@ static inline u64 do_task_delta_exec(struct task_struct *p, struct rq *rq)
It seems like https://github.com/ckolivas/linux/commit/0b69e633d6b0b08ae8547dc4099c8c0985019553.patch is inconsistent in how many digits of the Git SHAs it sends.
vltr commented on 2020-07-27 15:27 (UTC)
I think it's just a wild guess (or just my guts), but I think this might be some caching problem when downloading that particular file. Sometimes you might get it from a different server with a different content (even though this is odd, yes), but might explain why sometimes (and how inconsistently) this happens ...
air-g4p commented on 2020-07-27 05:15 (UTC) (edited on 2020-07-27 05:17 (UTC) by air-g4p)
@graysky and @artafinde: Thanks for trying to reproduce on your respective ends.
Inexplicably, the build completed without any PKGBUILD SHA256 modifications on my other laptop, and again running makepkg -sric
. I suppose this success is consistent with @artafinde's '50% of the time' finding when running makepkg -sric
.
Cheers guys...
artafinde commented on 2020-07-25 16:38 (UTC) (edited on 2020-07-25 16:40 (UTC) by artafinde)
graysky commented on 2020-07-25 14:58 (UTC) (edited on 2020-07-25 15:03 (UTC) by graysky)
air-g4p commented on 2020-07-25 07:26 (UTC) (edited on 2020-07-25 08:07 (UTC) by air-g4p)
oldsadsongs commented on 2020-07-23 17:24 (UTC)
@graysky I was able to reproduce @vltr's report by typing 'makepkg -si' instead of 'makepkg' on a fresh git clone.
vltr commented on 2020-07-23 14:54 (UTC)
@graysky that's ODD. I always build after cleaning up the git repository (git clean -dfx
) ... and the file had that signature I mentioned (hence my build failed). I cleaned (again), ran makepkg
and everything went smoothly this time (with unfuck-ck1-fix-suspend-to-ram.patch
signature being, indeed, 961ed94b8d905f1e901cacb08d253c4170af0a25828111b7558d9c874e923558
). that's really weird ... sorry about the confusion, whatever it happened.
graysky commented on 2020-07-23 13:22 (UTC)
@vltr - You sure?
% sha256sum unfuck-ck1-fix-suspend-to-ram.patch
961ed94b8d905f1e901cacb08d253c4170af0a25828111b7558d9c874e923558 unfuck-ck1-fix-suspend-to-ram.patch
vltr commented on 2020-07-23 12:53 (UTC)
hi there, @graysky! just one problem with 5.7.10: the unfuck-ck1-fix-suspend-to-ram.patch
has a sha256sum of value 961ed94b8d905f1e901cacb08d253c4170af0a25828111b7558d9c874e923558
in the PKGBUILD
, which would not pass the validity check since the correct sha256sum should be 9ad11f720d4dd83ddb8876b453f4526ad35f1ff72465213764fb1d206fea0379
. apart from that, everything works fine. thanks!
nTia89 commented on 2020-06-12 16:05 (UTC)
Above all, thanks @graysky for the change!
Anyway, /tmp
defaults to tmpfs
with size=50% but not everybody has so much RAM. By my own, this is the biggest mistake behind that choice...
dimosd commented on 2020-06-12 15:23 (UTC)
I suggest that you disable CONFIG_DEBUG_INFO, as it was before 5.7.2. That's what I am doing in my own builds anyway to build with a 4GB /tmp.
artafinde commented on 2020-06-12 12:23 (UTC)
graysky: Got my answer: https://bugs.archlinux.org/task/66260
artafinde commented on 2020-06-12 10:14 (UTC)
Kr1ss: I think devs would probably reply don't build in tmpfs (and require ~15G of space instead of ~3.5G) but that's a discussion for forums possibly :D - Thanks graysky.
Kr1ss commented on 2020-06-12 09:54 (UTC)
Thx @graysky ! I was only able to build 5.7.2-1 after blowing up /tmp to 20GiB, that's kind of ridiculous. If a user needs debug symbols they can enable them; I think most users wouldn't need'em anyways.
Cheers !
graysky commented on 2020-06-12 09:21 (UTC)
@artafinde - Fuck it, 5.7.2-2-ck1. Change my mind.
artafinde commented on 2020-06-12 09:13 (UTC)
@graysky - Agree, especially since later we strip it from the bug symbols. I raised the question in IRC but no answer. I guess forums or a bug might have better luck.
graysky commented on 2020-06-12 07:53 (UTC) (edited on 2020-06-12 08:16 (UTC) by graysky)
@artafinde - Yes, the debug stuff causes a failure on one of my machines with 16G of memory building in tmpfs (allocating 14.5G to the tmpfs partition on which the build root resides!)
This change was introduced with 5.7.2-1-arch1 here: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=663b08666b269eeeeaafbafaee07fd03389ac8d7
First question is why do we need the debug options?
"If you say Y here the resulting kernel image will include debugging info resulting in a larger kernel image. This adds debug symbols to the kernel and modules (gcc -g), and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb, etc on the kernel. Say Y here only if you plan to debug the kernel. If unsure, say N."
msw1 commented on 2020-06-12 06:08 (UTC)
I am getting the same error with /tmp running out of space as of version 5.7.2-1.
artafinde commented on 2020-06-11 21:39 (UTC) (edited on 2020-06-11 21:43 (UTC) by artafinde)
nTia89: The default configuration changed (now we produce some debug info) which we strip on packaging and creation of vmlinuz. See config and change in 5.7.1 (https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=b0b10d913f31d37155520286c98ce5282e962060) Config change comes from upstream (arch default config. PS: In my case with 16G /tmp was filled while building without any change in config or PKGBUILD. I suggest to not use tmpfs for now.
nTia89 commented on 2020-06-11 21:14 (UTC) (edited on 2020-06-11 21:17 (UTC) by nTia89)
Staring with 5.7.1, I cannot compile kernel because I run out of space on my /tmp (tmpfs with size of 6GB). Did it change anything recently?
artafinde commented on 2020-06-11 15:59 (UTC)
@as3ii: nvidia-dkms 440.82-2 works for -ck kernel. No idea about bbswitch.
as3ii commented on 2020-06-11 15:53 (UTC)
linux-ck 5.7.2 compiled correctly, but bbswitch and nvidia doesn't work (dkms install error)
Error! Bad return status for module build on kernel: 5.7.2-1-ck
vltr commented on 2020-06-11 15:11 (UTC)
linux-ck 5.7.2 compiled successfully and already up and running. Thanks, @graysky!
duff commented on 2020-06-11 12:29 (UTC)
does not cleanbuild 5.6.16.1 -> 5.7.1-2 tried on two different archlinux hosts (bulldozer und core2)
please fix that
graysky commented on 2020-06-11 10:33 (UTC)
@kwe - Yes, I saw that posted by sir_lucjan. I am reluctant just hack it together without CK's review. See his blog.
kwe commented on 2020-06-11 10:24 (UTC) (edited on 2020-06-11 10:25 (UTC) by kwe)
Getting the same error. It seems to be just that single function that seems to be missing for the compilation to finish, though.
I just added the function that was introduced in https://gitlab.com/alfredchen/linux-bmq/-/commit/ad9eb862e06f395e846a2f2e084e5b0e7eb9ca4b
to the top part of drivers/thermal/cpufreq_cooling.c
and it went through.
Not sure if anything else is missing, though, but please don't consider this a proper fix; it might be dangerous, even. I'm going with this solution, for now, because I have accepted the risk.
henrik_er commented on 2020-06-11 08:51 (UTC)
@graysky yes, exact same error output.
LinguinePenguiny commented on 2020-06-10 16:50 (UTC) (edited on 2020-06-10 16:51 (UTC) by LinguinePenguiny)
As of 5.7.1-2 for me:
LD .tmp_vmlinux.btf
ld: drivers/thermal/cpufreq_cooling.o: in function cpufreq_set_cur_state':
/opt/makepkg/build/linux-ck/src/linux-5.7.1/drivers/thermal/cpufreq_cooling.c:458: undefined reference to
arch_set_thermal_pressure'
BTF .btf.vmlinux.bin.o
scripts/link-vmlinux.sh: line 114: 613105 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1117: vmlinux] Error 1
==> ERROR: A failure occurred in build().
sir_lucjan commented on 2020-06-10 13:39 (UTC) (edited on 2020-06-10 13:40 (UTC) by sir_lucjan)
@graysky
Look at this. I had a similar error using BMQ. Con apparently skipped resync.
https://gitlab.com/alfredchen/linux-bmq/-/issues/6#note_353781623
vltr commented on 2020-06-10 13:38 (UTC) (edited on 2020-06-10 13:38 (UTC) by vltr)
@graysky yes, first I was going to mention here to add pahole
as a dependency but as I was writing it down, you updated the package. Since then, I've been having the error you described.
graysky commented on 2020-06-10 13:34 (UTC)
Is anyone else getting this error:
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.o
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
ld: drivers/thermal/cpufreq_cooling.o: in function `cpufreq_set_cur_state':
/scratch/linux-ck/src/linux-5.7.1/drivers/thermal/cpufreq_cooling.c:458: undefined reference to `arch_set_thermal_pressure'
BTF .btf.vmlinux.bin.o
tag__check_id_drift: subroutine_type id drift, core_id: 1129, btf_type_id: 1127, type_id_off: 0
libbpf: Unsupported BTF_KIND:0
btf_elf__encode: btf__new failed!
free(): double free detected in tcache 2
scripts/link-vmlinux.sh: line 114: 3291862 Aborted (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1117: vmlinux] Error 1
graysky commented on 2020-04-30 14:25 (UTC)
@stano00 - No, you are correct. Fixed in 5.6.8-2
stano00 commented on 2020-04-30 00:51 (UTC) (edited on 2020-04-30 00:52 (UTC) by stano00)
Is the sphinx-workaround.patch actually being applied by your PKGBUILD? I didn't see it print while the other patches were applied.
nTia89 commented on 2020-03-21 10:06 (UTC)
@graysky @kittenlol I am aware of those two lines, since the change happened years(?) ago. Anyway, using #31 architecture and saying 'y' to P6_NOPs question have never given me any issue. Why?
graysky commented on 2020-03-13 11:14 (UTC)
Gets stuck at asking for X86_P6_NOP with _subarch=31
@kittenlol - See commented line 15 and 16.
kittenlol commented on 2020-03-13 11:09 (UTC)
Gets stuck at asking for X86_P6_NOP with _subarch=31
nTia89 commented on 2020-02-16 21:38 (UTC)
Fixed!
Geeko commented on 2020-02-15 18:40 (UTC)
config checksum don't match
blitz commented on 2020-02-04 01:00 (UTC)
@graysky - `Merge branch '5.5/muqss' into 5.5/master' https://github.com/zen-kernel/zen-kernel/commit/82b455de1e967abf6ec5d75b5702a6d7376ddfc9
graysky commented on 2020-01-30 20:42 (UTC)
@redfang - It's in the output.
...
25. Intel Skylake (MSKYLAKE)
26. Intel Skylake X (MSKYLAKEX)
...
normalname012 commented on 2020-01-30 09:47 (UTC)
what option should i choose for intel skylate cpu (7th gen) during installation
graysky commented on 2020-01-28 20:07 (UTC)
@dwzg - Not out of date/no ck1. See: https://wiki.archlinux.org/index.php/Linux-ck#Release_cycle
Bambus89 commented on 2020-01-28 06:05 (UTC)
@graysky @superice97 thx
SuperIce97 commented on 2020-01-25 20:20 (UTC)
@Bambus89 MuQSS uses subtick accounting and tickless expiry, and thus is unaffected by the kernel's tick rate. The only thing that would change by increasing the tick rate from 100 to 1000 would be a slight increase in power consumption and a slight decrease in throughput due to increased overhead. This is why the MuQSS patches automatically set 100Hz as the default. This is talked about in the MuQSS design doc (search for "Tickless expiry"): http://ck.kolivas.org/patches/muqss/sched-MuQSS.txt
graysky commented on 2020-01-25 14:06 (UTC)
@bambus89- ck patchset uses this value
Bambus89 commented on 2020-01-25 10:32 (UTC)
Can you set a Option in pkgconfig for set 1000hz? Why is the kernel set to 100hz and are there benefits for 100hz?
graysky commented on 2019-12-31 18:48 (UTC)
Ah, you were asking for a build in [repo-ck]. I can add on with 5.4.7-1-ck.
trthomps commented on 2019-12-31 16:19 (UTC) (edited on 2019-12-31 16:21 (UTC) by trthomps)
@graysky - ah, yes I know I can build my own, was hoping to get a pre-build binary ;-)
Happy to contribute cpu time if that's needed for repo-ck
graysky commented on 2019-12-31 10:28 (UTC)
@trthomps - You can ... it is option 12. See the PKGBUILD.
trthomps commented on 2019-12-31 09:13 (UTC)
Would it be possible to add a zen2 build as well? I'm running zen successfully but it looks like amd added additional optimizations for the latest zen 2 arch.
[travis@travis-pc ~]$ gcc -c -Q -march=native --help=target | grep march
-march= znver2
Known valid arguments for -march= option:
blazessdd commented on 2019-12-20 12:05 (UTC)
can't add comment a long comment...
even if if i code
put it in code code
graysky commented on 2019-12-12 17:46 (UTC)
@blazessdd - Can you post a build log and link it here?
blazessdd commented on 2019-12-12 16:01 (UTC)
i have set _localmodcfg=y but whenever i try to compile modprobed wont show up and i get a kernel with all the modules compile what can i do?
graysky commented on 2019-11-28 14:14 (UTC) (edited on 2019-11-28 14:14 (UTC) by graysky)
@Althorion -
# Note - the march=native option is unavailable by this method, use the nconfig
# and manually select it.
Althorion commented on 2019-11-28 13:13 (UTC) (edited on 2019-11-28 13:14 (UTC) by Althorion)
Tired with clean PKGBUILD and -march=native
(option 31). Manual patching works just fine, no idea why.
BTW (unrelated problem, I think), I tried manually patching the sources, removing patching from the PKGBUILD, and when I put some value for _subarch=
, it fails at make oldconfig
—it tries giving it the value I put in _subarch=
(that would be 31
), thus entering the never-ending loop of wrong arguments.
Finally, I managed to successfully build the package by manual patching and giving it empty _subarch
.
graysky commented on 2019-11-28 13:06 (UTC)
Need more to go on in order to reproduce. Any edits to the PKGBUILD? Which number are you selecting on the gcc patch stage?
Althorion commented on 2019-11-28 12:46 (UTC)
No, I manually cloned the package (git clone <https://aur.archlinux.org/linux-ck.git>
) and run makepkg -i
on it. I tried removing the folder and re-cloning and clearing the build folder (rm -rf /tmp/makepkg/linux-ck
), but to no avail.
graysky commented on 2019-11-28 12:33 (UTC) (edited on 2019-11-28 12:34 (UTC) by graysky)
How are you building? Works fine here. If you're using an AUR helper, DON'T USE AN AUR HELPER!
...
patching file kernel/time/Kconfig
patching file kernel/time/clockevents.c
patching file kernel/time/hrtimer.c
patching file kernel/time/posix-cpu-timers.c
patching file kernel/time/timer.c
patching file kernel/trace/trace_selftest.c
patching file mm/vmscan.c
patching file net/core/pktgen.c
patching file sound/pci/maestro3.c
patching file sound/soc/codecs/rt5631.c
patching file sound/soc/codecs/wm8350.c
patching file sound/soc/codecs/wm8900.c
patching file sound/soc/codecs/wm9713.c
patching file sound/soc/soc-dapm.c
patching file sound/usb/line6/pcm.c
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
...
Althorion commented on 2019-11-28 12:26 (UTC)
Version 5.4-3 fails at patching: https://gist.github.com/Althorion/a817b8bd5027cf9344af52963d063951
Last few lines:
patching file mm/vmscan.c
patching file net/core/pktgen.c
patching file sound/pci/maestro3.c
patching file sound/soc/codecs/rt5631.c
patching file sound/soc/codecs/wm8350.c
patching file sound/soc/codecs/wm8900.c
patching file sound/soc/codecs/wm9713.c
patching file sound/soc/soc-dapm.c
patching file sound/usb/line6/pcm.c
?[1m Aborting...?(B?[m
graysky commented on 2019-11-23 22:26 (UTC)
No idea what pikaur is but if you are using an i686 fork of Arch, see man makepkg
to see how to ignore the architecture or modify the PKGBUILD itself.
lockheed commented on 2019-11-23 21:11 (UTC)
How can I build this on a 32bit system? I tried it now with pikaur, but I'm getting "linux-ck, linux-ck-headers can't be built on the current arch (pentium4). Supported: x86_64"
I know Arch abandoned 32 bit, but this is a source package so I expected it could be built.
graysky commented on 2019-11-11 18:53 (UTC)
@kyak - Must have missed that when diffing official PKGBUILD vs this. Modifycation will be included in 5.3.11, thanks.
kyak commented on 2019-11-11 18:02 (UTC)
Hi graysky,
Official kernels do now install kernel image to /boot anymore: https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/
Do you plan to follow the same path with linux-ck?
nTia89 commented on 2019-11-08 08:05 (UTC) (edited on 2019-11-08 08:05 (UTC) by nTia89)
Fixed! @sir_lucjan thank you, I tried again and now it compiles flawless. Maybe the reboot fixed the issue, since I upgraded some packages, including mkinitcpio, systemd and gcc...
sir_lucjan commented on 2019-11-07 22:15 (UTC)
mkinitcpio is not involved in the compilation of the kernel at all. It is used only to generate initramfs and it is also possible to do it with dracut.
nTia89 commented on 2019-11-07 18:16 (UTC) (edited on 2019-11-07 18:17 (UTC) by nTia89)
With latest mkinitcpio-27-2
, linux-ck compilation (in real it stops before...) stucks just after patching. No errors printed, just "failed in prepare()"
sir_lucjan commented on 2019-11-03 13:11 (UTC)
@toki1990
It's not a linux-ck problem, it's Manjaro. Due to recent updates in Arch Linux (kmod and mkinitcpio) hooks are no longer provided in kernel only in kmod (depmod-hook) and mkinitcpio (mkinitcpio-install and mkinitcpio remove). Unfortunately, at the moment, as a Manjaro user you will not install most of the current AUR kernels and the problem lies solely with your distribution, i.e. Manjaro.
toki1990 commented on 2019-11-03 13:02 (UTC)
I'm manjaro stable repo user. linux-ck 5.3.8-4 not booting. I'm tried linux-slim 5.3.8-2 custom kernel same problem. Xanmod 5.3.8-1 not doing this. Because problem is this:
"Updating linux-xanmod initcpios... ==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod.preset: 'default' -> -k /boot/vmlinuz-linux-xanmod -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-xanmod.img ==> Starting build: 5.3.8-xanmod6-1-xanmod -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect]...."
Xanmod custom kernel doing this last of compilation. Linux-ck 5.3.8-4 not doing this.
graysky commented on 2019-11-01 20:46 (UTC)
@Superice - Yes, I am ignoring that particular change. For example, the substitution will make _srcver=5.3.8-arch1 in this case whereas this package will be 5.3.8-1-ck which is fine for me.
SuperIce97 commented on 2019-11-01 20:39 (UTC) (edited on 2019-11-01 20:40 (UTC) by SuperIce97)
The pkgver
and _srcver
variables changed in the main linux
package:
pkgver=5.3.8.1
_srcver=${pkgver%.*}-arch${pkgver##*.}
graysky commented on 2019-11-01 18:48 (UTC)
@sir_lucjan - Good catch, thanks. Fixed in 5.3.8-4.
sir_lucjan commented on 2019-11-01 18:09 (UTC)
@graysky
As far as I can see, you forgot to change one line.
- echo "$_kernelname" > localversion.20-pkgname
+ echo "${pkgbase#linux}" > localversion.20-pkgname
air-g4p commented on 2019-10-31 13:36 (UTC) (edited on 2019-10-31 14:34 (UTC) by air-g4p)
@graysky,
It was interesting to see how much 'heat' my wireguard-dkms post generated, and perhaps several of us wireguard-dkms and -ck users have learned some important tips.
Bottom line = tldr version - no action is required provided that: the fou, ip_tunnel and wire
modules are found within lsmod
and/or modprobed-db list
if you run modprobed-db.
Those 3 modules were NOT loaded within MY modprobed-db list, which was quite surprising, given that I have run wireguard-dkms and modprobed-db for a VERY LONG time!
However, once I re-ran: modprobed-db store
, it found the three new modules.
Of course, during a subsequent, clean, rebuild of linux-ck, wireguard-dkms was successfully installed.
Thanks for your input graysky, and to the others who offered their comments.
laenco commented on 2019-10-30 22:38 (UTC) (edited on 2019-10-30 22:39 (UTC) by laenco)
@kwe: OK. I'll try to explain.
-
localmodconfig disables every module, that not exactly listed in provided file
-
the file modprobed.db filling automatically only by modules that are in memory when modprobed-db service runs.
-
fou module did not get into the modprobed.db for some reason
-
But it is needed as indirect dependency for wireguard-dkms
-
when you build kernel with localmodconfig - fou module become disabled
-
And consequent build of wireguard-dkms fails.
As I can see - the most simple way to fix such a problem - is to add fou/fou6 modules into modprobed.db manually.
Or - load them and run modprobed-db.service for the same thing.
Blame me, if I wrong, cause there is more coffee than blood in veins)
kwe commented on 2019-10-30 22:17 (UTC)
@laenco: Either I'm misunderstanding you or I have to disagree.
When digging though lsmod AFTER HAVING USED WIREGUARD (so I assume all the required modules have been loaded), I can't seem to find any specific modules that are NOT in modprobed.db. It seems to me like the part where .config is configured for the kernel compilation process is assembled in a wrong way, missing out on the loaded (!) modules. This doesn't seem to have anything to do with modprobed-db as far as I can tell (?).
laenco commented on 2019-10-30 22:13 (UTC)
@kwe: so it's look like wireguard needs fou module for dkms build/install, but does not load it during routine operations, so modprobed-db did not detect it.
You could try to add fou and fou6 modules to modprobed.db manually and rebuild.
kwe commented on 2019-10-30 22:06 (UTC)
@laenco: Here is my current system state:
$ grep -i fou ~/.config/modprobed.db
$ lsmod | grep -i fou
$ lsmod | grep -i wire
wireguard 233472 0
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 16384 1 wireguard
$ grep -i tun ~/.config/modprobed.db
ip6_udp_tunnel
tun
udp_tunnel
When I run makepkg to extract the linux-ck src
directory, I end up with this .config diff against the current running kernel config:
$ zdiff /proc/config.gz config.last
1069d1068
< CONFIG_NET_IP_TUNNEL=m
1077,1078c1076
< CONFIG_NET_UDP_TUNNEL=m
< CONFIG_NET_FOU=m
---
> # CONFIG_NET_FOU is not set
1116d1113
< CONFIG_IPV6_FOU=m
laenco commented on 2019-10-30 21:51 (UTC) (edited on 2019-10-30 21:53 (UTC) by laenco)
@kwe could you check ~/.config/modprobed.db for presence of "fou"/"fou6" modules?
The question is "If localmodconfig is unable to detect fou or is it a modprobed-db detection problem"?.
kwe commented on 2019-10-30 21:28 (UTC)
@graysky I am building linux-ck with modprobed-db, and for some reason, I always end up with those configuration options being disabled. I have to re-enable them manually every single time.
graysky commented on 2019-10-30 20:11 (UTC)
% uname -r
5.3.8-1-ck
% zgrep CONFIG_NET_FOU /proc/config.gz
CONFIG_NET_FOU=m
CONFIG_NET_FOU_IP_TUNNELS=y
Should be there as a module. Building wireguard-dkms on CK works for me:
# pacman -S wireguard-dkms
resolving dependencies...
looking for conflicting packages...
Packages (2) dkms-2.7.1-1 wireguard-dkms-0.0.20191012-1
Total Download Size: 0.24 MiB
Total Installed Size: 1.75 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
wireguard-dkms-0.0.20191012-1-x86_64 245.7 KiB 3.43 MiB/s 00:00 [############################################] 100%
(2/2) checking keys in keyring [############################################] 100%
(2/2) checking package integrity [############################################] 100%
(2/2) loading package files [############################################] 100%
(2/2) checking for file conflicts [############################################] 100%
:: Processing package changes...
(1/2) installing dkms [############################################] 100%
Optional dependencies for dkms
linux-headers: build modules against the Arch kernel [installed]
linux-lts-headers: build modules against the LTS kernel
linux-zen-headers: build modules against the ZEN kernel
linux-hardened-headers: build modules against the HARDENED kernel
(2/2) installing wireguard-dkms [############################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Install DKMS modules
==> dkms install wireguard/0.0.20191012 -k 5.3.7-arch1-2-ARCH
==> dkms install wireguard/0.0.20191012 -k 5.3.8-1-ck
Kr1ss commented on 2019-10-30 19:41 (UTC)
FWIW, I'm also setting that option manually, hence I'd support @air-g4p's request. Thx again for maintaining this btw !
Cheers !
air-g4p commented on 2019-10-30 19:36 (UTC)
@graysky - wireguard-dkms failed to build on CK with this output:
I asked the devs at #wireguard about this failure, and was told I needed to enable: CONFIG_NET_FOU
(FOU = foo over udp)
After enabling that and rebuilding linux-ck --> Success.
Per Jason's (zx2c4), the lead wireguard dev, suggestion, can you please enable CONFIG_NET_FOU by default on linux-ck?
Thanks graysky
graysky commented on 2019-10-27 14:46 (UTC) (edited on 2019-10-29 20:42 (UTC) by graysky)
@timo - OK... that is likely because your .config got tweaked due to your CC= line. I opened a flyspray shown below. See it for a solution: https://bugs.archlinux.org/task/64315
timo_capa commented on 2019-10-27 14:03 (UTC)
@graysky What I did was add CC=clang
before make in the PKGBUILD to use Clang as compiler.
What worked was using makepkg for compiling till it gets stuck, and then end it with make modules_install and make install from the src folder. Doesn't give a package for pacman, but works.
I've tried linux-pf the same way, though that got stuck at the same place :)
graysky commented on 2019-10-27 12:34 (UTC)
@simona - the recent failure of dkms is due to the fact that there are both a newer version of the toolchain and of the dkms packages in [testing] currently. The advice I have been given is that it always a good idea to build the kernel against [testing] to prevent version mismatch errors when toolchain packages come out of [testing] and into [core].
I need to figure out what the best option is now.
@timo_capa - I am not sure how you go about building in Clang... I am using the official Arch devtools for clean chroot building. Are you patching the kernel source with ck1?
simona commented on 2019-10-27 11:52 (UTC)
==> dkms install vboxhost/6.0.14_OSE -k 5.3.7-1-ck-skylake Error! Bad return status for module build on kernel: 5.3.7-1-ck-skylake (x86_64)
timo_capa commented on 2019-10-12 12:21 (UTC) (edited on 2019-10-12 14:43 (UTC) by timo_capa)
I'm not sure if this is something you're interested in fixing, but compiling the kernel with Clang gets stuck at Installing boot image...
. I'm assuming it's spamming something related to Kconfigs in the background related to GCC, as cancelling the build shows
"install: cannot stat '*'$'\n''* Restart config...'$'\n''*'$'\n''*'$'\n''* GCC plugins'$'\n''*'$'\n''Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW) ': No such file or directory"
E: Manually compiling a kernel from the tarball from kernel.org works and boots.
Klotz commented on 2019-10-12 12:21 (UTC)
For version 5.2.21, I think applying the sed expression sed -i -re 's/(CFLAGS[[:space:]]+)\+=/\1:=/'
to the ck stuff prior to patching will avoid a patch failure in tools/objtool/Makefile.
Pillgar commented on 2019-10-06 01:01 (UTC) (edited on 2019-10-06 12:34 (UTC) by Pillgar)
I'm getting DKMS errors when upgrading to linux-ck-ivybridge-5.2.19-1. On step (3/4) Install DKMS modules: Error! Bad return status for module build on kernel: 5.2.19-1-ck-ivybridge (x86_64).
It seems initcpio image can't build with any DKMS modules over ck-ivybridge-5.2.19-1
I'm using nvidia 435.21 dkms and vboxhost 6.0.12 dkms.
In make.logs I see error: incompatible gcc/plugin versions
I'm using gcc (9.1.0-2 updated: 2019-06-25)
Edit: There literally was just an update for gcc a few hours after I posted this. All solved.
Lessaj commented on 2019-09-15 19:14 (UTC)
It is building successfully now.
graysky commented on 2019-09-15 18:36 (UTC)
Please try 5.2.14-4
Lessaj commented on 2019-09-15 18:20 (UTC) (edited on 2019-09-15 18:20 (UTC) by Lessaj)
The addition of fix_patch-5.2-ck1_for_systemd-detect-virt_containers.patch seems to cause these last 3 lines to be dropped from kernel/sched/MuQSS.c even though they are in patch-5.2-ck1 which causes a build failure.
"#endif / CONFIG_CGROUP_SCHED /"
"#undef CREATE_TRACE_POINTS"
air-g4p commented on 2019-08-30 09:39 (UTC) (edited on 2019-08-30 15:38 (UTC) by air-g4p)
@graysky - It now appears the issue is exclusively related to modprobed-db. My latest build worked well in a clean chroot with ccache enabled, but I used an empty _localmodcfg=
statement. Of course, the build time was quite lengthy, but it worked.
Any thoughts on a workaround, or a permanent fix?
Thanks for your help graysky....
graysky commented on 2019-08-28 18:41 (UTC)
@air-g4p - I do not use ccache so I cannot comment. I will say that builds using distcc on 5.2 fail where they worked fine with 5.1. Related? The change in the chroot build might be due to the modprobed-db change I made wherein the old behavior was to call it in recall mode via sudo which was always hacky in a PKGBUILD. The current method reads the database directly which the build scripts might not allow since your homedir is outside of the build root. Try building in the chroot without using the modprobed-db enabled; that will probably work.
air-g4p commented on 2019-08-28 13:08 (UTC)
@graysky - built without issue with ccache disabled, while running makepkg -sri
so what is driving that fail?
Also, why did -ck previously build (many times) without issue in a clean chroot, but now it fails?
Thanks...
graysky commented on 2019-08-27 19:09 (UTC)
@air-g4p - Disable ccache and try again
air-g4p commented on 2019-08-27 08:25 (UTC) (edited on 2019-08-27 12:34 (UTC) by air-g4p)
@graysky,
In a clean folder, and running makepkg -sri
the build failed, but in a different way. I got as far as:
-> Applying patch 0004-drm-amdgpu-pin-the-csb-buffer-on-hw-init-for-gfx-v8.patch... patching file drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c -> Setting config... -> Applying enable_additional_cpu_optimizations_for_gcc_v9.1+_kernel_v4.13+.patch ... patching file arch/x86/include/asm/module.h patching file arch/x86/Kconfig.cpu patching file arch/x86/Makefile patching file arch/x86/Makefile_32.cpu HOSTCC scripts/basic/fixdep /usr/bin/ccache: invalid option -- 'W'
then I also saw:
make[1]: [scripts/Makefile.host:90: scripts/basic/fixdep] Error 1 make: [Makefile:508: scripts_basic] Error 2 ==> ERROR: A failure occurred in prepare(). Aborting...
Any ideas? Thanks
graysky commented on 2019-08-26 21:05 (UTC)
@air-g4p - Does it build outside of the chroot? I'm thinking the chroot build script doesn't look outside of that environment and will therefore fail.
air-g4p commented on 2019-08-26 16:51 (UTC)
@graysky,
I'm seeing several inexplicable errors with the latest build:
When trying to build ck with time extra-x86_64-build
in a clean chroot, I get as far as:
Kernel Live Patching (LIVEPATCH) [N/y/?] n
configuration written to .config
-> No modprobed.db data found /startdir/PKGBUILD: line 157: exit1: command not found ==> ERROR: A failure occurred in prepare(). Aborting... ==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/user/build
this DESPITE: modprobed-db store showing:
180 modules currently loaded per /proc/modules 180 modules are in /home/user/.config/modprobed.db
AND the correct path in PKGBUILD:
_localmodcfg=/home/user/.config/modprobed.db
Also, please have a look at Line 157 of PKGBUILD.
Did you intend to type exit
as opposed to your current exit1
?
I have never seen this modprobed error previously.
Ideas are welcome...
graysky commented on 2019-08-20 19:31 (UTC)
I haven't made an ISO/no idea. You could ask on CK's blog why it fails with that mount command. I do not edit beyond the changes his patchset make.
zerophase commented on 2019-08-20 00:46 (UTC)
@graysky archiso failing to build appears to be an issue with the CK kernel. No, idea what's different from Arch, as the only thing I changed was the compression algorithm used for initramfs.
Have any idea what might be causing the mount failure with CK?
zerophase commented on 2019-08-17 18:41 (UTC)
@graysky This is a forum post I made on the issue. It looks like folders under the work directory are not able to be identified as mount points. If you install archiso, and just run sudo cp -r /usr/share/archiso/configs/releng/ ~/archlive; cd ~/archlive; sudo ./build.sh -v
The issue should reproduce itself.
I just happened to decide to try the Arch kernel to see if that resolved the build failure I was receiving, and everything just built successfully. Looks like others have identified this issue in the past, but did not report it. I have a feeling it has something to do with mkarchiso
.
graysky commented on 2019-08-17 11:10 (UTC)
You have provided nothing to go on...
zerophase commented on 2019-08-17 00:42 (UTC) (edited on 2019-08-17 00:43 (UTC) by zerophase)
I'm having issues getting archiso to successfully build an image when running the CK kernel. Everything builds fine with the default kernel. Is anyone else having this issue? Could it be from disabling initramfs support, other than LZ4? Is this a CK issue or archiso issue?
rzax666 commented on 2019-08-09 09:57 (UTC) (edited on 2019-08-09 10:29 (UTC) by rzax666)
@charveey thx but fix pkgbuild please ;D
Deadstar commented on 2019-08-09 05:19 (UTC)
Will the AMD Llano processors family be added to the kernel?
charveey commented on 2019-08-07 00:55 (UTC) (edited on 2019-08-07 00:58 (UTC) by charveey)
@rzax666 if you're interested you can just install my package, linux-bootsplash which provides the kernel with framebuffer bootsplash support. I personally run the 5.2.5 ck kernel with the patch you want. I got a hardware issue on my computer so I can't test the latest version (5.2.6)
rzax666 commented on 2019-08-07 00:31 (UTC) (edited on 2019-08-07 00:33 (UTC) by rzax666)
please add this patch - https://github.com/philmmanjaro/linux-bootsplash
graysky commented on 2019-08-03 19:22 (UTC) (edited on 2019-08-03 19:23 (UTC) by graysky)
Yeah, I think you shouldn't use native in non-interactive mode. See the comments:
Note - the march=native option is unavailable by this method, use the and manually select it.
kwe commented on 2019-08-03 15:01 (UTC) (edited on 2019-08-03 15:03 (UTC) by kwe)
Since switching from _subarch=20
(MIVYBRIDGE) to _subarch=28
(MNATIVE) in the PKGBUILD, it won't build:
24. Intel Skylake X (MSKYLAKEX) (NEW)
25. Intel Cannon Lake (MCANNONLAKE) (NEW)
26. Intel Ice Lake (MICELAKE) (NEW)
> 27. Generic-x86-64 (GENERIC_CPU)
28. Native optimizations autodetected by GCC (MNATIVE) (NEW)
choice[1-28?]: 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 28
The last message keeps looping forever.
When I switch back to the default _subarch=
with no value, the process/interaction seems suboptimal:
- it asks me choice[1-28?]:
- I choose 28
- it asks me Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW)
- I choose y
- it does the modprobed-db recall (as configured)
- it asks me BT8XX GPIO abuser (GPIO_BT8XX) [N/m/y/?] (NEW)
- I choose n (why does this ask me every time?)
- it asks me Studio Evolution SE6X (SND_SE6X) [N/m/?] (NEW)
- I choose n (again, why does this ask me every time?)
- ==> Sources are ready.
air-g4p commented on 2019-07-30 06:28 (UTC)
@graysky - Thanks, and understood.
@zerophase - Thanks, what you said made sense, and got me thinking about my chroot. As I had been using makechrootpkg
of late to build linux-ck, I completely forgot that command neither cleans, nor updates a chroot.
As soon as I built linux-ck with my typical extra-x86_64-build
my chroot got cleaned and updated, which resolved all the DKMS incompatible gcc versions installation issues.
zerophase commented on 2019-07-29 19:11 (UTC)
@air-g4p if you can rollback to the last good kernel you should be able to install. The last time I had dkms issues was from updating the kernel multiple times without rebooting. On the second kernel update I usually receive a bunch of errors about the version of the kernel dkms is looking for does not exist. Pretty sure that's what is happening to you too.
graysky commented on 2019-07-29 19:06 (UTC)
I do not use dkms so I wouldn't know where to start with it.
air-g4p commented on 2019-07-29 13:34 (UTC) (edited on 2019-07-29 13:35 (UTC) by air-g4p)
@graysky - Saw these DKMS installation errors today after building -ck on my fully updated system:
(2/6) Install DKMS modules ==> dkms install bbswitch/0.8 -k 5.2.4-1-ck Error! Bad return status for module build on kernel: 5.2.4-1-ck (x86_64) Consult /var/lib/dkms/bbswitch/0.8/build/make.log for more information. ==> dkms install vboxhost/6.0.10_OSE -k 5.2.4-1-ck Error! Bad return status for module build on kernel: 5.2.4-1-ck (x86_64) Consult /var/lib/dkms/vboxhost/6.0.10_OSE/build/make.log for more information. ==> dkms install nvidia/430.34 -k 5.2.4-1-ck Error! Bad return status for module build on kernel: 5.2.4-1-ck (x86_64) Consult /var/lib/dkms/nvidia/430.34/build/make.log for more information. ==> dkms install wireguard/0.0.20190702 -k 5.2.4-1-ck Error! Bad return status for module build on kernel: 5.2.4-1-ck (x86_64) Consult /var/lib/dkms/wireguard/0.0.20190702/build/make.log for more information.
My /build/make.logs show multiple instances of:
cc1: error: incompatible gcc/plugin versions cc1: error: fail to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so
Is there a workaround, or a solution?
graysky commented on 2019-07-27 22:15 (UTC)
@SuperIce - Right you are thanks, fixed.
SuperIce97 commented on 2019-07-27 22:13 (UTC) (edited on 2019-07-27 22:13 (UTC) by SuperIce97)
@graysky The 26 should be changed to 27 in this comment in the PKGBUILD: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-ck#n15
nTia89 commented on 2019-07-27 09:25 (UTC)
great!
graysky commented on 2019-07-26 20:22 (UTC)
@nTia89 - Yes, but was waiting for 5.2.3 to incorporate that and the other 2 patches. See: https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=c4e43c48637e
nTia89 commented on 2019-07-26 13:02 (UTC)
@graysky Don't you follow upstream changes about CONFIG_GCC_PLUGIN_STACKLEAK
[1]?
vinibali commented on 2019-07-21 06:54 (UTC)
5.2 patches are out now: http://ck.kolivas.org/patches/5.0/5.2/5.2-ck1/
timo_capa commented on 2019-07-14 07:36 (UTC) (edited on 2019-07-14 07:39 (UTC) by timo_capa)
@nivekuil It shouldn't. I checked the config, and "CONFIG_USER_NS_UNPRIVILEGED" is enabled.
Also see: https://aur.archlinux.org/cgit/aur.git/tree/config?h=linux-ck#n166
nivekuil commented on 2019-07-14 07:18 (UTC)
Does this linux-zen bug also apply here? https://bugs.archlinux.org/task/62990
graysky commented on 2019-06-17 19:05 (UTC)
@freenes - if the unpatched kernel doesn't work there is little likelihood that the MuQSS scheduler will fix it. You need to find out what's breaking it.
freenestor commented on 2019-06-17 02:06 (UTC)
@graysky @zerophase Thank you for advises. I tried 5.1.8-arch, and updated bios(my laptop model is ThinkPad T430u, bios is updated to Version: H6ETA0WW 2.18 Release Date: 06/01/2018), neither working.
zerophase commented on 2019-06-15 21:31 (UTC)
@graysky The version from the aur seems to have that feature disabled by default.
graysky commented on 2019-06-15 10:28 (UTC)
@gee - I try to keep linux-ck as close to the official ARCH kernel as I can. I do not know what negative effect changing that parameter might have for other users. Recommend you build from the AUR yourself modifying it as you see fit.
gee commented on 2019-06-15 10:12 (UTC)
Hello again,
I'll retry my last request in an easier way if you don't mind graysky.
Would you mind using 'N' for Linux kconfig's RAID6_PQ_BENCHMARK? I have not been able to find a way to do so without altering the kconfig file yet, and since I grab the kernels from your repos, it wouldn't work that way.
Setting it to 'N' save a few seconds on boot time, which I think is quite nice.
zerophase commented on 2019-06-14 17:38 (UTC)
@freenestor if that does not work try updating your bios / uefi. I would also post more system specs. As a last, resort you could try doing a clean install just to rule out configs breaking from waiting awhile to upgrade.
I think the issue probably has something to do with the motherboard, though. If nothing works try to use the warranty for a replacement. A new version of the same mobo might just work.
graysky commented on 2019-06-14 17:14 (UTC)
@freenestor - can you boot 5.1.x-arch without the parameter? Rule out ck1 patchset as the cause in other words.
freenestor commented on 2019-06-14 05:56 (UTC)
I cannot boot linux-ck 5.1.x without nolapic kernel parameter, and with nolapic parameter the performance is worse. I can boot linux-ck 4.19.x normally. Can anyone give some advises?
graysky commented on 2019-06-13 20:27 (UTC)
@ismet - Something happened with the rsync mirror. Fixing now, please try in 5 min or so.
ismet commented on 2019-06-13 16:21 (UTC)
Hey graysky, pre-compiled linux-ck-zen package cannot be downloaded from repo-ck repositories.
error: failed retrieving file 'linux-ck-zen-5.1.9-2-x86_64.pkg.tar.zst' from repo-ck.com : The requested URL returned error: 404
Althorion commented on 2019-06-11 08:07 (UTC)
Shame. Seems like a useful option.
graysky commented on 2019-06-10 18:46 (UTC)
@Althorin - Purely archival.
Althorion commented on 2019-06-10 11:18 (UTC)
The PKGBUILD saves config.last for later, but never does anything with it (i.e., giving the option to use one as a basis for compilation). Is there something missing?
graysky commented on 2019-05-06 18:09 (UTC)
@galaxy0419 - Not out of date, https://wiki.archlinux.org/index.php/Linux-ck#Release_cycle
gatlinnewhouse commented on 2019-04-27 21:00 (UTC)
@gatlinnewhouse
I fixed the issue, it seems there was a problem with my makepkg.cfg
gatlinnewhouse commented on 2019-04-18 10:32 (UTC)
trying to compile this now causes my computer to freeze, drop out of the x server and go back to the vt login screen (and my configs automatically log me in) and just sit there, fans spinning inconsistently
sir_lucjan commented on 2019-04-04 16:07 (UTC)
@graysky
You could rebase http://ck.kolivas.org/patches/5.0/5.0/5.0-ck1/patches/0002-Fix-Werror-build-failure-in-tools.patch against 5.0.6
graysky commented on 2019-04-03 23:18 (UTC) (edited on 2019-04-03 23:18 (UTC) by graysky)
CK1 needs to be tweaked to patch into 5.0.6 it seems...
patching file tools/objtool/Makefile
Hunk #1 FAILED at 31.
1 out of 1 hunk FAILED -- saving rejects to file tools/objtool/Makefile.rej
Can someone post to CK's blog?
RaskAr commented on 2019-03-29 12:22 (UTC) (edited on 2019-03-29 13:02 (UTC) by RaskAr)
Hello graysky, I use to patch the local copy of the PKGBUILD to allow the currently running config (/proc/config) to be used as base config so maybe it can be useful to merge it ?
BS86 commented on 2019-03-10 08:26 (UTC)
The patchset for 5.0 is live: http://ck.kolivas.org/patches/5.0/5.0/5.0-ck1/
He is just too busy to officially announce: http://ck-hack.blogspot.com/2018/12/linux-420-ck1-muqss-version-0185-for.html?m=1#comment-form
Kr1ss commented on 2019-02-16 19:05 (UTC) (edited on 2019-02-16 19:06 (UTC) by Kr1ss)
Great.
Thx for researching and fixing so quickly ! PKGREL 2 built fine. (EDIT without changing any configs)
graysky commented on 2019-02-16 18:30 (UTC) (edited on 2019-02-16 18:40 (UTC) by graysky)
Seems like the ck patchset needs a tweak: http://ck-hack.blogspot.com/2018/12/linux-420-ck1-muqss-version-0185-for.html?showComment=1550063841657#c3680780559065276989
Testing now and will push 4.20.10-2 if successful.
Kr1ss commented on 2019-02-16 18:27 (UTC)
Looks like I could build after setting CONFIG_KVM
and CONFIG_KVM_INTEL
from <m>
to [y]
.
I'm building for Haswell architecture btw.
graysky commented on 2019-02-16 18:19 (UTC)
Yea it tricked me into thinking it built find until I found 0 packages built from the batch... currently reviewing build log to see wtf.
Kr1ss commented on 2019-02-16 17:59 (UTC)
Yep, me too :
ERROR: "sched_smt_present" [arch/x86/kvm/kvm-intel.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1275: modules] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> Removing installed dependencies...
checking dependencies...
Package (2) Old Version Net Change
bc 1.07.1-3 -0.17 MiB
inetutils 1.9.4-7 -1.12 MiB
Total Removed Size: 1.29 MiB
:: Do you want to remove these packages? [Y/n]
:: Running pre-transaction hooks...
(1/1) Removing old entries from the info directory file...
:: Processing package changes...
removing inetutils...
removing bc...
:: Running post-transaction hooks...
(1/2) Reloading system manager configuration...
Skipped: Current root is not booted.
(2/2) Arming ConditionNeedsUpdate...
==> ERROR: Build failed, check /var/lib/buildroot/x86_64/kriss/build
zerophase commented on 2019-02-16 17:54 (UTC)
Is 4.20.10 giving anyone else compile errors?
gee commented on 2019-02-15 09:29 (UTC)
It probably is out of focus, but it would be really nice to add this patchset: https://lists.ubuntu.com/archives/kernel-team/2019-January/098018.html
My boot takes 2 sec to test various raid6 algorithms, when I don't even use raid... Being able to specify the algorithm to use would shave that time off and be awesome.
air-g4p commented on 2019-01-17 07:23 (UTC)
@graysky,
Thanks for pointing out my non-Arch standard settings and I forgot there was a new /etc/makepkg.conf.pacnew hanging about. I'm back to standard now.
I see you removed 'subarch 27' from PKGBUILD, and now as expected, linux-ck-4.20.3-1-x86_64.pkg.tar.xz and its headers build without issue.
graysky commented on 2019-01-17 00:50 (UTC)
@air-g4p - As well, your CFLAGS are not the Arch standard... drop -fstack-protector-strong
per the new makepkg.conf in pacman-5.1.2-2.
graysky commented on 2019-01-16 21:07 (UTC) (edited on 2019-01-17 00:51 (UTC) by graysky)
@air-g4p - See the comments in the PKGBUILD and the discussion here in the AUR.
<h1>Note - the march=native option is unavailable by this method, use the nconfig and manually select it.</h1>
In short, I do not know how to allow the native option to get set via the method used for the other discretely defined options.
air-g4p commented on 2019-01-16 20:35 (UTC)
@graysky,
I'm running an i7 8550U.
Under both /etc/makepkg.conf and ~/chroot/root/etc/makepkg.conf, I have these identical settings:
ARCHITECTURE, COMPILE FLAGS
CARCH="x86_64" CHOST="x86_64-pc-linux-gnu"
-- Compiler and Linker Flags
CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j8"
-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments" DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
Is there anything you see in my setup that would drive:
'The build fails with hundreds of instances of:
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 27'
that I mentioned when '_subarch=27' is set?
I normally build linux-ck in a clean chroot without issue, but this infinite loop issue disturbs me.
graysky commented on 2019-01-13 12:11 (UTC)
I remember looking at this a while ago and concluding it isn't possible... prove me wrong :)
air-g4p commented on 2019-01-13 09:37 (UTC)
Hi graysky,
I can confirm the build loop issue zoopp mentioned last month is still present in linux-ck 4.20.1-1.
With this PKGBUILD option set:
27. Native optimizations autodetected by GCC (MNATIVE)
_subarch=27
The build fails with hundreds of instances of:
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 27
It appears to me that the only way out of this loop is crtl-c.
Of course, the build proceeds normally with any other appropriate subarch assigned.
graysky commented on 2019-01-12 09:38 (UTC)
@artafinde - ck1 disables NUMA
artafinde commented on 2019-01-12 09:32 (UTC)
@vltr: try enabling NUMA on ck.
vltr commented on 2019-01-11 09:53 (UTC)
@marceliq ohhh ... I haven't seen that. And that's actually a real bummer :(
marceliq commented on 2019-01-11 09:46 (UTC) (edited on 2019-01-11 09:47 (UTC) by marceliq)
In patch-4.20-ck1 there is:
@@ -896,6 +913,7 @@ config CGROUP_DEVICE
config CGROUP_CPUACCT
bool "Simple CPU accounting controller"
+ depends on !SCHED_MUQSS
help
Provides a simple controller for monitoring the
total CPU consumed by the tasks in a cgroup.
which disable CPUACCT if SCHED_MUQSS is enabled :(
vltr commented on 2019-01-11 09:41 (UTC) (edited on 2019-01-11 10:13 (UTC) by vltr)
Thanks, @graysky! Yeah, I tried to revert some of the changes - docker stopped working after 4.19.4
or 4.19.5
(from repo-ck
), but I just got some time to find the source of the error now. I thought it was CONFIG_CGROUP_CPUACCT
at first because of error given by docker:
$ docker run --rm hello-world
docker: Error response from daemon: unable to find "cpuacct" in controller set: unknown.
That's just an example. Any other docker command (build, run, etc) would eventually ran into this issue (although the docker daemon seem to work normally).
This is something that doesn't happen in the stock kernel (and I make use of testing repositories as well). Anyway, I reverted not only that flag but some others as well (I actually did the diff myself earlier), but docker is still a no go. I'm not that expert in the kernel to go further and analyze what's wrong, unfortunately. I wanted to share my experience here in case anyone bumps into the same problem.
Would you mind providing me CK's blog so I can post there as well?
Thanks a lot!
EDIT
Just found out the issue, pointed out by @marceliq and then CK's blog and comments regarding this issue as well as the forum post related. Thanks!
graysky commented on 2019-01-10 20:25 (UTC) (edited on 2019-01-10 20:28 (UTC) by graysky)
@vltr - It would appear the ck1 patchset does this, see here for a diff of the Arch config before and after simply patching with CK1: https://github.com/graysky2/4.20.1_temp/commit/82d2aee40035766d2e225e4b2a3db36faa187273
Recommend you post to CK's blog referencing that diff and your problem. Might be that he did not mean to do that if I am correct.
vltr commented on 2019-01-10 11:28 (UTC)
Hello, @graysky! Just one question: is there any reason why the CONFIG_CGROUP_CPUACCT
flag is not set anymore on linux-ck? Thanks a lot!
graysky commented on 2019-01-01 14:42 (UTC)
@saren - sorry about that... fixed now but did not bump the pkgver.
Saren commented on 2019-01-01 06:13 (UTC)
Hi, since 4.20-ck NUMA is disabled regardless of _NUMAdisable
. $ numactl -s
shows No NUMA support available on this system.
zoopp commented on 2018-12-27 12:46 (UTC)
I usually build with native optimisations detected by GCC however there's a problem if I assign anything to the _subarch variable. Early during the build this question pops up:
Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW)
.. which is answered with the value of _subarch variable (27 in my case).
Since this isn't an accepted answer, the question loops endlessly.
Not really a big issue but I thought I should mention it.
air-g4p commented on 2018-12-12 09:51 (UTC)
@graysky:
Same here: Built linux-ck 4.19.8-1 without issue yesterday, and all seems to be running well and as expected since then.
Ropid commented on 2018-12-09 03:07 (UTC) (edited on 2018-12-09 03:11 (UTC) by Ropid)
@graysky:
On first look, it seems to work fine for me. I built and booted into this 4.19.8 version a few hours ago.
$ uname -r
4.19.8-1-ck
$ uptime
04:05:41 up 5:57, 1 user, load average: 0.32, 1.34, 1.90
I don't see anything unusual happening in the journal. Programs, games and the desktop don't seem to misbehave.
graysky commented on 2018-12-08 17:22 (UTC)
I heard from CK that it is unlikely he will be able to unfuck 4.19-ck1 before the release of 4.20. Fortunately, a user on the blog posted two patches which seem to do just that. I have adapted them to the PKGBUILD for 4.19.7 and for 4.19.8. I have been testing 4.19.7-ck1 and it has been running without issues. I am building 4.19.8-ck1 now. I pushed 4.19.8 to the AUR just now and am requesting some user feedback on stability and performance. I will build the repo set once we some confirmation that all is well. Thanks.
graysky commented on 2018-12-05 22:53 (UTC)
@lukpod - Not out of date, see pinned comment:
Even though 4.19.7 has been released, several upstream changes therein break ck1. Please do not flag out-of-date until Con releases an update.
graysky commented on 2018-12-05 20:32 (UTC)
Even though 4.19.7 has been released, several upstream changes therein break ck1. Please do not flag out-of-date until Con releases an update.
graysky commented on 2018-12-01 12:25 (UTC)
@FarStar - False alarm... I made a mistake in my config when building. No issues with 4.19.6.
FarStar commented on 2018-12-01 12:08 (UTC)
Hello graysky,
What kind of problems? I have slowdowns at times but I don't know if it's related.
graysky commented on 2018-12-01 12:04 (UTC)
Anyone else experiencing problems relating to networking under 4.19.6?
graysky commented on 2018-11-15 11:09 (UTC)
I need to clear yay's cache after every major kernel update.
Highly discourage users from AUR helpers. 9 times out of 10, problems with builds are the apfsult of the helper.
zerophase commented on 2018-11-15 02:32 (UTC)
@graysky Found the issue. I need to clear yay's cache after every major kernel update.
graysky commented on 2018-11-14 23:41 (UTC)
I don't think this is something with linux-ck but with how you configured/compiled/whatever it. Try the control experiment: build it straight-up and see if it works.
zerophase commented on 2018-11-14 22:57 (UTC)
@graysky I think it might be since I've modified my initramfs to the minimal size.
I could have sworn some of the usb subsystems were added directly to the kernel this release. I just don't want to reboot and find I have an unbootable kernel.
Any idea what to do about modules not being found?
graysky commented on 2018-11-14 22:05 (UTC)
I get no such errors
zerophase commented on 2018-11-14 20:49 (UTC) (edited on 2018-11-14 20:50 (UTC) by zerophase)
When running mkinitcpio, on 4.19.2, I'm getting errors over ehci_pci, xhci_pci, usbhid modules not being found. Have those modules been renamed?
artafinde commented on 2018-11-05 19:51 (UTC)
@graysky: wiki for modprobed-db mention to call the localmodconfig
as below:
make LSMOD=$HOME/.config/modprobed.db localmodconfig
What's the difference of the two methods?
Ranguvar commented on 2018-11-01 14:31 (UTC)
Anyone tried unofficial patch submittied in ck-hack comments? https://jki.io/ck-4.19.patch.bz2
Could be tampered, I haven't tested yet (and not advocating this package use it).
gustawho commented on 2018-10-29 09:13 (UTC)
Here's patch-4-18.ck1.xz
Ranguvar commented on 2018-10-29 00:38 (UTC)
Anyone have a mirror of patch-4.18-ck1.xz?
artafinde commented on 2018-10-28 22:45 (UTC)
Meh, ck.kolivas.org seems down - can't download patch
somethingtohide commented on 2018-10-18 15:56 (UTC)
I'm getting an error while building this, although it's unclear what it is. All the previously logged patching steps are either skipped or success. Here's just the last bit:
patching file sound/soc/soc-dapm.c patching file sound/usb/line6/pcm.c patching file tools/objtool/Makefile ==> ERROR: A failure occurred in prepare(). Aborting...
I simply clone this AUR link, modify PKGBUILD to "_makeenconfig=y" and "_NUMAdisable=", then "makepkg -sri". Changing "_subarch=" has no effect.
I checked that last Makefile that's patched and it's indeed patched. I think the problem is the next line in the PKGBUILD, "local src"
francoism90 commented on 2018-10-09 13:19 (UTC)
@graysky https://bugs.archlinux.org/task/60272 - seems to be a known issue, thanks for looking into it. :)
graysky commented on 2018-10-05 16:25 (UTC)
@ELMastro - Do not build with an AUR helper. Use makepkg.
ElMastro commented on 2018-10-05 02:49 (UTC)
After [code] INSTALL sound/usb/line6/snd-usb-line6.ko INSTALL sound/usb/line6/snd-usb-pod.ko INSTALL sound/usb/line6/snd-usb-podhd.ko INSTALL sound/usb/line6/snd-usb-toneport.ko INSTALL sound/usb/line6/snd-usb-variax.ko INSTALL sound/usb/misc/snd-ua101.ko INSTALL sound/usb/snd-usb-audio.ko INSTALL sound/usb/snd-usbmidi-lib.ko INSTALL sound/usb/usx2y/snd-usb-us122l.ko INSTALL sound/usb/usx2y/snd-usb-usx2y.ko INSTALL virt/lib/irqbypass.ko DEPMOD 4.18.12-1-ck-ck rm: [/code] mine complains it can't remove '/tmp/packerbuild-1001/linux-ck/linux-ck/pkg/linux-ck/usr/lib/modules/4.18.12-1-ck/source' Can someone please confirm I'm the only one with this problem?
graysky commented on 2018-10-04 21:40 (UTC)
@fran - I mirror the Arch official config just allowing CK1 to set the options it wants to. Does your setup work with the official Arch kernel?
francoism90 commented on 2018-10-01 09:16 (UTC) (edited on 2018-10-01 09:17 (UTC) by francoism90)
@graysky Something goes wrong after the latest kernel update. I use something like this cryptkey=/dev/disk/by-uuid/..:ext4:/keys/mykey
as kernel parameter, but it seems the USB is no longer init at boot. When using linux 4.10 it works correctly and the USB contents will be read.
Seems changes have been made in the config (https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-ck&id=b0017a84f42a
) - don't know why this happens, do you have an idea? :)
air-g4p commented on 2018-09-25 09:44 (UTC)
@graysky - Thank you for sending me down the issues/29 path. I learned quite a bit, and now realize this 'problem' is upstream in nature. I'm sure this will not come as a surprise to you, but I'm running gcc version 8.2.1 20180831 (GCC) and the output of: gcc -c -Q -march=native --help=target | grep march
is:
-march= skylake
Now I understand why, which I do appreciate.
graysky commented on 2018-09-23 17:56 (UTC)
@air-g4p - Your question is really for the gcc patchset I maintain. Issue 29 linked below applies but to my knowledge, there hasn't been any gcc changes to support your CPU. If I am wrong, plz post to the issue against the patch: https://github.com/graysky2/kernel_gcc_patch/issues/29
air-g4p commented on 2018-09-23 08:03 (UTC) (edited on 2018-09-23 08:35 (UTC) by air-g4p)
o/ graysky:
I'm running an i7-8550U which Intel describes as belonging to the Kaby Lake R family. This family was launched in Q3 2017.
That family of CPUs lives here: https://ark.intel.com/products/codename/126287/Kaby-Lake-R
Are you planning to add Kaby Lake support within your PKGBUILD or do you suggest I use another one of the other PKGBUILD 'Lakes'?
Thanks
graysky commented on 2018-09-16 13:01 (UTC)
nTia89 commented on 2018-09-16 12:56 (UTC)
oh, thanks... I was missing the change upstream (kernel dev) :-(
graysky commented on 2018-09-16 12:47 (UTC)
This change mirrors that of the upstream Arch kernel and is due to the change of upstream (kernel source) not signing patches any more. You can modify the PKGBUILD to be like the old behavior if you want, but I will maintain as closely as I can how Arch upstream does it.
nTia89 commented on 2018-09-16 12:15 (UTC)
some releases ago, I used to download 4.X tar (90MB) and a patch-4.X.Y tar (~KB), while now I download 4.X.Y tar, for every new kernel sub-version. Is there a way to revert to a patch-system in order to build the kernel? I have an very very slow internet connection but I bet it will be appreciate for metered-connection users.
graysky commented on 2018-09-16 11:54 (UTC)
What?
nTia89 commented on 2018-09-16 11:49 (UTC) (edited on 2018-09-16 11:54 (UTC) by nTia89)
Is there an easy way to get back with the kernel patch system?
francoism90 commented on 2018-09-06 07:56 (UTC)
@graysky Sorry for the noise, the commit has been reverted. :|
sir_lucjan commented on 2018-09-05 10:54 (UTC)
francoism90 commented on 2018-09-05 08:48 (UTC)
@graysky Thanks for the update! :)
graysky commented on 2018-09-03 11:44 (UTC)
@francoism90 - Was waiting for 4.18.6 but I don't even see an rc for it. I will push 4.18.5-4 with these incorporated shortly.
francoism90 commented on 2018-09-03 07:14 (UTC) (edited on 2018-09-03 07:15 (UTC) by francoism90)
@graysky Could you please implement the following changes: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=c75a915313f72924fa0a3ed45356f9e0ea488f3b
Should this also be changed? https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=df01e3111f453e720762a55d68a2e6de2a25f247
Thanks!
vp1981 commented on 2018-08-31 08:29 (UTC)
@keren_sky, did you search for 'apm_bigs' in the kernel source? I did and found nothing, but searching for 'apm_bios' gives many results, for example
$ find -name 'apm_bios*'
./include/linux/apm_bios.h ./include/uapi/linux/apm_bios.h
I would assume that the error has nothing to do with 'apm_bios*' files.
P.S. If somehow your kernel source doesn't have 'apm_bios*' files then something wrong on your side.
keren_sky commented on 2018-08-29 23:00 (UTC)
I see the following: CC [M] drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgv100.o fixdep: error opening file: include/linux/apm_bigs.h: No such file or directory make[4]: *** [scripts/Makefile.build:318: drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgv100.o] Error 2
Which pkg provides that file? thanks.
simona commented on 2018-08-29 15:10 (UTC)
repository http://repo-ck.com/ will be updated soon?
vp1981 commented on 2018-08-29 14:18 (UTC)
@biosin, did you read your log and other comments? Read the log again and these comments: freenestor commented on 2018-08-28 04:17 (edited on 2018-08-28 04:21 by freenestor)
ltsdw commented on 2018-08-28 05:24 (edited on 2018-08-28 05:24 by ltsdw)
skydrome commented on 2018-08-28 09:09 (edited on 2018-08-28 09:09 by skydrome)
P.S. Sorry, no links.
commented on 2018-08-29 09:25 (UTC)
Edit: My fault, somehow the AUR helper didn't delete everything before rebuilding it. 4.18.5-3 does compile.
Somehow, linux-ck 4.18.5-3 and 4.18.5-1 failed building for me at the same seemingly random spot:
LDS arch/x86/kernel/vmlinux.lds
CC [M] arch/x86/kernel/msr.o
CC [M] arch/x86/kernel/cpuid.o
AR arch/x86/kernel/built-in.a
AR arch/x86/built-in.a
==> ERROR: A failure occurred in build().
Aborting...
Full log: https://0bin.net/paste/Y1S1HgocIkxQ8yTW#Ak1q9uDS+t9SSgwppr80Kj3T6rXI51EceXDIdJoNtSQ
tomascco commented on 2018-08-29 00:36 (UTC)
Thanks for your hard work @graysky! I can also confirm that it's building fine.
Lessaj commented on 2018-08-29 00:11 (UTC)
Great! Confirming 4.18.5-3 builds fine for me now, you did the same thing I tried by removing the DEPMOD=/doesnt/exist. :) I was just testing it out and for my particular setup there are some regressions (AMDGPU related, I have 4 monitors, tends to be finicky) so I'll hold off for now and stick with 4.17.11-6. Thank you for the quick support!
graysky commented on 2018-08-28 22:42 (UTC)
@zerophase - I don't think I can automate that since there is are 2 prompts...
graysky commented on 2018-08-28 22:42 (UTC)
4.18.5-3 builds, sorry for the fuck-up.
SilverMight commented on 2018-08-28 22:30 (UTC)
Also received the same issue as @Lessaj
ltsdw commented on 2018-08-28 22:29 (UTC)
I made changes in pkgbuild to apply muqss to another package kernel, and it build successfully here.
zerophase commented on 2018-08-28 21:20 (UTC) (edited on 2018-08-28 21:24 (UTC) by zerophase)
setting _subarch=27
for GCC detecting native cpu features causes the setup script to loop infinitely on Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?]
Would it be possible to allow user input here for whether to turn this feature on or not?
dunconio commented on 2018-08-28 21:02 (UTC) (edited on 2018-08-28 21:29 (UTC) by dunconio)
I can confirm the updated build 4.18.5-2-ck fails as per @Lessaj. (I am using _subarch=19
)
INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
INSTALL virt/lib/irqbypass.ko
DEPMOD 4.18.5-2-ck
'make modules_install' requires /doesnt/exist. Please install it.
This is probably in the kmod package.
make: *** [Makefile:1248: _modinst_post] Error 1
==> ERROR: A failure occurred in package_linux-ck().
Aborting...
==> ERROR: Makepkg was unable to build linux-ck.
graysky commented on 2018-08-28 20:07 (UTC)
I updated with ck's fix in 4.18.5-2 ... please confirm.
Lessaj commented on 2018-08-28 19:19 (UTC) (edited on 2018-08-28 19:27 (UTC) by Lessaj)
Able to complete the build with the patch mentioned by @skydrone, but fails right at the end when installing modules as part of package(). Comparing with previous PKGBUILD this part is unchanged, not sure why I'm experiencing this error now. Confirmed I have the kmod package.
INSTALL sound/xen/snd_xen_front.ko
INSTALL virt/lib/irqbypass.ko
DEPMOD 4.18.5-1-ck
'make modules_install' requires /doesnt/exist. Please install it.
This is probably in the kmod package.
make: *** [Makefile:1248: _modinst_post] Error 1
==> ERROR: A failure occurred in package_linux-ck().
Aborting...
ltsdw commented on 2018-08-28 18:29 (UTC)
@skydrome how can I apply this? Should I edit something in pkgbuild or before/pre pkgbuild?
LChris314 commented on 2018-08-28 12:29 (UTC)
Hello. When I installed my current 4.17.11 kernel, I made some changes to the config with menuconfig
(mostly removed unneeded modules). What is the preferred way to integrate the changes I made into the new version? Do I just load the current config from the menu, or should I modify the PKGBUILD in some way?
skydrome commented on 2018-08-28 09:09 (UTC) (edited on 2018-08-28 09:09 (UTC) by skydrome)
ltsdw commented on 2018-08-28 05:24 (UTC) (edited on 2018-08-28 05:24 (UTC) by ltsdw)
I'm getting this:
kernel/sched/MuQSS.c: In function ‘sched_tick_remote’:
kernel/sched/MuQSS.c:3321:34: error: ‘struct task_struct’ has no member named ‘se’
delta = rq_clock_task(rq) - curr->se.exec_start;
coldreaver commented on 2018-08-28 04:41 (UTC)
4.18.5 is failing yea :(
freenestor commented on 2018-08-28 04:17 (UTC) (edited on 2018-08-28 04:21 (UTC) by freenestor)
I failed buid it on my computer with linux-4.17-ck installed
CC kernel/rcu/rcu_segcblist.o
AR kernel/rcu/built-in.a
CC kernel/sched/MuQSS.o
kernel/sched/MuQSS.c: In function ‘sched_tick_remote’:
kernel/sched/MuQSS.c:3321:34: error: ‘struct task_struct’ has no member named ‘se’
delta = rq_clock_task(rq) - curr->se.exec_start; ^~
make[2]: *** [scripts/Makefile.build:318: kernel/sched/MuQSS.o] Error 1
make[1]: *** [scripts/Makefile.build:558: kernel/sched] Error 2
make: *** [Makefile:1033: kernel] Error 2
==> ERROR: A failure occurred in build(). Aborting...
zerophase commented on 2018-08-28 01:46 (UTC)
Is the 4.18.5 failing to build for anyone else?
francoism90 commented on 2018-08-27 13:22 (UTC)
@graysky https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=c75a915313f72924fa0a3ed45356f9e0ea488f3b - could you also enable this in linux-ck? :)
harryharryharry commented on 2018-08-27 10:06 (UTC)
Just a heads up, a 4.18 ck-patchset has just been released: http://ck.kolivas.org/patches/4.0/4.18/4.18-ck1/
sir_lucjan commented on 2018-08-18 15:46 (UTC)
simona commented on 2018-08-18 08:53 (UTC)
I hope 4.18.2 will arrive soon...
graysky commented on 2018-08-17 22:54 (UTC)
@Jeffrey4l - I don't see why not. Did you create a ticket for the Arch kernel to do the same? @francoism90 - No idea, email ck.
francoism90 commented on 2018-08-17 20:02 (UTC)
@graysky Does this mean no patch for 4.18 yet?
Jeffrey4l commented on 2018-08-16 04:36 (UTC)
Could you enable
CONFIG_CGROUP_CPUACCT=y
in config in default?
This is need for docker stats and systemd-cgtop
sir_lucjan commented on 2018-08-14 20:47 (UTC)
simona commented on 2018-08-14 20:40 (UTC)
4.17.11-6 ? what change?
keepitsimpleengr commented on 2018-08-13 16:17 (UTC)
:: installing nvidia-utils (396.51-1) breaks dependency 'nvidia-utils=396.45' required by nvidia-ck-sandybridge
simona commented on 2018-08-11 17:53 (UTC)
ok :-))) thx.
graysky commented on 2018-08-11 10:11 (UTC)
@simona - See the pinned post from Aug 4th.
simona commented on 2018-08-11 08:13 (UTC)
stopped to 4.17.11?
gee commented on 2018-08-11 03:35 (UTC)
Oh it's pkgbase, got it!
Yeah I'm running it, but the changes were made in bluetooth that I have not tested much, and schedutils that I don't use. If you look at the patch you'll see it is just a 3-way manual diff, nothing fancy.
graysky commented on 2018-08-10 18:56 (UTC)
@gee - Thanks, any feedback (assuming you're running that patched code)? I passed CK your proposal for review. To your question, just rename the pkgbase from linux-ck to linux-whatever-you-want
sispus commented on 2018-08-10 10:28 (UTC) (edited on 2018-08-10 11:03 (UTC) by sispus)
@ sir_lucjan
thank you, but I think I don't understand what to do. I did:
sudo pacman-key --recv-key 38DBBDC86092693E
it replied:
gpg: bad data signature from key 8396F1D05506E82D: Wrong key usage (0x19, 0x2)
gpg: bad data signature from key 20E8A9C77716EB4F: Wrong key usage (0x19, 0x2)
I did also that without realizing "wrong key usage" warning:
sudo pacman-key --lsign-key 38DBBDC86092693E
Now when I repeat above command (--recv-key) it says: Remote key not fetched correctly from keyserver.
I don't know if these info is helpful. If not, I'm sorry...
edit: I found this from a forum and solved: gpg --recv-keys 38DBBDC86092693E
sir_lucjan commented on 2018-08-10 09:53 (UTC)
sispus commented on 2018-08-10 09:49 (UTC)
I couldn't install it to manjaro xfce. linux-4.17.11.tar ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified!
gee commented on 2018-08-10 08:29 (UTC) (edited on 2018-08-10 09:27 (UTC) by gee)
@graysky, I've patched ck's patch to build with .14, it was fairly easy, hopefully I made no mistake: https://pastebin.com/WDVt52ZB
Unrelated, but how do I easily get this package to be named similarly to the one I'd get from your repo, in my case -haswell?
melcor333 commented on 2018-08-09 23:20 (UTC) (edited on 2018-08-09 23:28 (UTC) by melcor333)
@graysky - I'll try thanks
EDIT: Perfect! Working as intended. Thanks a lot! :)
melcor333 commented on 2018-08-09 23:18 (UTC)
Hi, since last 2 updates I'm unable to boot to GUI, because of nvidia isn't found in kernel modules. I get this error during install:
==> ERROR: module not found: nvidia'
==> ERROR: module not found:
nvidia_modeset'
==> ERROR: module not found: nvidia_uvm'
==> ERROR: module not found:
nvidia_drm'
I have nvidia-ck and linux-ck-headers installed. Is there anything I'm doing wrong?
GPU is Nvidia GTX960. Before this everything worked flawlessly.
Thanks
graysky commented on 2018-08-09 21:16 (UTC)
@melcor333 - broadcom and nvidia-* have been updated. Please try and reported back. broadcom and nvidia-340xx work for me on my test box.
graysky commented on 2018-08-09 21:06 (UTC)
Yes, the naming schema has changed. I will push some updates shortly.
graysky commented on 2018-08-09 19:29 (UTC)
All - I think I have all the kinks ironed out of the new PKGBUILD structure. We are still unfortunately in the position of ck1 not patching into 4.17.12-current so we seem stuck on 4.17.11. Good news is that 4.18.0 should be released this weekend and CK is likely to work on that rather than doing so to an EOL kernel (4.17.x series).
I just pushed 4.17.11-4 with a few minor tweaks. Builds and runs fine for me. Please d/l and test.
@Saren - Fixed the NUMA issue in -4. Please try.
Saren commented on 2018-08-07 17:42 (UTC)
Hi, my system needs NUMA support, and changing _NUMAdisable=y
to _NUMAdisable=
still disables NUMA support on 4.17.11-3
. I have already compiled the kernel twice and I am sure I have changed that line. It was totally fine before the major PKGBUILD format change.
artafinde commented on 2018-08-07 11:29 (UTC)
Yeah if only they provide a checksum and/or signed packages :)
graysky commented on 2018-08-07 11:03 (UTC)
QuartzDragon commented on 2018-08-07 09:47 (UTC)
artafinde,
That sounds better than my suggestion. :)
artafinde commented on 2018-08-07 08:53 (UTC) (edited on 2018-08-07 09:00 (UTC) by artafinde)
Following the new way for the linux package fetches the whole linux repo (bare) with cloning which downloads 2Gb just to checkout HEAD of it (~150Mb). The ideal would beto download from release i.e. https://github.com/archlinux/linux/archive/v4.17.13-arch1.tar.gz
QuartzDragon commented on 2018-08-07 07:42 (UTC) (edited on 2018-08-07 07:43 (UTC) by QuartzDragon)
Hey graysky,
Is there any reason you're not using https://github.com/archlinux/linux/tree/v4.17.11-arch1? It contains all of the relevant Arch-specific changes:
zerophase commented on 2018-08-06 16:09 (UTC) (edited on 2018-08-06 16:11 (UTC) by zerophase)
@graysky should the kernel be installing modules as ck-ck now?
graysky commented on 2018-08-05 19:17 (UTC)
@id942701 - Opps, debug helper. Removed no in 4.17.11-3.
id942701 commented on 2018-08-05 18:18 (UTC)
PKGBUILD problem: exit in prepare(). Build successful.
graysky commented on 2018-08-05 16:02 (UTC) (edited on 2018-08-05 16:02 (UTC) by graysky)
I changed my mind... I just commited 4.17.11-2 which just changes to the PKGBUILD to mirror that of Arch upstream. Builds for me. Can some others please test and report back? CK has been contacted about ck1 not patching in to 4.17.12.
graysky commented on 2018-08-05 11:32 (UTC)
@QuartzDragon - I have already merged it too but am don't see much value in using 4.17.11-2 with just the PKGBUILD changes... as I posted on 08-04, ck1 does not patch against 4.17.12.
QuartzDragon commented on 2018-08-05 09:44 (UTC) (edited on 2018-08-05 09:49 (UTC) by QuartzDragon)
Hey, graysky,
You may want to check out https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux because the kernel PKGBUILD has changed significantly.
I've already merged in the changes locally, and it builds fine.
graysky commented on 2018-08-04 11:26 (UTC) (edited on 2018-08-11 10:11 (UTC) by graysky)
I am unable to patch into 4.17.12+ due to changes upstream... need to fix before updating the PKGBUILD:
Hunk #1 FAILED at 185.
Hunk #2 succeeded at 473 (offset -1 lines).
1 out of 2 hunks FAILED -- saving rejects to file
kernel/sched/cpufreq_schedutil.c.rej
id942701 commented on 2018-08-04 08:47 (UTC)
Small typo "Note that the generic (default) option is 24" but "26. Generic-x86-64 (GENERIC_CPU)"
Tjuh commented on 2018-08-01 17:58 (UTC)
I'm trying to build 4.14.20 because I have not been able to build a functional version since 4.16.15. Well 4.16 builds fine but it just hangs at boot same with 4.17-ck and vanilla. Only working kernel I got now is latest linux-lts.
graysky commented on 2018-08-01 17:48 (UTC)
You're building 4.16?
Tjuh commented on 2018-08-01 17:05 (UTC)
I am unable to build any version prior to 4.16 due to the following error message:
pager.c: In function ‘pager_preexec’: pager.c:36:12: error: passing argument 2 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict] select(1, &in, NULL, &in, NULL); ^~~ ~~~ cc1: all warnings being treated as errors mv: cannot stat '/tmp/makepkg/linux-ck/src/linux-4.14/tools/objtool/.pager.o.tmp': No such file or directory make[4]: [/tmp/makepkg/linux-ck/src/linux-4.14/tools/build/Makefile.build:97: /tmp/makepkg/linux-ck/src/linux-4.14/tools/objtool/pager.o] Error 1 make[3]: [Makefile:52: /tmp/makepkg/linux-ck/src/linux-4.14/tools/objtool/libsubcmd-in.o] Error 2 make[2]: [Makefile:54: /tmp/makepkg/linux-ck/src/linux-4.14/tools/objtool/libsubcmd.a] Error 2 make[1]: [Makefile:62: objtool] Error 2 make: *** [Makefile:1637: tools/objtool] Error 2 ==> ERROR: A failure occurred in prepare(). Aborting...
Anyone know what this is about?
artafinde commented on 2018-08-01 15:47 (UTC)
I'm the same person with the one on the forums :)
SilverMight commented on 2018-08-01 15:43 (UTC)
@artafinde Yup, just saw that in the thread. Thanks
artafinde commented on 2018-08-01 06:48 (UTC)
@SilverMight: Enable NUMA, recompile and CUDA now works.
SilverMight commented on 2018-07-31 21:44 (UTC)
Have a few people with the same issue in the thread: https://bbs.archlinux.org/viewtopic.php?id=239174
graysky commented on 2018-07-29 21:49 (UTC)
No idea about CUDA/don't have the hardware. You might try CK's blog or someone might reply to what I think is your bbs thread.
SilverMight commented on 2018-07-29 21:39 (UTC)
Now it works, thanks. Do you know if there's an issue with CUDA? Doesn't seem to initialize on this kernel, but every other kernel works fine for me
graysky commented on 2018-07-29 21:04 (UTC)
Did you pacman -Syyu
? Fine for me % pacman -Ss core2-h
repo-ck/linux-ck-core2-headers 4.17.11-1 (ck-core2)
Header files and scripts for building modules for Linux-ck-core2 kernel Intel Core2/Newer Xeon optimized.
SilverMight commented on 2018-07-29 19:19 (UTC) (edited on 2018-07-29 20:10 (UTC) by SilverMight)
Some reason my pacman is trying to fetch 4.10-1 instead of 4.11 from repo-ck, even though I have refreshed the lists.. anyone experiencing this?
Also - is anyone else having an issue with CUDA with this kernel?
sir_lucjan commented on 2018-07-11 23:01 (UTC)
@ graysky
No.
graysky commented on 2018-07-11 20:35 (UTC)
Can anyone else confirm that 4.17.6 causes errors relating to mounting disks.
bezirg commented on 2018-06-28 08:50 (UTC)
Proposed change in PKGBUILD:
Note that the
# generic (default) option is 24.
to ====>
Note that the
# generic (default) option is 26.
bezirg commented on 2018-06-28 08:45 (UTC)
On linux-ck 4.17.3-1 makepkg error:
==> Verifying source file signatures with gpg...
linux-4.17.tar ... FAILED (unknown public key 79BE3E4300411886)
patch-4.17.3 ... FAILED (unknown public key 38DBBDC86092693E)
==> ERROR: One or more PGP signatures could not be verified!
graysky commented on 2018-06-25 13:14 (UTC)
I asked for a timeline for 4.17-ck1. I will update the [repo-ck] thread when I hear back. Doesn't make too much sense to go though heroic measures to troubleshoot if 4.17-ck1 is just around the corner. I believe 4.16.x will be EOL'ed shortly as well.
CK expects 4.17-ck1 in a few days so it's not worth trying to unfuck 4.16-ck1 to fit into 4.16.17 or 4.16.18 IMO.
graysky commented on 2018-06-24 21:07 (UTC)
Yea, it's confirmed that 4.16.17-1 doesn't play well with ck's patchset. I asked for a timeline for 4.17-ck1. I will update the [repo-ck] thread when I hear back. Doesn't make too much sense to go though heroic measures to troubleshoot if 4.17-ck1 is just around the corner. I believe 4.16.x will be EOL'ed shortly as well.
Tjuh commented on 2018-06-24 18:36 (UTC)
Same problem as the others, just a black screen during boot, ditto with the pre built pkg from the repo ck.
nTia89 commented on 2018-06-24 10:24 (UTC)
me too. 4.16.17-2 stucks just after boot selection. I am on broadwell, compiled with native and P6_NOP. Downgraded
graysky commented on 2018-06-23 05:37 (UTC)
@zero - Yes, I am having this problem as well.
zerophase commented on 2018-06-22 23:45 (UTC) (edited on 2018-06-22 23:54 (UTC) by zerophase)
Anyone else getting stuck after the boot loader with the last update? Don't believe I have any logs since the system stalls early in boot.
graysky commented on 2018-06-22 19:18 (UTC)
@Saren - Thanks... I ran the test in another terminal but never checked the result. Fixed now.
Saren commented on 2018-06-22 19:05 (UTC)
Fail at prepare() for 4.16.17-1
patching file drivers/acpi/acpi_watchdog.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/acpi/acpi_watchdog.c.rej
graysky commented on 2018-05-24 22:06 (UTC)
@banzay - I like to mirror the official Arch kernel patch-wise @Morgan - I believe that was needed for some reason ... can't remember why but it's harmless as-is.
banzay commented on 2018-05-24 21:22 (UTC)
https://bugzilla.kernel.org/show_bug.cgi?id=198167 these patches will not be included?
Morganamilo commented on 2018-05-22 04:32 (UTC)
Is there a reason for the linux-ck=4.16.10
provide? All packages automatically provide their own name.
zebulon commented on 2018-05-02 06:24 (UTC)
@graysky: thanks. Do you mean 4.16.6-2? There is no -3 in the repository.
graysky commented on 2018-05-01 23:31 (UTC)
@sir_l - CK1 includes the nvidia patch (0003) and I bumped linux-rc to 4.16.7 which includes 0004 so I accidentally omitted it.... fixing in 4.16.6-3, thanks.
sir_lucjan commented on 2018-05-01 21:03 (UTC) (edited on 2018-05-01 21:04 (UTC) by sir_lucjan)
@graysky
Probably you forgot about other patches:
graysky commented on 2018-05-01 20:56 (UTC)
@sir_lucjan - Yes, I thought I diffed that out >:( ... fixed now but since I have been building the repo packages, I don't want to bump the pkgver and start all over.
@zebulon - Thanks for reporting. Please try now.
sir_lucjan commented on 2018-05-01 20:51 (UTC) (edited on 2018-05-01 20:52 (UTC) by sir_lucjan)
@graysky
You should remove
# http://bugs.archlinux.org/task/9912
install -Dt "${_builddir}/drivers/media/dvb-core" -m644 drivers/media/dvb-core/*.h
from headers()
@zebulon
UP
zebulon commented on 2018-05-01 20:47 (UTC) (edited on 2018-05-01 20:48 (UTC) by zebulon)
Hi, packaging fails with this error:
==> Starting package_linux-ck-headers()...
install: cannot stat 'drivers/media/dvb-core/*.h': No such file or directory
==> ERROR: A failure occurred in package_linux-ck-headers().
Aborting...
Or am I doing something wrong? The only option I used is Skylake optimisations, but I do not think this is relevant.
sir_lucjan commented on 2018-04-11 14:47 (UTC)
@simona
You should ask Con.
simona commented on 2018-04-10 08:13 (UTC)
4.16? soon?
Dennis commented on 2018-03-24 07:14 (UTC)
Today receiving the key just worked and the packages updated as well without issues. Must have been a network issue elsewhere.
@vp1981: The missing sudo on the second command was just an oversight on my part when I prepared a cleaned up, condensed message for posting here. In reality I ran all commands in a root shell and only added sudo in front for the log here to make it clear that I was running those commands as root.
vp1981 commented on 2018-03-23 23:55 (UTC)
@graysky
I already installed that packages using 'pacman -U'. I had to say that these are the only packages that not upgraded smoothly, on other two platforms (haswell and sandybridge) all was fine. At first I suspected that it is the 'archlinux-keyring' that cause the problem, I tried to update all other packages but without '-ck-skylake*' and only after that tried to update these two packages using usual 'pacman -Su' but 'pacman' reported something about either broken package or a key, I couldn't remember the details, sorry.
@Dennis
I tried to reinstall the key and went fine (actually pacman-key returned that the key is already installed). Besides, according to the your message the problem with 'gpg': it cannot retrieve the key. You may try again but I'm not sure what causes the failure (may be network problem or gpg misconfiguration, you may want to [re]read https://wiki.archlinux.org/index.php/Pacman/Package_signing). Also I noticed that you issue command like
sudo pacman-key ... && pacman-key ...
without 'sudo' before the second pacman-key. Try to append 'sudo' to both 'pacman-key'.
P.S. I usually do that everyday:
(reflector stuff) && pacman -Scc && pacman -Syy && pacman -Su && pacman -Scc
Dennis commented on 2018-03-23 19:22 (UTC) (edited on 2018-03-23 19:22 (UTC) by Dennis)
I'm also having problems updated linux-ck-skylake from repo-ck:
$ sudo pacman -Syyu
:: Starting full system upgrade... resolving dependencies... looking for conflicting packages...
Packages (2) linux-ck-skylake-4.15.12-1 linux-ck-skylake-headers-4.15.12-1
Total Installed Size: 152.68 MiB Net Upgrade Size: 0.05 MiB
:: Proceed with installation? [Y/n] Y (2/2) checking keys in keyring [#######################################################################################] 100% downloading required keys... error: key "88A032865EE46C4C" could not be looked up remotely error: required key missing from keyring error: failed to commit transaction (unexpected error) Errors occurred, no packages were upgraded.
$ sudo pacman-key -r 5EE46C4C && pacman-key --lsign-key 5EE46C4C gpg: keyserver receive failed: Address family not supported by protocol ==> ERROR: Remote key not fetched correctly from keyserver.
Also tried updating archlinux-keyring alone first and reinitialized and repopulated the keyring but I am still getting above errors.
graysky commented on 2018-03-23 18:54 (UTC)
@vp1981 and @Silvermight - Please pacman -Syyu
and it should work.
vp1981 commented on 2018-03-23 14:35 (UTC)
@SilverMight: same here, I checked downloaded files (-ck-skylake and -ck-skylake-headers) and they are correct and 'pacman -U' installs them fine.
SilverMight commented on 2018-03-23 10:37 (UTC)
Getting error: linux-ck-skylake: missing required signature when trying to update from repo-ck.com... I have the pacman key added and I tried it again, however it still fails to update
sir_lucjan commented on 2018-03-22 10:30 (UTC)
shanti commented on 2018-03-22 09:12 (UTC)
@sir_lucjan
thanks I added the lines you provided however I am still unable to apply the bfq-sq-mq patch successfully,
Makefile.rej gives:
[code]--- Makefile +++ Makefile @@ -2,7 +2,7 @@ VERSION = 4 PATCHLEVEL = 15 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION = NAME = Fearless Coyote
DOCUMENTATION --- Makefile +++ Makefile @@ -2,7 +2,7 @@ VERSION = 4 PATCHLEVEL = 15 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION =-mq NAME = Fearless Coyote
DOCUMENTATION[/code]
shanti commented on 2018-03-22 09:07 (UTC)
@sir_lucjan
thanks I added the lines you provided however I am still unable to apply the bfq-sq-mq patch successfully,
Makefile.rej gives:
[--- Makefile +++ Makefile @@ -2,7 +2,7 @@ VERSION = 4 PATCHLEVEL = 15 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION = NAME = Fearless Coyote
# DOCUMENTATION --- Makefile +++ Makefile @@ -2,7 +2,7 @@ VERSION = 4 PATCHLEVEL = 15 SUBLEVEL = 11 -EXTRAVERSION = +EXTRAVERSION =-mq NAME = Fearless Coyote
# DOCUMENTATION]
vp1981 commented on 2018-03-22 01:16 (UTC) (edited on 2018-03-22 01:17 (UTC) by vp1981)
@Terence:
you do not have the option to enable bfq-mq anymore
you mean the kernel cmdline option?
it should appear as bfq-mq in the list of schedulers
I have felling that that's wrong (may be because now BFQ in mainline). Some time ago I tried to follow closely BFQ development and had impression that new 'BFQ-MQ' is now 'BFQ' in mainline. This line
mq-deadline kyber [bfq] none
tells me that bfq in my case is BFQ-MQ (because all these schedulers are MQ).
sir_lucjan commented on 2018-03-21 17:23 (UTC)
@Terence
Nope, I have my own kernel with bfq patchset.
Terence commented on 2018-03-21 17:20 (UTC)
@sir_lucjan yes, you have bfq-mq and bfq I was just saying vp1981 only had bfq. I see you have bfq-mq. Is this from latest linux-ck? Did you have to do somethign to enable it?
sir_lucjan commented on 2018-03-21 16:05 (UTC)
@Terence:
bfq != bfq-mq
[lucjan@archlinux ~]$ cat /sys/block/sda/queue/scheduler
bfq [bfq-mq] none
Terence commented on 2018-03-21 16:00 (UTC)
@vp1981, I think so because you do not have the option to enable bfq-mq anymore and it should appear as bfq-mq in the list of schedulers.
vp1981 commented on 2018-03-21 14:23 (UTC) (edited on 2018-03-21 14:24 (UTC) by vp1981)
$ uname -a
Linux smoon.vl-lomov.ru 4.15.11-1-ck-haswell #1 SMP PREEMPT Tue Mar 20 11:27:59 EDT 2018 x86_64 GNU/Linux
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-linux-ck-haswell root=UUID=162d2744-158f-46b5-b3e8-fdc25739c96a rw systemd.unified_cgroup_hierarchy=1 scsi_mod.use_blk_mq=1 quiet
$ cat /sys/block/sd*/queue/scheduler
mq-deadline kyber [bfq] none mq-deadline kyber [bfq] none mq-deadline kyber [bfq] none mq-deadline kyber [bfq] none mq-deadline kyber [bfq] none
@Terence, is that mean that I don't have BFQ-MQ?
Terence commented on 2018-03-21 13:13 (UTC)
bfq-mq is also missing.
francoism90 commented on 2018-03-21 11:12 (UTC)
Why I'm I only seeing the following options: $ cat /sys/block/sd*/queue/scheduler noop deadline [cfq]
$ uname -a Linux 4.15.11-1-ck-skylake #1 SMP PREEMPT Tue Mar 20 11:44:14 EDT 2018 x86_64 GNU/Linux
Thanks
Morganamilo commented on 2018-03-21 00:53 (UTC)
@LinX as one of the devs for it I'm glad it does ;)
Kerriganx commented on 2018-03-21 00:51 (UTC)
@Morganamilo thanks, yay works.
Morganamilo commented on 2018-03-21 00:31 (UTC)
@LinX works with me using yay. AUR helpers are not officially supported though. your best bet is makepkg
.
Kerriganx commented on 2018-03-21 00:27 (UTC) (edited on 2018-03-21 00:30 (UTC) by Kerriganx)
I tried pacaur instead of yaourt but it freezes at:
==> Validating source files with sha256sums... linux-4.15.tar.xz ... Passed linux-4.15.tar.sign ... Skipped patch-4.15.11.xz ... Passed patch-4.15.11.sign ... Skipped config ... Passed 60-linux.hook ... Passed 90-linux.hook ... Passed linux.preset ... Passed enable_additional_cpu_optimizations-20180310.tar.gz ... Passed patch-4.15-ck1.xz ... Passed 0001-add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by.patch ... Passed 0002-drm-i915-edp-Only-use-the-alternate-fixed-mode-if-it.patch ... Passed ==> Verifying source file signatures with gpg... linux-4.15.tar ... Passed patch-4.15.11 ... Passed
Kerriganx commented on 2018-03-20 23:35 (UTC) (edited on 2018-03-20 23:36 (UTC) by Kerriganx)
@Morganamilo I run through yaourt -Syua. Month ago there was no such problem
Morganamilo commented on 2018-03-20 23:13 (UTC)
@LinX It wants user input, are you running makepkg through a script that doesn't pass on stdin or something?
Kerriganx commented on 2018-03-20 23:05 (UTC)
I'm stuck on "Support for P6_NOPs". This line appears endlessly: https://i.imgur.com/N8FzBst.gif
sir_lucjan commented on 2018-03-20 15:38 (UTC)
@shanti:
### Patch source with BFQ-SQ-MQ
msg "Fix naming schema in BFQ-SQ-MQ patch"
sed -i -e "s|SUBLEVEL = 0|SUBLEVEL = 11|g" \
-i -e "s|EXTRAVERSION = -bfq|EXTRAVERSION =|g" \
-i -e "s|EXTRAVERSION =-mq|EXTRAVERSION =|g" ../${_bfq_sq_mq_patch}
msg "Patching source with BFQ-SQ-MQ patches"
patch -Np1 -i ../${_bfq_sq_mq_patch}
Works fine.
shanti commented on 2018-03-20 15:34 (UTC)
@sir_lucjan
Thank you very much, unfortunately despite my trials, the patch fails to apply. I reverted to 4.14.12-2-ck which seem to be the last linux-ck including bfq-sq scheduler.
So to my understanding, bfq-sq has been removed from ck patchset itself but I couldn't find relevant information on Paolo Valente's website.
Can somebody elaborate why? or have any information whether it may come back or not.
RaskAr commented on 2018-03-16 10:47 (UTC)
@CarterCox See https://bbs.archlinux.org/viewtopic.php?pid=1488777#p1488777
CarterCox commented on 2018-03-16 03:02 (UTC)
==> ERROR: One or more PGP signatures could not be verified!
This is what I'm getting. Anyone knows how to solve it?
sir_lucjan commented on 2018-03-13 14:07 (UTC)
@shanti
You can add bfq-sq/bfq-mq patchset:
Download:
https://github.com/sirlucjan/kernel-patches/blob/master/4.15/4.15-bfq-sq-mq-git-20180227.patch
shanti commented on 2018-03-13 13:55 (UTC)
As mentioned by someone earlier, bfq-sq scheduler is gone in recent releases. Can someone please explain why such an important feature of this kernel is being omitted or dropped? Thanks
j1simon commented on 2018-03-11 13:31 (UTC)
I see several warnings in my log "NOHZ: local_softirq_pending xxx" 4.15.8-1-ck-skylake
QuartzDragon commented on 2018-03-08 07:42 (UTC)
The problem is referenced here: https://bugs.archlinux.org/task/57741
Problem should be fixed in systemd 238.0-2.
jambuu commented on 2018-03-07 11:22 (UTC)
The system is crashing in the latest version wrt systemd and glibc, I am having the same issue as @QuartzDragon
QuartzDragon commented on 2018-03-06 23:07 (UTC)
Anyone else get a systemd PID1-related coredump after the 238 systemd update currently in testing?
It's weird that only the stock Arch kernel worked, while systemd wasn't happy with linux-ck...
RaskAr commented on 2018-03-01 23:11 (UTC) (edited on 2018-03-01 23:28 (UTC) by RaskAr)
Yep, removing this file from the cache and fetching again, worked.
For reference and as a follow up on the touchPad + trackPoint of my pc not being fully enabled by this config, enabling _makenconfig=y
option in the PKGBUILD permitted adding this two modules to the build:
Device Drivers -> input device support -> (M) RMI4 SMB Support
Device Drivers -> HID support -> Special HID drivers -> (M) Synaptics RMI4 device support
After a reboot everything was working as before, TITS (that is to say :D) the trackPoint was hardly moving in one direction only.
But adding psmouse.synaptics_intertouch=1
as a boot parameter (advertised in boot log) made the two freshly built modules to be loaded at boot, allowing the trackPoint to be usable without shortcomings !
As a proof, using xinput on X11 the touchPad is recognized in a different way : "SynPS/2 Synaptics TouchPad" now is "Synaptics TM2758-001". In Wayland the name is different but both devices work well too.
Terence commented on 2018-03-01 20:23 (UTC)
@RaskAr Remove the one you have and fetch it again.
graysky commented on 2018-03-01 20:12 (UTC)
Hello graysky, linux-ck 4.15.7-1 fails to build here : enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch ... ÉCHEC
@RaskAr - Not sure what that means... builds fine for me.
RaskAr commented on 2018-03-01 20:01 (UTC)
Hello graysky,
linux-ck 4.15.7-1 fails to build here :
enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch ... ÉCHEC
microsoftenator commented on 2018-02-27 06:38 (UTC) (edited on 2018-02-27 06:38 (UTC) by microsoftenator)
I'm getting this output in my dmesg whenever a VM is running:
BUG: using smp_processor_id() in preemptible [00000000] code: CPU 0/KVM/690
BUG: using smp_processor_id() in preemptible [00000000] code: CPU 1/KVM/691
It seems to be related to CONFIG_PREEMPT, since changing to CONFIG_PREEMPT_NONE=y or CONFIG_PREEMPT_VOLUNTARY=y eliminates the message.
This does not occur on the regular Arch kernel
graysky commented on 2018-02-23 20:41 (UTC)
@RaskAr - I use the ARCH .config as the base for linux-ck making only the changes the ck patchset requires. If this is something shipped with the kernel but silent in the config itself, you can enable it and build with it. If this is an out-of-tree addition, you are free to patch the source and build it.
RaskAr commented on 2018-02-23 19:46 (UTC)
Hello graysky, the config seems to be missing a builtin config for laptop users :
From log : « kernel: psmouse serio3: synaptics: The touchpad can support a better bus than the too old PS/2 protocol. Make sure MOUSE_PS2_SYNAPTICS_SMBUS and RMI4_SMB are enabled to get a better touchpad experience. »
After checking the config it only misses RMI4, which is the successor of the PS2 PROTOCOL, see http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01731.html Would be great to have it enabled !
presianbg commented on 2018-02-19 05:03 (UTC) (edited on 2018-02-20 16:54 (UTC) by presianbg)
bfq-sq is gone again.
-CONFIG_BFQ_SQ_GROUP_IOSCHED=y
PS: Putting "scsi_mod.use_blk_mq=1 " in kernel options is enabling the BFQ MQ scheduler. The selecting it with TLP, works just fine.
PS2: elevator option in the kernel parameters is not recognized.
graysky commented on 2018-02-18 20:35 (UTC)
which processor family should i chose for apollo lake (goldmont) processor Celeron N3450?
Did you try: https://wiki.archlinux.org/index.php/Unofficial_user_repositories/Repo-ck#Selecting_the_correct_CPU_optimized_package
garwol commented on 2018-02-17 17:34 (UTC)
which processor family should i chose for apollo lake (goldmont) processor Celeron N3450?
Terence commented on 2018-02-17 16:50 (UTC)
@nTia89 It had to be from my side, it's working fine now with 4.14.20.
nTia89 commented on 2018-02-15 22:02 (UTC)
no problem here with .19 and DKMS
Terence commented on 2018-02-13 20:34 (UTC)
Something with 4.14.19 is making DKMS not working for any driver.
kata198 commented on 2018-02-08 05:03 (UTC)
@QuartzDragon - I applied the 4.14 patch with -F5 (fuzz-level 5, dangerous; requires manual review of every patch but "shoves" things in when at all possible. It even managed to shove some code right into the middle of a comment!), fixed the rejections, added one or two new compat functions as required due to API/ABI changes between .14 and .15, did some basic research into where things moved around and such and applied those changes.
I've done some kernel work in the past, so I like to think I'm somewhat familiar with the layout of things. It shouldn't take too long for you to pick up where things are, thanks to you're friendly General Regular Expression Parser (grep) .
Basically, checked the diff between 4.14 and 4.15 on the core scheduler to see any abi/api changes, and others as they arose ( I remember there being a change in some of the "compat" files which required updates/additions/rewrites beyond what the original patch provided, there may have been others ).
Then just built, and fixed any issues that arise during compile (these can be due to changing where #ifdef wrappers are in the baseline, where the patch may force things into the wrong section, or a linker issue from a missing function, etc.)
I'd say just dive right in! Try to merge 4.14 to 4.15 yourself, basically make it till you break it, or succeed! Probably a good idea to use a virtualbox image for testing rather than your primary system, or what I do on this laptop I am using to type to you right now, which is running arch in a virtualbox on top of windows 10 (work / warrenty reasons) is this: I take a snapshot prior to development, so any damage that gets done I can just roll back and alls good.
Hope this helps, I'm not too sure on what you are looking for specifically, so I tried to keep it general!
I would say just dig in! Try you m
kata198 commented on 2018-02-08 04:46 (UTC)
I mentioned specifically that I didn't know if they were true or not -- I just found a couple articles when searching to see if anyone else had ported it as it was time for me to build a new kernel. I mean no disrespect nor harm toward anybody. @beojan is probably right -- they may have been dated 2007 which I mistook for 2017.
If you've spoken with him and he says he's not -- all the better. But please don't try to make me out to be some sort of demon spreading nonsense -- I specifically said "I don't know if these reports are legitimate or not."
You're free to enjoy the early merge and update I did, or you're free to wait for him to release an official version. I'm still running strong without any issues on my merge, so it seems pretty stable to me.
Again, I apoligize if I've upset anybody, this was not my intent at all.
beojan commented on 2018-02-06 11:48 (UTC)
@kata198 I wonder if the "rumours" you're hearing are really old news from when he stopped maintaining the old ck patchset in 2007.
graysky commented on 2018-02-04 11:20 (UTC)
@kata198- While I applause your efforts to help port the ck patchset, announcing uncited and unconfirmed rumors as pretext is not cool.
CK himself replied to me in a private email:
Yeah bullshit. It'll probably be a week or so though.
Cheers,
Con
On 4 February 2018 at 22:06, John <graysky AT archlinux DOT us> wrote:
> https://wiki.archlinux.org/index.php?title=Talk:Linux-ck&diff=next&oldid=483793
>
> Specifically: "Hey guys, so I've read some rumors that Con Kolivas is taking
> a break / no longer maintaining the ck patchset; that 4.14 was the last
> version for a while. "
QuartzDragon commented on 2018-02-04 04:35 (UTC) (edited on 2018-02-04 04:36 (UTC) by QuartzDragon)
@kata198
Where did you hear about these rumours? I'm curious as to why he'd stop maintaining the patchset without notifying everyone, and passing the reins onto someone capable.
Also, out of curiousity, how did you rebase the patches? I'm curious about learning how to do rebasing, myself.
kata198 commented on 2018-02-04 02:23 (UTC) (edited on 2018-02-04 02:29 (UTC) by kata198)
Linux-4.15 (Unofficial)
Hey guys, I've heard rumros that Con Kolivas may no longer be maintaining the ck patchset? I don't know if these reports are legitimate or not, but just in case they are, I went ahead and manually updated the ck patchset to cleanly apply with 4.15. It's been a little bit of time since I've done any sort of active kernel development, but I believe everything is correct here, and I've been running this ported patchset (ported patch-4.14-ck1.xz to work with linux-4.15) for almost 2 full days now without even the slightestnd ev indication of issue, I'm running on an intel i7 in SMP/SMT mode, through virtualbox as my primary laptop/desktop.
I'm posting to share my unofficial merge of the patchset, in the hopes that it may be of benefit to others.
You can find the patch and even a drop-in replacement of the PKGBUILD on stock arch-4.15 package, HERE:
https://github.com/kata198/con-ck-patches
Enjoy!
Plexcon commented on 2018-02-02 20:56 (UTC)
drivers/gpu/drm/amd/amdgpu/.tmp_uvd_v7_0.o: warning: objtool: uvd_v7_0_ring_emit_fence()+0x45a: return with modified stack frame CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_vce.o /bin/sh: línea 1: 27516 Violación de segmento (`core' generado) ./tools/objtool/objtool orc generate --no-fp "drivers/gpu/drm/amd/amdgpu/.tmp_amdgpu_vce.o" make[4]: [scripts/Makefile.build:321: drivers/gpu/drm/amd/amdgpu/amdgpu_vce.o] Error 139 make[3]: [scripts/Makefile.build:579: drivers/gpu/drm/amd/amdgpu] Error 2 make[2]: [scripts/Makefile.build:579: drivers/gpu/drm] Error 2 make[1]: [scripts/Makefile.build:579: drivers/gpu] Error 2 make: *** [Makefile:1032: drivers] Error 2 ==> ERROR: Se produjo un fallo en build(). Cancelando...
Plexcon commented on 2018-02-02 19:33 (UTC)
/bin/sh: línea 1: 5200 Violación de segmento (`core' generado) ./tools/objtool/objtool orc generate --no-fp "drivers/infiniband/hw/mlx4/.tmp_mcg.o" make[4]: [scripts/Makefile.build:321: drivers/infiniband/hw/mlx4/mcg.o] Error 139 make[3]: [scripts/Makefile.build:579: drivers/infiniband/hw/mlx4] Error 2 make[2]: [scripts/Makefile.build:579: drivers/infiniband/hw] Error 2 make[1]: [scripts/Makefile.build:579: drivers/infiniband] Error 2 make: *** [Makefile:1032: drivers] Error 2 ==> ERROR: Se produjo un fallo en build(). Cancelando...
Plexcon commented on 2018-02-02 18:17 (UTC) (edited on 2018-02-05 19:49 (UTC) by Plexcon)
==> Verificando las firmas de las fuentes con gpg... linux-4.14.tar ... HA FALLADO (clave pública desconocida 79BE3E4300411886) patch-4.14.16 ... HA FALLADO (clave pública desconocida 38DBBDC86092693E) ==> ERROR: ¡No se ha podido verificar alguna de las firmas PGP!
sudo pacman-key --recv 38DBBDC86092693E sudo pacman-key --recv 79BE3E4300411886
niklaszantner commented on 2018-01-31 22:22 (UTC) (edited on 2018-01-31 22:23 (UTC) by niklaszantner)
@AriseEVE
==> Verifying source file signatures with gpg... linux-4.14.tar ... Passed patch-4.14.16 ... Passed
Works for me.
I assume that you have to add the keys to your system (looks like you are missing Linus' and Greg's key)
Following commands should help:
gpg --recv-key 79BE3E4300411886<br> gpg --recv-key 38DBBDC86092693E
AriseEVE commented on 2018-01-31 22:06 (UTC)
==> Verifying source file signatures with gpg... linux-4.14.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.14.16 ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified! <br> ==> ERROR: Makepkg was unable to build linux-ck.
Unable to build, key check failed.
graysky commented on 2018-01-29 21:49 (UTC)
@Mthw - Not out-of-date for the same reason as graysky commented on 2018-01-29 09:52
Morganamilo commented on 2018-01-29 11:02 (UTC)
Ah my bad. Wasn't thinking about the patches.
graysky commented on 2018-01-29 09:52 (UTC)
@morganamilo-not out of date until ck1 for 4.15.x is released.
AstroProfundis commented on 2018-01-26 08:26 (UTC)
4.14.15-2 works for me as well, thanks
bratpilz commented on 2018-01-26 01:25 (UTC)
linux-ck-4.14.15-2 builds successfully for me. Thanks for the patch!
graysky commented on 2018-01-26 00:03 (UTC)
I included a patch from loqs that should fix the build error in 4.14.15-2. Please test and give some feedback.
AstroProfundis commented on 2018-01-25 05:53 (UTC)
I tried to disable CONFIG_SCHED_MUQSS in defconfig (and regenerated the config file thus enabled FAIR_GROUP_SCHED and CFS_BANDWIDTH automatically), the build was success without error. Hope this info helps.
vp1981 commented on 2018-01-25 01:09 (UTC)
Hello, just for the record: https://www.spinics.net/lists/linux-block/msg21999.html and corresponding commit is in 4.14.15.
I'm not familiar with MuQSS source but hope that the fix is simple enough and CK make new ck2.
sir_lucjan commented on 2018-01-24 19:55 (UTC)
I tried to compile linux-ck but I had the same error.
sir_lucjan commented on 2018-01-24 19:51 (UTC)
Look, I think there's been a misunderstanding.
Error seems related to ck-patchset/muqss. I don't use muqss / ck patchset.
Sources 4.14.15 build fine without errors.
sir_lucjan commented on 2018-01-24 19:50 (UTC)
Look, I think there's been a misunderstanding.
Error seems related to ck-patchset/muqss. I don't use muqss / ck patchset.
Sources 4.14.15 build fine without errors.
graysky commented on 2018-01-24 19:44 (UTC)
Yes but without MuQSS. Works fine. Seems related to ck-patchset.
...without MuQSS? So if you apply all the patches in the broken out ck1 except for 0001-MuQSS-version-0.162-CPU-scheduler.patch
you are able to build without error?
sir_lucjan commented on 2018-01-24 15:48 (UTC)
@graysky
Yes but without MuQSS. Works fine.
Seems related to ck-patchset.
graysky commented on 2018-01-24 15:35 (UTC)
@sir_l - you compiled 4.14.15-1 without errors? Looks like you're building a differently named kernel. What are the differences vs linux-ck?
sir_lucjan commented on 2018-01-23 22:21 (UTC) (edited on 2018-01-23 22:23 (UTC) by sir_lucjan)
@graysky
Yes, seems related to MuQSS. I've compiled without errors:
Linux version 4.14.15-0.4-bfq-sq-mq-haswell-git (lucjan@archlinux) (gcc version 7.2.1 20171224 (GCC)) #1 SMP PREEMPT Mon Jan 22 17:03:42 CET 2018
Linux archlinux 4.14.15-0.4-bfq-sq-mq-haswell-git #1 SMP PREEMPT Mon Jan 22 17:03:42 CET 2018 x86_64 GNU/Linux
(stable-rc version)
graysky commented on 2018-01-23 22:19 (UTC)
@sir_l - Seems related to MuQSS. CK has been emailed.
Full log: https://gist.github.com/graysky2/b11cc7627168d951d96ceba14d79565c Clipped log:
kernel/sched/MuQSS.c: In function ‘try_to_wake_up’:
kernel/sched/MuQSS.c:1962:3: error: too few arguments to function ‘delayacct_blkio_end’
delayacct_blkio_end();
^~~~~~~~~~~~~~~~~~~
In file included from kernel/sched/MuQSS.c:41:0:
./include/linux/delayacct.h:125:20: note: declared here
static inline void delayacct_blkio_end(struct task_struct *p)
^~~~~~~~~~~~~~~~~~~
kernel/sched/MuQSS.c: In function ‘try_to_wake_up_local’:
kernel/sched/MuQSS.c:2025:4: error: too few arguments to function ‘delayacct_blkio_end’
delayacct_blkio_end();
^~~~~~~~~~~~~~~~~~~
In file included from kernel/sched/MuQSS.c:41:0:
./include/linux/delayacct.h:125:20: note: declared here
static inline void delayacct_blkio_end(struct task_struct *p)
^~~~~~~~~~~~~~~~~~~
CC [M] sound/drivers/vx/vx_pcm.o
CC [M] net/8021q/vlanproc.o
make[2]: *** [scripts/Makefile.build:320: kernel/sched/MuQSS.o] Error 1
make[1]: *** [scripts/Makefile.build:579: kernel/sched] Error 2
make: *** [Makefile:1032: kernel] Error 2
sir_lucjan commented on 2018-01-23 21:59 (UTC) (edited on 2018-01-23 21:59 (UTC) by sir_lucjan)
@graysky
Could you paste a log?
graysky commented on 2018-01-23 21:57 (UTC) (edited on 2018-01-23 21:58 (UTC) by graysky)
All - It seems that 4.14.15-1 is erroring out on the build for me. Need to dig into it further to see why.
graysky commented on 2018-01-23 21:39 (UTC)
@sir_lucjan - Thanks. I removed it but since it's harmless, I won't push a -2 release... it can be effective on the next version.
sir_lucjan commented on 2018-01-23 21:28 (UTC) (edited on 2018-01-23 21:31 (UTC) by sir_lucjan)
"chmod +x tools/objtool/sync-check.sh" is not needed anymore.
graysky commented on 2018-01-21 12:56 (UTC)
could you please append 'make clean' and 'rm -fr Documentation' after 'make mrproper'?
'rm -fr Documentation' saves >2Gbytes on tmpfs and can avoid 'No space left on device' error which happens in low-ram PC.
@enihcam - The make clean
would be redundant and I show linux-4.14/Documentation as being only 38M, not 2G.
zerophase commented on 2018-01-18 00:21 (UTC) (edited on 2018-01-18 00:21 (UTC) by zerophase)
@QuartzDragon Thanks got it working. I was zcatting config over too early in prepare earlier. (might have been missing switching Retpoline on) For some reason running zcat too early in prepare turns every module on.
QuartzDragon commented on 2018-01-17 23:55 (UTC)
@graysky @zerophase
The Retpoline patches for Spectre got backported to the current 4.14.14 release, not before. The Memory Page Isolation patches for Meltdown were earlier, though, yeah.
graysky commented on 2018-01-17 22:57 (UTC)
@zerophase - Yes, since version 4.14.11-1 I believe.
zerophase commented on 2018-01-16 21:29 (UTC)
I tried the whole zcat /proc/config.gz > ./.config. It seems to work fine, but it looks like more modules are turned on, and the kernel ballooned up by 51.66 MiBs for me. Did anyone else notice the kernel get larger?
Are the Spectre and Meltdown protections turned on by default?
cokomoko commented on 2018-01-12 20:28 (UTC)
@graysky No, I do not change anything. But I use the system in Turkish. Could it be a problem?
graysky commented on 2018-01-12 20:18 (UTC) (edited on 2018-01-12 20:18 (UTC) by graysky)
@cokomoko - Builds find for me. Are you modifying anything when building?
@gustawho - Yes.
gustawho commented on 2018-01-12 19:34 (UTC)
Does/will this build include any patches to address Meltdown and/or Spectre?
cokomoko commented on 2018-01-12 19:28 (UTC) (edited on 2018-01-12 19:34 (UTC) by cokomoko)
CC [M] arch/x86/crypto/sha512-mb/sha512_mb.o AS [M] arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.o CC [M] arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.o AS [M] arch/x86/crypto/sha512-mb/sha512_mb_mgr_submit_avx2.o AS [M] arch/x86/crypto/sha512-mb/sha512_x4_avx2.o LD [M] arch/x86/crypto/sha512-mb/sha512-mb.o arch/x86/crypto/sha512-mb/sha512_mb.o: file not recognized: Dosya biçemi tanınmıyor make[3]: [scripts/Makefile.build:560: arch/x86/crypto/sha512-mb/sha512-mb.o] Error 1 make[2]: [scripts/Makefile.build:573: arch/x86/crypto/sha512-mb] Error 2 make[1]: [scripts/Makefile.build:573: arch/x86/crypto] Error 2 make: [Makefile:1032: arch/x86] Error 2
Where's the problem?
enihcam commented on 2018-01-11 04:47 (UTC)
Thank you @QuartzDragon.
Maybe @graysky could simple add a step to zcat /proc/config.gz to somewhere, for example /tmp/.config? I thought this should be harmless. In this way, people who want to reuse current config could save the manual step, i.e. just open the menu and load /tmp/.config.
zerophase commented on 2018-01-11 04:00 (UTC)
I wouldn't mind a solution for config_current either. I can't always remember what I turned on in the kernel every time.
QuartzDragon commented on 2018-01-11 03:21 (UTC) (edited on 2018-01-11 03:22 (UTC) by QuartzDragon)
@enihcam
You can always just keep config.last aside, or just zcat /proc/config.gz manually if you really need to.
enihcam commented on 2018-01-11 01:51 (UTC)
@graysky, is there any alternative solutions to using '_use_current'? I have many specialized devices running linux-ck, removal of _use_current causes a lot of troubles in maintaining the kernels.
Lessaj commented on 2018-01-09 01:26 (UTC) (edited on 2018-01-09 01:26 (UTC) by Lessaj)
As long as it stops to ask you for any CONFIG that it's missing it's good to keep. It used to stop to ask, I think what's preventing it is:
yes "" | make config >/dev/null
graysky commented on 2018-01-07 20:12 (UTC)
...I'm beginning to wonder if the _use_current
variable is more trouble than it's worth
Lessaj commented on 2018-01-07 19:16 (UTC) (edited on 2018-01-07 19:17 (UTC) by Lessaj)
@eugen-b @Tjuh The parameter is not in the current config unless you've booted with a kernel that contains it so I added it, I believe it's actually getting stuck further down in prepare but commenting that out fixes it because it doesn't overwrite the current config.
zcat /proc/config.gz > ./.config
echo "CONFIG_PAGE_TABLE_ISOLATION=y" >> ./.config
Tjuh commented on 2018-01-07 16:48 (UTC)
Same issue as eugen-b when enabling config_audit=y in the config file. Haven't been able to compile since version 4.14.6-2.
eugen-b commented on 2018-01-07 16:21 (UTC) (edited on 2018-01-07 16:48 (UTC) by eugen-b)
I got endless lines related to CONFIG_PAGE_TABLE_ISOLATION=y after makeconfig -sri
I edited the PKGBUILD with _use_current=n, but it didn't help.
What helped was commenting the following lines in PKGBUILD
### Optionally use running kernel's config
# code originally by nous; http://aur.archlinux.org/packages.php?ID=40191
# if [ -n "$_use_current" ]; then
# if [[ -s /proc/config.gz ]]; then
# msg "Extracting config from /proc/config.gz..."
# # modprobe configs
# zcat /proc/config.gz > ./.config
# else
# warning "Your kernel was not compiled with IKCONFIG_PROC!"
# warning "You cannot read the current config!"
# warning "Aborting!"
# exit
# fi
# fi
Saren commented on 2018-01-07 04:36 (UTC)
@graysky Thanks for making the toggle back.
graysky commented on 2018-01-06 12:24 (UTC) (edited on 2018-01-06 12:31 (UTC) by graysky)
@presianbg - My bad. Fixed in 4.14.12-3.
@saren - Yes, some recent benchmarking I did on a dual quad showed a pretty big hit so I reasoned that 99+% of users want it disabled. I reenabled the variable toggle.
presianbg commented on 2018-01-06 09:47 (UTC)
Hi, happy 2018! Wish you all the best! bfq-sq is missing again... what is going on :?
Saren commented on 2018-01-06 03:45 (UTC)
Hi there. Since https://aur.archlinux.org/cgit/aur.git/diff/PKGBUILD?h=linux-ck&id=2315c7af5630
does that mean I will have to comment out the NUMA disabled code everytime? Thanks.
tosto commented on 2018-01-05 18:01 (UTC)
@sl13kp Disabilita le notifiche, dovresti trovare un link in alto a destra nel riquadro "Package Actions" (e per favore evita di spammare nei commenti).
sl13kp commented on 2017-12-31 00:12 (UTC)
avete scocciato con le notifiche non mi interessa questo programma
QuartzDragon commented on 2017-12-28 09:49 (UTC) (edited on 2017-12-28 09:50 (UTC) by QuartzDragon)
@kurwall
Try deleting your old build files, because the patch applies perfectly fine for me. If you're not using TMPFS for your builds, then your old build files will stick around, causing you issues if you don't delete them every now and then.
kurwall commented on 2017-12-28 01:46 (UTC)
The GCC patch needs to be redone, as currently it is not applying properly
air-g4p commented on 2017-12-19 09:58 (UTC)
Hi grayslake,
SUCCESS! Linux-ck can now be built without issue in a clean chroot.
To make it absolutely clear to anyone who wants to build linux-ck in a clean chroot, grayslake referred to specifying the correct _subarch variable for your system on line 38 of PKGBUILD prior to building.
You, ROCK, grayslake!
Thank you for your assistance.
All the best - and Merry Christmas,
air|g4p
graysky commented on 2017-12-18 20:10 (UTC)
@air-g4p - You need to assign a value to the _subarch
variable (line 38) before you try building.
air-g4p commented on 2017-12-18 15:55 (UTC)
oops: my missing (below) linux-ck 4.14.7-1 build failure link is here:
air-g4p commented on 2017-12-18 15:52 (UTC)
Hi grayslake,
I am sorry to have to inform you that using: extra-x86_64-build
fails with either linux-ck 4.14.6-3 or with linux-ck 4.14.7-1.
I have pasted the complete failed build runs at:
linux-ck 4.14.6-3 (per your suggestion) lives here: https://bpaste.net/show/cad411ec029a
and also with: linux-ck 4.14.7-1, here:
Despite the 'advice' generated just prior to build failure:
Console input/output is redirected. Run 'make oldconfig' to update configuration.
$ make oldconfig make: *** No rule to make target 'oldconfig'. Stop.
and ofc, this also:
$ sudo make oldconfig [sudo] password for <userid>: make: *** No rule to make target 'oldconfig'. Stop.</userid>
Those 'make oldconfig' failures occur irrespective of whether a user is in their correct build directory, or in their chroot directory = /var/lib/archbuild/extra-x86_64/<userid>/build</userid>
Also, carefully note, the build process never stopped, prior to failure, to ask me, which CPU I wanted to build support for. The current linux-ck AURs I have tested above both only auto-select '> 23. Generic-x86-64 (GENERIC_CPU)', then immediately fail.
grayslake - I do appreciate your ongoing support, but I would like to get to the bottom of this issue, sometime 'soon'. If you have specific commands you want me to test, let me know.
All the best,
air|g4p
graysky commented on 2017-12-18 12:22 (UTC)
@artafinde - good idea.
sir_lucjan commented on 2017-12-18 11:29 (UTC) (edited on 2017-12-18 11:30 (UTC) by sir_lucjan)
artafinde commented on 2017-12-18 07:58 (UTC)
@graysky I suggest for now to delete the 24 option (line #38) on the PKGBUILD. If a user wants native detection let him go through makepkg
.
foi commented on 2017-12-18 06:16 (UTC)
Hi!
Failed in install (distro: manjaro gnome):
==> Verifying source file signatures with gpg... linux-4.14.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.14.7 ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-ck.
air-g4p commented on 2017-12-18 05:41 (UTC)
Hi graysky,
Thank you very much for attention and extremely quick correction of this issue. Highly impressive, indeed!
When I get a chance, I'll try a re-build with the current release, and let you how things went.
All the best,
air|g4p
graysky commented on 2017-12-17 23:33 (UTC) (edited on 2017-12-17 23:34 (UTC) by graysky)
@artafinde - Short of applying this patch and shipping the corresponding config (which makes building for repo-ck more difficult), I don't know how to cover that use-case.
It might be a bit of a hassle for you, but if you just run makepkg -s
outside of the chroot, setup the config to your liking, you can replace the shipped config with config.last and update the checksums before you build in the chroot.
artafinde commented on 2017-12-17 23:23 (UTC)
@graysky: if you choose 24 (native) then you are asked again for P6_NOPS which fails to auto-configure with "yes" Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW)
graysky commented on 2017-12-17 09:56 (UTC)
@air-g4p - Yes, the failure is due to user intervention being required to select a sub-arch. Please try 4.14.16-3 in which the _subarch
variable should take care of this use case.
air-g4p commented on 2017-12-17 06:21 (UTC)
Hi graysky,
In the event you are not aware, your linux-ck 4.14.6-2 AUR fails to build in a clean chroot, using: extra-x86_64-build.
Your immediately prior release also failed to build using either extra-x86_64-build or makechrootpkg -c -r $CHROOT.
We know for a fact your AUR is broken because when discussing this linux-ck build failure on #archlinux, another experienced AUR user also replicated the same extra-x86_64-build failure on his system.
I have pasted my entire build run for your review at: https://bpaste.net/show/3c5c3d9ea326. That paste URL will remain valid for one month.
Additionally, for those users willing to employ this approach, I can confirm your AUR can be successfully built and installed with: makepkg -si.
I hope you are able to determine, and correct, whichever part(s) of your code is/are causing the build failure, as many of us strongly prefer to build AURs exclusively within a clean chroot environment.
Thank you for providing an otherwise excellent alternative kernel. Your effort is immensely appreciated.
Cheers,
air|g4p
eduardoeae commented on 2017-12-16 12:48 (UTC)
Works OK now. Thanks!
graysky commented on 2017-12-16 11:36 (UTC)
@edu and sha - Please try now.
Shaikh commented on 2017-12-16 08:03 (UTC)
I encountered the same problem as @eduardoeae.
eduardoeae commented on 2017-12-16 03:17 (UTC)
Your packages (from repo-ck.com) are failing with "missing required signature". I have been using them for months without problem. Also tried re-adding your key (pacman-key -r 5EE46C4C && pacman-key --lsign-key 5EE46C4C) as the site suggests, but still not working.
Pinned Comments
graysky commented on 2022-04-14 11:45 (UTC)
Is anyone interested in testing the 5.17.y ck kernel? I'd like some broader feedback before I push it out to the AUR and to the repo. Please try it here if interested:
http://repo-ck.com/testing/
You can download a prebuilt package or build yourself.
Please post feedback good or bad to the repo-ck thread to keep it all in one place: https://bbs.archlinux.org/viewtopic.php?pid=2031356