From: Grant Edwards <grant.b.edwards@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Slightly corrupted file systems when resuming from hibernation
Date: Wed, 17 Apr 2024 13:52:34 -0000 (UTC) [thread overview]
Message-ID: <uvok72$dfg$1@ciao.gmane.io> (raw)
In-Reply-To: 4343017.ejJDZkT8p0@rogueboard
On 2024-04-17, Michael <confabulate@kintzios.com> wrote:
>> > But, to get back to the beginning of this discussion: if there is a
>> > risk that my aging hardware possibly can less and less cope with
>> > newer and newer kernels, should I put something like
>> >
>> > >=sys-kernel/gentoo-sources-6.7.0
>> >
>> > into file "package.mask" to stay with "longterm" 6.6.* kernels?
>>
>> Yes: if you want to avoid getting upgraded to 6.8 when it gets
>> kernel.org "longterm" status and gentoo-sources "stable" status, then
>> a statement like that in in package.mask will keep you on
>> gentoo-sources 6.6 kernels (which are "longterm" on kernel.org).
> I am not sure the assumption "... aging hardware possibly can less and less
> cope with newer and newer kernels" is correct.
Good point. My "yes" was in response to a question of the form "if X
is true, should I do Y". I did not attempt to address the likelyhood
that X was actually ture, only whether Y was appropriate if X was
true.
> As already mentioned newer kernels have both security and bug fixes.
> As long as you stick with stable gentoo-sources you'll have these in
> your system. Later kernels also come with additional kernel drivers
> for new(er) hardware. You may not need/want these drivers if you do
> not run the latest hardware. Using 'make oldconfig' allows you to
> exclude such new drivers, but include new security options and/or
> functionality as desired.
>
> It can happen for new code to introduce some software regression.
The usual worries with running newer kernels on older hardware are:
1) Performance degradation when upgrading kernels on older hardware.
On one embedded project I work with we're still running a 2.6
kernel because network throughput drops by 25-30% when we upgrade
to 3.x kernels. There's nothing "wrong" with those 3.x kernels,
they're just bigger and significantly slower. [Even when built
with a config that's as identical to the 2.6 kernels as possible.]
2) Lack of support for old hardware when running a newer kernels.
I used to run into this when running nvidia-drivers.
Gentoo-sources would mark a new kernel stable, but my video board
would not be supported by nvidia-drivers versions that were
supported for that new stable kernel. I would mask newer kernels
until and run older "longterm" kernels as long as I could. I would
evenually be forced to buy a new video card. After going through
that cycle a couple times, I swore off NVidia video cards and
life's been much eaiser since.
next prev parent reply other threads:[~2024-04-17 13:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 17:46 [gentoo-user] Slightly corrupted file systems when resuming from hibernation Dr Rainer Woitok
2024-04-14 18:41 ` [gentoo-user] " Dr Rainer Woitok
2024-04-15 11:48 ` Michael
2024-04-16 9:04 ` Dr Rainer Woitok
2024-04-16 10:15 ` Michael
2024-04-16 13:29 ` Dr Rainer Woitok
2024-04-16 13:53 ` Arve Barsnes
2024-04-16 14:53 ` Grant Edwards
2024-04-16 15:07 ` Dale
2024-04-16 15:01 ` Dale
2024-04-16 15:14 ` Grant Edwards
2024-04-16 16:43 ` Dr Rainer Woitok
2024-04-16 19:26 ` Grant Edwards
2024-04-17 9:10 ` Michael
2024-04-17 13:52 ` Grant Edwards [this message]
2024-04-17 20:05 ` Dale
2024-04-17 20:32 ` Grant Edwards
2024-04-17 22:18 ` Dale
2024-04-17 15:50 ` Dr Rainer Woitok
2024-04-17 17:52 ` Wols Lists
2024-04-17 10:37 ` Dr Rainer Woitok
2024-04-17 10:56 ` Michael
2024-04-17 14:11 ` Grant Edwards
2024-04-17 16:11 ` Dr Rainer Woitok
2024-04-17 17:53 ` Grant Edwards
2024-04-16 10:55 ` Dale
2024-04-16 11:15 ` Michael
2024-04-16 12:48 ` Dale
2024-04-16 14:32 ` Jack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='uvok72$dfg$1@ciao.gmane.io' \
--to=grant.b.edwards@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox