From: Pierre Langlois <pierre.langlois@gmx.com>
To: Leo Famulari <leo@famulari.name>
Cc: pierre.langlois@gmx.com, 50343@debbugs.gnu.org
Subject: [bug#50343] [PATCH] gnu: Add linux-libre 5.14.
Date: Sat, 11 Sep 2021 18:30:51 +0100 [thread overview]
Message-ID: <87y283kobm.fsf@gmx.com> (raw)
In-Reply-To: <YTy+9HHBhjqEXc/Q@jasmine.lan>
[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]
Leo Famulari <leo@famulari.name> writes:
> [[PGP Signed Part:Undecided]]
> On Sat, Sep 11, 2021 at 12:56:37PM +0100, Pierre Langlois wrote:
>> I just tried out 5.14.2 on my rockpro64 (rk3399 chip) and ethernet isn't
>> working :-/. It probably also affects the pinebook pro.
>>
>> Doing a bit of searching, I see it was reported upstream and this patch
>> introduced the issue https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210823143754.14294-1-michael.riesch@wolfvision.net/
>>
>> I see Manjaro has patched their kernel to revert the patch as well:
>> https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/commit/5e87e6f3b764d64bbb5b183e379a5fe64c3646ad
>
> Thanks for the report!
>
>> I suppose we could also apply that patch, although I'm sure it'll get
>> fixed upstream in a point release. We probably don't want to delay the 5.14
>> switch too much, maybe we could keep the linux-libre-5.13 variable
>> around for a little longer though? If not, I'm sure I could just use
>> 5.10 though.
>
> When they are two stable kernels [0], I typically keep the previous
> stable kernel as the Guix "default" until it stops being supported
> upstream, and then the latest stable kernel is made the default, and the
> older one is removed from Guix.
Oh I didn't know that, I thought we may switch to 5.14 earlier, that's
very sensible :-).
>
> I see in the upstream report that Sasha Levin is aware of the problem,
> and he is one of the stable kernel maintainers. So 5.13 should continue
> to work, and 5.14 should be fixed soon.
>
> We don't usually patch our kernels except for really critical problems;
> We use the stable and long-term support releases directly from upstream
> in order to avoid the old-school "custom distro kernel" thing.
Yeah I agree, the patch may fix the rk3399 ethernet but could break
other platforms, we don't know what the right fix should be.
>
> How about we keep things as they are now, and then reconsider if 5.13 is
> due for removal and the bug still exists in 5.14? I think that most
> rk3399 users in Guix should be okay for now, since the default kernel,
> 5.13, still works for them, right?
Sounds like a plan!
Thanks,
Pierre
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 519 bytes --]
prev parent reply other threads:[~2021-09-11 17:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 17:47 [bug#50343] [PATCH] gnu: Add linux-libre 5.14 Leo Famulari
2021-09-07 2:29 ` bug#50343: " Leo Famulari
2021-09-11 11:56 ` [bug#50343] " Pierre Langlois
2021-09-11 14:36 ` Leo Famulari
2021-09-11 17:30 ` Pierre Langlois [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y283kobm.fsf@gmx.com \
--to=pierre.langlois@gmx.com \
--cc=50343@debbugs.gnu.org \
--cc=leo@famulari.name \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).