1 |
Am Sun, 21 Aug 2016 07:28:17 -0400 |
2 |
schrieb Rich Freeman <rich0@g.o>: |
3 |
|
4 |
> On Sun, Aug 21, 2016 at 6:20 AM, Peter Humphrey |
5 |
> <peter@××××××××××××.uk> wrote: |
6 |
> > On Sunday 21 Aug 2016 05:55:06 Rich Freeman wrote: |
7 |
> >> On Sun, Aug 21, 2016 at 5:12 AM, Peter Humphrey |
8 |
> >> <peter@××××××××××××.uk> |
9 |
> > wrote: |
10 |
> [...] |
11 |
> >> |
12 |
> >> No idea, but upstream is up to 4.4.19, and 4.6.7 (which is now |
13 |
> >> EOL). So, those are pretty old versions. I see 4.4.19 in the |
14 |
> >> Gentoo repo, and 4.7.2 (which is probably where 4.6 users should |
15 |
> >> be moving to). |
16 |
> > |
17 |
> > Yes, this ~amd64 box is now at 4.7.2, but I have an amd64 and two |
18 |
> > x86 systems and they both want to downgrade to 4.1.15-r1, which eix |
19 |
> > shows as the latest stable version. |
20 |
> > |
21 |
> > I thought 4.4.6 and 4.6.4 were both pretty stable; was I wrong? |
22 |
> > |
23 |
> |
24 |
> I'm sure they both work. However, upstream has released numerous |
25 |
> fixes since 4.4.6, and they will not be releasing security/bug/etc |
26 |
> fixes for 4.6.x. |
27 |
> |
28 |
> As long as there are no critical issues there is no issue with not |
29 |
> being completely up-to-date with the kernel's stable releases, and I'm |
30 |
> sure the Gentoo kernel team is tracking these sorts of issues. |
31 |
> However, it isn't a surprise that they dropped 4.6. If they |
32 |
> downgraded 4.1 I suspect that was a mistake somewhere along the ways - |
33 |
> I could see them upgrading it to something more recent. |
34 |
> |
35 |
> And there is nothing wrong with having some internal QA on kernel |
36 |
> releases. 4.1 had a nasty memory leak a release or two ago that was |
37 |
> killing my system after only an hour or two uptime. They took over a |
38 |
> week to stabilize the fix as well (though a patch was out fairly |
39 |
> quickly). So, I'm not in nearly the rush to update kernels as I used |
40 |
> to be (granted, unless you read all the lists it is easy to miss this |
41 |
> sort of thing). |
42 |
|
43 |
Surprise surprise, 4.7 has this (still not fully fixed) oom-killer bug. |
44 |
When I'm running virtual machines, it still kicks in. I wanted to stay |
45 |
on 4.6.x until 4.8 is released, and only then switch to 4.7. Now I was |
46 |
forced early (I'm using btrfs), and was instantly punished by doing so: |
47 |
|
48 |
The bfq patches I used were unstable (IO ops froze during boot, I was |
49 |
forced to hard-reset the system) and as a consequence btrfs eventually |
50 |
broke down a few hours later after the kernel booted without using bfq. |
51 |
|
52 |
I had to restore from backup. Gentoo could have simply masked 4.6.x |
53 |
with a masking message instead of removing it completely without |
54 |
warning. I'm now using deadline instead of bfq, and I'm not using cfq |
55 |
because it is everything else but running an interactive system |
56 |
regarding IO: have some more than normal background IO and desktop |
57 |
becomes unusable, audio and video apps starts skipping, games start |
58 |
freezing up to a minute. |
59 |
|
60 |
I'm now on 4.7.2 and I'm not happy due to the oom-killer mess. And |
61 |
going back to 4.4 or even 4.1 is probably an unrealistic option when |
62 |
using btrfs - at least I don't want to test it. |
63 |
|
64 |
> I really wish the kernel had separate |
65 |
> announce/discussion/patch lists. It is really annoying that there is |
66 |
> no way to get official notices up upstream updates without subscribing |
67 |
> to lkml and such. Is Linux the only FOSS project that has never heard |
68 |
> of -announce lists? |
69 |
> |
70 |
> I ended up bailing on gentoo-sources all the same. Not that there was |
71 |
> really anything wrong with it, but since I'm running btrfs and they've |
72 |
> had a history of nasty regressions that tend to show up MONTHS later |
73 |
> I've been a lot more picky about my kernel updates. I'm currently |
74 |
> tracking 4.1. I might think about moving to 4.4 in a little while. I |
75 |
> tend to stay on the next-to-most-recent longterm not long after a new |
76 |
> longterm is announced. That tends to give them enough time to work |
77 |
> out the bugs. Plus, I spend a lot less time playing with |
78 |
> configuration options this way (they don't change within a minor |
79 |
> version). |
80 |
|
81 |
This is why I wanted to stay major version behind currently stable - |
82 |
I'm using btrfs, too. And history shows that especially 4.x.{0,1} may |
83 |
introduce some nasty bugs if you are using edge technology like btrfs. |
84 |
|
85 |
As I said, I'm not happy with this situation currently but I arranged |
86 |
to live with it for the time being. |
87 |
|
88 |
With btrfs gaining no must-have features lately, I'm considering to |
89 |
stay with stable gentoo-sources when it switches to the unstable |
90 |
version I'm currently using - which might be 4.7 or 4.8, I'm not sure. |
91 |
I don't trust 4.7 currently, so I hope it will be 4.8. |
92 |
|
93 |
-- |
94 |
Regards, |
95 |
Kai |
96 |
|
97 |
Replies to list-only preferred. |