GNU bug report logs -
#32840
linux-libre 4.18.9: shpchp is no longer a module (now: built-in)
Previous Next
Reported by: Nils Gillmann <gillmann <at> n0.is>
Date: Tue, 25 Sep 2018 20:18:01 UTC
Severity: normal
Tags: fixed
Done: ludo <at> gnu.org (Ludovic Courtès)
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32840 in the body.
You can then email your comments to 32840 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Tue, 25 Sep 2018 20:18:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nils Gillmann <gillmann <at> n0.is>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 25 Sep 2018 20:18:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
at taler we need shpchp as a module in the initrd.
Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
you were able to just specify it for the initrd.
With 4.18.9, this module became a compile-in/built-in (see linux
commit log). I want to avoid maintaining yet another kernel
definition for future complications if I can. Can we get this module
built in by default?
I consider it a bug as the functionality was given before and
disappeared now, leaving our system unable to upgrade unless I write
some code around it.
Thanks.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Tue, 25 Sep 2018 23:37:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 32840 <at> debbugs.gnu.org (full text, mbox):
Hi Nils,
Nils Gillmann <gillmann <at> n0.is> writes:
> at taler we need shpchp as a module in the initrd.
>
> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
> you were able to just specify it for the initrd.
>
> With 4.18.9, this module became a compile-in/built-in (see linux
> commit log). I want to avoid maintaining yet another kernel
> definition for future complications if I can. Can we get this module
> built in by default?
Sure, that sounds sensible. I'll push a config update soon.
Thanks,
Mark
Reply sent
to
Mark H Weaver <mhw <at> netris.org>
:
You have taken responsibility.
(Wed, 26 Sep 2018 03:25:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Nils Gillmann <gillmann <at> n0.is>
:
bug acknowledged by developer.
(Wed, 26 Sep 2018 03:25:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 32840-done <at> debbugs.gnu.org (full text, mbox):
Nils Gillmann <gillmann <at> n0.is> writes:
> at taler we need shpchp as a module in the initrd.
>
> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
> you were able to just specify it for the initrd.
>
> With 4.18.9, this module became a compile-in/built-in (see linux
> commit log). I want to avoid maintaining yet another kernel
> definition for future complications if I can. Can we get this module
> built in by default?
Done in commit fe73352e8073ea0a0e6f6b5591f24395671998ab on master.
Closing this bug now, but please reopen if appropriate.
Thanks!
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Wed, 26 Sep 2018 06:22:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 32840-done <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> netris.org> writes:
> Nils Gillmann <gillmann <at> n0.is> writes:
>
>> at taler we need shpchp as a module in the initrd.
>>
>> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
>> you were able to just specify it for the initrd.
>>
>> With 4.18.9, this module became a compile-in/built-in (see linux
>> commit log). I want to avoid maintaining yet another kernel
>> definition for future complications if I can. Can we get this module
>> built in by default?
>
> Done in commit fe73352e8073ea0a0e6f6b5591f24395671998ab on master.
> Closing this bug now, but please reopen if appropriate.
I don’t understand why building it as a module is needed when upstream
decided to turn it into a built-in feature.
Could you please explain?
--
Ricardo
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Wed, 26 Sep 2018 16:27:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 32840 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus transcribed 808 bytes:
>
> Mark H Weaver <mhw <at> netris.org> writes:
>
> > Nils Gillmann <gillmann <at> n0.is> writes:
> >
> >> at taler we need shpchp as a module in the initrd.
> >>
> >> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
> >> you were able to just specify it for the initrd.
> >>
> >> With 4.18.9, this module became a compile-in/built-in (see linux
> >> commit log). I want to avoid maintaining yet another kernel
> >> definition for future complications if I can. Can we get this module
> >> built in by default?
> >
> > Done in commit fe73352e8073ea0a0e6f6b5591f24395671998ab on master.
> > Closing this bug now, but please reopen if appropriate.
Thanks! I'll get back if this didn't fix upgrading the server.
> I don’t understand why building it as a module is needed when upstream
> decided to turn it into a built-in feature.
>
> Could you please explain?
There are modules [M] and boolean y/n "builtins" in Linux. We don't need
to build it as a module now, since upstream changed it to be a builtin.
It is not covered by whatever selection we have in the kernel config as
builtins. Since the module disappeared, users of the module were left
with the choice to remove it and either build their own kernel variation
or ask for it as a feature.
I asked for it, since Taler wanted as little reliance on third-party
repositories as possible, no matter how reliable the repositories are.
> --
> Ricardo
>
>
>
>
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 17 Oct 2018 22:57:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Wed, 17 Oct 2018 23:00:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 32840 <at> debbugs.gnu.org (full text, mbox):
Hi Mark,
Mark H Weaver <mhw <at> netris.org> skribis:
> Nils Gillmann <gillmann <at> n0.is> writes:
>
>> at taler we need shpchp as a module in the initrd.
>>
>> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
>> you were able to just specify it for the initrd.
>>
>> With 4.18.9, this module became a compile-in/built-in (see linux
>> commit log). I want to avoid maintaining yet another kernel
>> definition for future complications if I can. Can we get this module
>> built in by default?
>
> Sure, that sounds sensible. I'll push a config update soon.
I’ve reopened the bug because I think we need the same change as in
fe73352e8073ea0a0e6f6b5591f24395671998ab for AArch64 (at least it
appears to be needed on the OverDrive 1000.)
Could you take a look?
(I’m not entirely sure about the workflow to get the updated config from
“make oldconfig”…)
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Thu, 18 Oct 2018 00:26:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 32840 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludovic,
ludo <at> gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> Nils Gillmann <gillmann <at> n0.is> writes:
>>
>>> at taler we need shpchp as a module in the initrd.
>>>
>>> Before version 4.18.x, shpchp was a module we've build in guix' linux-libre,
>>> you were able to just specify it for the initrd.
>>>
>>> With 4.18.9, this module became a compile-in/built-in (see linux
>>> commit log). I want to avoid maintaining yet another kernel
>>> definition for future complications if I can. Can we get this module
>>> built in by default?
>>
>> Sure, that sounds sensible. I'll push a config update soon.
>
> I’ve reopened the bug because I think we need the same change as in
> fe73352e8073ea0a0e6f6b5591f24395671998ab for AArch64 (at least it
> appears to be needed on the OverDrive 1000.)
>
> Could you take a look?
Sure. I've attached a proposed patch below. Would you like to try it
and push it to master if it works?
> (I’m not entirely sure about the workflow to get the updated config from
> “make oldconfig”…)
FYI, my current method is:
* Unpack the latest linux-libre source.
* Copy the existing kernel configuration to .config in the source dir.
* Manually edit .config with desired configuration change.
* Within "guix environment linux-libre" run:
ARCH=arm64 make oldconfig
More generally, ARCH should be set to the value returned by
'system->linux-architecture' in (gnu packages linux).
* Manually edit out some changes that are clearly irrelevant,
such the addition of a top comment saying which compiler I have in my
PATH.
Some day, I would prefer to have multiple smaller configuration files,
with a shared common configuration plus smaller architecture-specific
files, but we're not there yet.
Thanks,
Mark
[0001-gnu-linux-libre-Enable-SHPC-PCI-Hotplug-driver-on-AR.patch (text/x-patch, inline)]
From 41fdb333b05e300622c4c41aaced70fff2c6df7f Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw <at> netris.org>
Date: Wed, 17 Oct 2018 20:09:19 -0400
Subject: [PATCH] gnu: linux-libre: Enable SHPC PCI Hotplug driver on ARM64.
Fixes <https://bugs.gnu.org/32840> on ARM64.
* gnu/packages/aux-files/linux-libre/4.18-arm64.conf: Add
CONFIG_HOTPLUG_PCI_SHPC=y.
---
gnu/packages/aux-files/linux-libre/4.18-arm64.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/aux-files/linux-libre/4.18-arm64.conf b/gnu/packages/aux-files/linux-libre/4.18-arm64.conf
index ab30f51d2..64b14b52c 100644
--- a/gnu/packages/aux-files/linux-libre/4.18-arm64.conf
+++ b/gnu/packages/aux-files/linux-libre/4.18-arm64.conf
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/arm64 4.18.0-gnu Kernel Configuration
+# Linux/arm64 4.18.14-gnu Kernel Configuration
#
CONFIG_ARM64=y
CONFIG_64BIT=y
@@ -481,7 +481,7 @@ CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
CONFIG_HOTPLUG_PCI_CPCI=y
-# CONFIG_HOTPLUG_PCI_SHPC is not set
+CONFIG_HOTPLUG_PCI_SHPC=y
#
# PCI controller drivers
--
2.19.1
Information forwarded
to
bug-guix <at> gnu.org
:
bug#32840
; Package
guix
.
(Thu, 18 Oct 2018 22:18:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 32840 <at> debbugs.gnu.org (full text, mbox):
Hi Mark,
Mark H Weaver <mhw <at> netris.org> skribis:
> ludo <at> gnu.org (Ludovic Courtès) writes:
[...]
>> I’ve reopened the bug because I think we need the same change as in
>> fe73352e8073ea0a0e6f6b5591f24395671998ab for AArch64 (at least it
>> appears to be needed on the OverDrive 1000.)
>>
>> Could you take a look?
>
> Sure. I've attached a proposed patch below. Would you like to try it
> and push it to master if it works?
It does fix the problem for me so I’ve pushed it as
402e60859da609e95d16a04a253977da88f4077e.
>> (I’m not entirely sure about the workflow to get the updated config from
>> “make oldconfig”…)
>
> FYI, my current method is:
>
> * Unpack the latest linux-libre source.
> * Copy the existing kernel configuration to .config in the source dir.
> * Manually edit .config with desired configuration change.
> * Within "guix environment linux-libre" run:
>
> ARCH=arm64 make oldconfig
>
> More generally, ARCH should be set to the value returned by
> 'system->linux-architecture' in (gnu packages linux).
> * Manually edit out some changes that are clearly irrelevant,
> such the addition of a top comment saying which compiler I have in my
> PATH.
OK, thanks for explaining!
> Some day, I would prefer to have multiple smaller configuration files,
> with a shared common configuration plus smaller architecture-specific
> files, but we're not there yet.
Yeah…
Anyway I’m happy to say I have GuixSD running on the OverDrive 1000!
There were a few more shenanigans (the openSuSE kernel had a few things
set to “y” that we’re setting to “m”), but then it went smoothly.
Thanks!
Ludo’.
Added tag(s) fixed.
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Sun, 11 Nov 2018 17:34:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
32840 <at> debbugs.gnu.org and Nils Gillmann <gillmann <at> n0.is>
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Sun, 11 Nov 2018 17:34:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 10 Dec 2018 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.