| View previous topic :: View next topic |
| Author |
Message |
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
 Posted: Sun Nov 10, 2013 9:20 pm Post subject: |
 |
|
| thunderrd wrote: | | Is there any hope that there will be further updates |
I hope so
| thunderrd wrote: | | Things have been pretty silent here. |
I agree and must acknowledge that 25% of the reasons of the silence is on my full and entire responsibility.
Don't ask me to distribute the 75 other %, to each is own!
| thunderrd wrote: | | I saw the problems in Bug #479382, and am thinking maybe you have had enough proxy maintaining |
Not really. The idea of proxy maintaining perfectly fits my purpose.
When there is a will, there is a way. And I think that until the Bug you mention, we have both (proxy-maintainers and I) fruitfully managed to find one.
I must acknowledge with Bug #479382 a lack of good will from my own side.
Several reasons triggered it: the poor performances of 3.9, 3.10 kernels is one of them, the nvidia mess is another one, "upstream" reactivity a third, ... a fourth...
In such conditions, v.g : I am not myself convinced that the final result is worth it, I admit that fighting / arguing with the proxy-maintainers about a silly-stupid-trivial patch is well above my forces.
| thunderrd wrote: | | I, for one, appreciate all that you have done, Eric. Thank you. |
Thank you for saying this.
But... be aware that... I am for absolutely nothing in the actually best performing ck-sources kernel release available in portage, hmmm... the best performing kernel release available in portage! 
OK, then, practically :
- I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47
- I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels)
- I expect being capable to push 3.10 and 3.11 during week 48.
If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards, I'll require a slot to be opened in gentoo-sunrise.
Thank you, thunderrd, for your support.
_________________
Last edited by aCOSwt on Sun Nov 10, 2013 10:50 pm; edited 2 times in total |
|
| Back to top |
|
 |
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Nov 10, 2013 10:21 pm Post subject: |
|
|
| aCOSwt wrote: | | - I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47 |
That is four months old by now, EOL and insecure; is this still worth pursuing?
| aCOSwt wrote: | | - I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels) |
Definitely worth it for people hit by the changes in the later kernels.
| aCOSwt wrote: | | - I expect being capable to push 3.10 and 3.11 during week 48. |
Sounds good; please note that I have made a forward ported patch for 3.12 some time ago if we want to add more support, I'll probably test this patch more thoroughly soon.
| aCOSwt wrote: | | If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards |
Feel free to explain why these patches are needed and I'll look into it. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Mon Nov 18, 2013 11:30 am Post subject: |
|
|
| TomWij wrote: | | aCOSwt wrote: | | - I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47 |
That is four months old by now, EOL and insecure; is this still worth pursuing? |
It's not me who wrote | Quote: | # For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
# as some of them experience problems with the new stable kernel 3.10.7; |
But... I... quite agree with that.
In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution.
BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.
Of course this is only my opinion as far as I am concerned.
Nevermind anyway.
However, I do not know how you expect the following snippet of code to be working | Code: | for j in ${KPATCH_DIR}/*/50*_*.patch*; do
if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then
UNIPATCH_DROP+=" $(basename ${j})"
fi
done |
I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally.
_________________
|
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Nov 18, 2013 11:41 am Post subject: |
|
|
| aCOSwt wrote: | It's not me who wrote | Quote: | # For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
# as some of them experience problems with the new stable kernel 3.10.7; |
But... I... quite agree with that. |
Well, yeah, I think we're quite close to dropping that.
| aCOSwt wrote: | | In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution. |
True, but an overlay / local ebuild might fit the purpose better; and isn't this something that can be forward ported? If you really want it, go ahead, alternative kernel sources aren't considered supported by Gentoo Security; it is just a suggestion to avoid affecting users and/or receiving blame.
| aCOSwt wrote: | | BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes. |
You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.
And when you want to instead define your own USE flag gentoo-experimental you can have it set K_EXP_GENPATCHES_LIST="*" when calling the unpack function; note that you need to set K_EXP_GENPATCHES_PULL or override SRC_URI if you do so, because due to Portage's limitations we can't export a variable to control the USE flag name.
| aCOSwt wrote: | However, I do not know how you expect the following snippet of code to be working | Code: | for j in ${KPATCH_DIR}/*/50*_*.patch*; do
if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then
UNIPATCH_DROP+=" $(basename ${j})"
fi
done |
I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally. |
Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code... |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Mon Nov 18, 2013 12:07 pm Post subject: |
|
|
| TomWij wrote: | | aCOSwt wrote: | | BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes. |
You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag. |
I understand that but if you want the genpatches experimental tarball and have the ck-sources experimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches.
| TomWij wrote: | | aCOSwt wrote: | However, I do not know how you expect the following snippet of code to be working | Code: | for j in ${KPATCH_DIR}/*/50*_*.patch*; do
if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then
UNIPATCH_DROP+=" $(basename ${j})"
fi
done |
I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally. |
Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code... |
Well, having K_EXP_GENPATCHES_LIST initialized the way I (&& hardened) would initialize UNIPATCH_EXCLUDE, I mean, something of the kind | Code: | K_EXP_GENPATCHES_LIST="
5000_BFQ-1-block-cgroups-kconfig-build-bits-for-v6r2-3.10.patch
5000_BFQ-2-block-introduce-the-v6r2-I-O-sched-for-3.10.patch1
5000_BFQ-3-block-add-Early-Queue-Merge-EQM-v6r2-I-O-sched-for-3.10.patch1
5000_BFQ-4-block-Switch-from-v6r2-for-3.10.0-v6r2-for-3.10.patch" |
Does not work for me.
BTW, having K_EXP_GENPATCHES_LIST="*" as you suggest, does not work either.
Only having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally actually does the trick.
_________________
|
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Nov 18, 2013 12:49 pm Post subject: |
|
|
| aCOSwt wrote: | | TomWij wrote: | | aCOSwt wrote: | | BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes. |
You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag. |
I understand that but if you want the genpatches experimental tarball and have the ck-sources experimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches. |
All its occurences are guarded by -z ${K_EXP_GENPATCHES_NOUSE} which means that the USE flag is only checked if you not set that; thus, if you set it, the eclass won't check the USE flag.
| aCOSwt wrote: | | TomWij wrote: | | aCOSwt wrote: | However, I do not know how you expect the following snippet of code to be working | Code: | for j in ${KPATCH_DIR}/*/50*_*.patch*; do
if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then
UNIPATCH_DROP+=" $(basename ${j})"
fi
done |
I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally. |
Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code... |
Well, having K_EXP_GENPATCHES_LIST initialized the way I (&& hardened) would initialize UNIPATCH_EXCLUDE, I mean, something of the kind | Code: | K_EXP_GENPATCHES_LIST="
5000_BFQ-1-block-cgroups-kconfig-build-bits-for-v6r2-3.10.patch
5000_BFQ-2-block-introduce-the-v6r2-I-O-sched-for-3.10.patch1
5000_BFQ-3-block-add-Early-Queue-Merge-EQM-v6r2-I-O-sched-for-3.10.patch1
5000_BFQ-4-block-Switch-from-v6r2-for-3.10.0-v6r2-for-3.10.patch" |
Does not work for me. |
UNIPATCH_EXCLUDE is for the user.
| aCOSwt wrote: | BTW, having K_EXP_GENPATCHES_LIST="*" as you suggest, does not work either.
Only having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally actually does the trick. |
Hmm, this indeed behaves odd, will investigate further. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Mon Nov 18, 2013 1:21 pm Post subject: |
|
|
Okay, my bad, you have found a bug; thank you very much, this is fixed now.
| Quote: | + 18 Nov 2013; Tom Wijsman <TomWij@gentoo.org> kernel-2.eclass:
+ Reimplemented K_EXP_GENPATCHES_LIST patch matching by switching the LHS with
+ the RHS and doing much more proper matching (50 works, *_BFQ-* works,
+ etc...); spotted by aCOSwt on the forums, my earlier tests apparently didn't
+ check this properly. |
| Code: | - if [[ ! "${K_EXP_GENPATCHES_LIST}" == *"$(basename ${j})"* ]] ; then
- UNIPATCH_DROP+=" $(basename ${j})"
- fi
+ for k in ${K_EXP_GENPATCHES_LIST} ; do
+ [[ "$(basename ${j})" == ${k}* ]] && continue 2
+ done
+ UNIPATCH_DROP+=" $(basename ${j})"
|
Sorry, my testing appears to have been improper on this variable; I'm not particularly good at Bash, but the above diff (replaced lines with - by +) should do fine as far as I can see in new tests. |
|
| Back to top |
|
|
thunderrd
n00b
Joined: 20 Aug 2010
Posts: 59
|
| Posted: Mon Nov 18, 2013 3:24 pm Post subject: |
|
|
FWIW, and in case you don't already know, Con has:
patch-3.12-ck1.bz2
and
3.12-sched-bfs-443.patch
available in his server now. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Fri Nov 22, 2013 5:10 pm Post subject: |
|
|
 *** Inadvertently reedited ****
_________________
Last edited by aCOSwt on Tue Dec 03, 2013 8:14 pm; edited 2 times in total |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sat Nov 23, 2013 11:49 am Post subject: |
|
|
- And I forgot telling that from 3.8, following a discussion I had with him on IRC, Con removed from the ck-patchset a couple of patches aiming at reducing the apparent IO throughput, in particular through extremely low settings of the dirty ratios.
These ratios are now back to default, which means that IO-bound tasks are now CPU-bound for much longer than usual.
This may well explain why some of you might well, since 3.8, feel their system less interactive during heavy disk write operations.
Those wishing to restore pre-3.8 behaviour can
| Code: | #echo 1 > /proc/sys/vm/dirty_background_ratio
#echo 1 > /proc/sys/vm/dirty_ratio |
To be done after having entered your preferred DE as it is very likely to fiddle these values when initializing.
- And I of course also forgot to urge you to keep away from the following kernel config settings :
RCU_USER_QS
RCU_NOCB_CPU
_________________
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Tue Dec 03, 2013 8:11 pm Post subject: |
|
|
Following BUG 492966, and thanks to Tom Wijsman the ck-sources tree has been updated.
3.11 users should upgrade to 3.11.10,
3.12 users should upgrade to 3.12.2
Note about 3.12.2 : ck-patched kernels have always been concerned with random suspend/resume issues.
This is even more true since 3.9 and the "dramatic CPU offline code changes to mainline"
Con tried to address these issues with several patches, among which the bfs443-hibernate_test2.patch.
The idea grounding this patch is affining tasks to CPU0 as CPUs go offline.
The experimental use flag is back in the ck-sources together with a new use flag named hibernate.
emerging the ck-sources-3.12.2 with both use flags set will apply the above patch to bfs.
OK, OK... I know... BFS-444 is out today... this making my initiative... obsolete! 
But... 444 was not even planned when I posted my bump request last week.
I should push it as part of 3.12.3
_________________
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sat Dec 14, 2013 3:55 pm Post subject: |
|
|
Following BUG 494234, and thanks to Tom Wijsman, the ck-sources tree has been updated.
3.4 users should upgrade to 3.4.74,
3.10 users should upgrade to 3.10.24,
3.12 users can upgrade to 3.12.5 and test the new bfs-444 successfully addressing several suspend/resume issues.
_________________
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun Mar 02, 2014 7:10 pm Post subject: |
|
|
Following BUG 502442, and thanks to Tom Wijsman, the ck-sources tree has been updated.
3.4 users should upgrade to 3.4.82,
Be aware that a new custom patch is being applied with this release.
Without it, the build of the kernel would fail because of an unresolved reference.
Since 3.4.81, linux defines a new function which is of absolutely no use to bfs.
(It does not concern security either, it is nothing but yet another pathetic try for the cfs to catch some idea of the cpu load when working tickless)
However, this function is declared external in the sched.h header used by bfs.
=> The trivial patch simply adds a void definition of that function in the rightly named compatibility crap section of the bfs.c code.
_________________
|
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Thu Mar 06, 2014 9:57 am Post subject: |
|
|
Following BUG 503142, and thanks to Tom Wijsman, the ck-sources tree has been updated.
3.10 users should upgrade to 3.10.32,
3.12 users should upgrade to 3.12.13,
Be aware that the 3.12 branch shows a regression in the handling of usbatm debug traces, so those who get CONFIG_USB_ATM are concerned.
3.13.5 was also made available.
Be aware that, despite a relatively high release number, 3.13.5 is an early release of the ck-sources => It is likely to show a couple of problems.
In particular the fact that it breaks kvm seems confirmed.
| kernelOfTruth wrote: | @aCOSwt:don't be so hard on yourself  |
I first tried to be hard on others... it does not work well either... 
_________________
Last edited by aCOSwt on Fri May 09, 2014 9:27 pm; edited 1 time in total |
|
| Back to top |
|
|
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2751
Location: Here and Away Again
|
| Posted: Thu Mar 06, 2014 11:38 am Post subject: |
|
|
Many thanks. Just booted 3.13.5 on my main-machine.
Be aware of that, you also helped me solve a couple of issues on a laptop I am testing things currently. For whatever reason, X did not want to see the device it should have been using with the i915-driver, while vesa worked. I had also some trouble getting terminal emulators to work.
Yes, both were something something /dev something related issues, but I had no real clues where to look at, or what. This is no surprise, because, before someone screams udev, I'll just say:
static-dev
Lo, and behold, everything just worked with the new(er) kernel. It's embarrassingly a case of not sure what I did, but that fixed it!
Must. Find. Reason.
Anyblue!
Thanks! 
_________________
Kindest of regardses. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sat Apr 26, 2014 7:35 pm Post subject: |
|
|
Following BUG 508768, and thanks to Markos Chandras, the ck-sources tree has been updated.
3.13 users should upgrade to 3.13.11,
That release should no longer break kvm.
_________________
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Fri May 09, 2014 9:24 pm Post subject: |
|
|
Following BUG 509930, and thanks to Markos Chandras, the ck-sources tree has been updated.
3.4 users should upgrade to 3.4.89,
3.10 users should upgrade to 3.10.39,
3.12 users should upgrade to 3.12.19,
The regression in the handling of usbatm debug traces with the 3.12 series went fixed in 3.12.19
3.14.3 was also made available.
_________________
|
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1256
|
| Posted: Sun May 18, 2014 10:18 am Post subject: |
|
|
| please, update to 3.14.4 |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun May 18, 2014 3:56 pm Post subject: |
|
|
| Perfect Gentleman wrote: | | please, update to 3.14.4 |
Being said that I am working on updates but was more targetting a 3.14.5 than a 3.14.4, I am interested to know more about your reasons for this. Security fix ? Any particular driver / feature bug fix ? As well as the level of urgency. Depending on that, I could be able to suggest a temporary workaround.
_________________
|
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1256
|
| Posted: Sun May 18, 2014 4:04 pm Post subject: |
|
|
| yep, security issues that were fixed with 3.14.4 patch. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun May 18, 2014 7:18 pm Post subject: |
|
|
Tom, weren't you supposed to be devaway this week end ?
OK... had just asked because, strictly speaking, sys-kernel/ck-sources unequivocally states : | Code: | WARN: postinst
ck-sources is UNSUPPORTED by Gentoo Security.
This means that it is likely to be vulnerable to recent security issues. |
It is the very first time I get a bump request for security fixes.
Nevermind. I won't refuse helping a Perfect Gentelman having apparently registred here in the first intention to get the best *-sources money can't buy.
(Even if 3.14.4 is... actually not the best release!... yet!)
Will do the necessary testings tonight and post the ebuild(s) tomorrow.
_________________
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
