Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ck-sources : All about choice !
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Sun Nov 10, 2013 9:20 pm    Post subject: Reply with quote

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! :wink:

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
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Sun Nov 10, 2013 10:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon Nov 18, 2013 11:30 am    Post subject: Reply with quote

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
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Mon Nov 18, 2013 11:41 am    Post subject: Reply with quote

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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Mon Nov 18, 2013 12:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Mon Nov 18, 2013 12:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1342

PostPosted: Mon Nov 18, 2013 1:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 34

PostPosted: Mon Nov 18, 2013 3:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Fri Nov 22, 2013 5:10 pm    Post subject: Reply with quote

:oops: *** Inadvertently reedited **** :oops:
_________________


Last edited by aCOSwt on Tue Dec 03, 2013 8:14 pm; edited 2 times in total
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Sat Nov 23, 2013 11:49 am    Post subject: Reply with quote

- 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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Tue Dec 03, 2013 8:11 pm    Post subject: Reply with quote

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.

:oops: OK, OK... I know... BFS-444 is out today... this making my initiative... obsolete! :roll:
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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Sat Dec 14, 2013 3:55 pm    Post subject: Reply with quote

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
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Sun Mar 02, 2014 7:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5610
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Mar 05, 2014 4:58 pm    Post subject: Reply with quote

ck-patchset for 3.13 kernel series is out

and immediately the computer feels like it's 2 generations younger :lol:


evaluating now under heavy CPU load and memory pressure against heavily patched up 3.13 kernel to 3.14 CFS (wasn't working not quite bad but still sluggishness was there, 8 GB zram, ZFS mirror1, Btrfs w. compression (lzo) on root)
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Wed Mar 05, 2014 6:07 pm    Post subject: Reply with quote

kernelOfTruth wrote:
ck-patchset for 3.13 kernel series is out

And even more that what's just apparent
ha bha! :evil:
For the first time in the ck-sources' life, gentoo-ck-sources could even have been the first to offer a ck-patched kernel...
I just apparently... failed!
Ha bha! :evil:

BTW, seems to get a couple of trouble under kvm.
_________________
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5610
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Mar 05, 2014 7:10 pm    Post subject: Reply with quote

@aCOSwt:

don't be so hard on yourself :)


hopefully virtualbox isn't affected as well
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2375
Location: Hilbert space

PostPosted: Thu Mar 06, 2014 9:57 am    Post subject: Reply with quote

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 has also be 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... :twisted:
_________________
Back to top
View user's profile Send private message
Chiitoo
l33t
l33t


Joined: 28 Feb 2010
Posts: 744
Location: Here and Away Again

PostPosted: Thu Mar 06, 2014 11:38 am    Post subject: Reply with quote

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! 8)
_________________
Kind Regards,
~ The Noob Unlimited ~

Sore wa sore, kore wa kore.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8
Page 8 of 8

 
Jump to:  
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