Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61140 > unrolled thread

Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

Back to article view | Back to linux.debian.kernel

Contents

  Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-06-01 19:10 +0200
    Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Riku Voipio <riku.voipio@iki.fi> - 2018-06-04 13:10 +0200
      Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-06-04 17:40 +0200
        Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ben Hutchings <ben@decadent.org.uk> - 2018-06-05 03:20 +0200
          Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ian Campbell <ijc@debian.org> - 2018-06-05 09:40 +0200
            Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-06-08 21:40 +0200
              Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ian Campbell <ijc@debian.org> - 2018-06-09 14:20 +0200
                Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-06-13 21:30 +0200
                  Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ian Campbell <ijc@debian.org> - 2018-06-14 11:10 +0200
                    Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Riku Voipio <riku.voipio@iki.fi> - 2018-08-06 16:40 +0200
                      Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-08-07 00:10 +0200
    Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-01 01:00 +0200
      Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ian Campbell <ijc@debian.org> - 2018-09-02 10:00 +0200
    Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-01 02:00 +0200
      Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ben Hutchings <ben@decadent.org.uk> - 2018-09-04 19:30 +0200
        Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-04 20:50 +0200
          Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Riku Voipio <riku.voipio@iki.fi> - 2018-09-05 08:50 +0200
          Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ben Hutchings <ben@decadent.org.uk> - 2018-09-06 22:30 +0200
    Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-20 22:00 +0200
      Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-21 17:40 +0200
        Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Ben Hutchings <ben@decadent.org.uk> - 2018-09-22 01:30 +0200
          Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers. Geoff Levand <geoff@infradead.org> - 2018-09-24 19:20 +0200

Page 1 of 2  [1] 2  Next page →

#61140 — Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.

[Multipart message — attachments visible in raw view] — view raw

X-Debbugs-Cc: geoff@infradead.org, Riku Voipio <riku.voipio@linaro.org>
Source: linux
Severity: normal
Tags: patch buster

Attached patches enable kernel features for newer ARM64 servers.

o Change CONFIG_ACPI_NFIT=y to CONFIG_ACPI_NFIT=m.
o Enable CONFIG_SCHED_SMT for hyperthreading processors.
o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
o Enable a number of ACPI options likely to be available on servers.
o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.16.12 (SMP w/224 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[toc] | [next] | [standalone]

#61146

On Fri, Jun 01, 2018 at 10:07:57AM -0700, Geoff Levand wrote:
> Source: linux
> Severity: normal
> Tags: patch buster
> 
> Attached patches enable kernel features for newer ARM64 servers.

Thanks, I've been looking into updating these.
 
> o Change CONFIG_ACPI_NFIT=y to CONFIG_ACPI_NFIT=m.
> o Enable CONFIG_SCHED_SMT for hyperthreading processors.
> o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
> o Enable a number of ACPI options likely to be available on servers.
> o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.

ACPI_APEI breaks HP m400, the xgene moonshot:

https://bugzilla.redhat.com/show_bug.cgi?id=1574718
 
The rest of options are generally fine. Wish more of these were modules tho.
If we ok with telling M400 users to setting kernel command line of ghes.disable=1,
we can enable APEI as well.

>   0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
>   0002-arm64-Updates-for-ACPI-servers.patch
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 4.16.12 (SMP w/224 CPU cores)

Cheeky. I take that means Debian kernel works well on you plaform.

> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

> >From 45de8904c961d98f48f61a87198579a90daa61f9 Mon Sep 17 00:00:00 2001
> From: Geoff Levand <geoff@infradead.org>
> Date: Thu, 31 May 2018 17:38:38 -0700
> Subject: [PATCH 1/4] [arm64] Use default of CONFIG_ACPI_NFIT=m
> 
> Commit ed497f3cb706d0e0f63844b064d9ebbf6f33b052 (Add server and 96boards options)
> added an arm64 specific CONFIG_ACPI_NFIT=y, overriding the default of =m, but the
> commit message mentions nothing about why this was done.
> 
> Remove the arm64 specific setting and use the default of module build.
> 
> Cc: Riku Voipio <riku.voipio@linaro.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
>  debian/config/arm64/config | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/debian/config/arm64/config b/debian/config/arm64/config
> index 4d862989014c..2cbdc9092de1 100644
> --- a/debian/config/arm64/config
> +++ b/debian/config/arm64/config
> @@ -68,11 +68,6 @@ CONFIG_ARCH_XGENE=y
>  CONFIG_ACPI=y
>  CONFIG_ACPI_NUMA=y
>  
> -##
> -## file: drivers/acpi/nfit/Kconfig
> -##
> -CONFIG_ACPI_NFIT=y
> -
>  ##
>  ## file: drivers/ata/Kconfig
>  ##
> -- 
> 2.14.1
> 

> >From 60439ed76d7c9660285d8805d40d35a84de218d3 Mon Sep 17 00:00:00 2001
> From: Geoff Levand <geoff@infradead.org>
> Date: Thu, 31 May 2018 17:38:38 -0700
> Subject: [PATCH 2/4] [arm64] Updates for ACPI servers
> 
> o Enable CONFIG_SCHED_SMT for hyperthreading processors.
> o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
> o Enable a number of ACPI options likely to be available on servers.
> o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.
> 
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
>  debian/config/arm64/config | 29 ++++++++++++++++++++++++-----
>  1 file changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/debian/config/arm64/config b/debian/config/arm64/config
> index 2cbdc9092de1..ed40c33ce47d 100644
> --- a/debian/config/arm64/config
> +++ b/debian/config/arm64/config
> @@ -9,6 +9,7 @@ CONFIG_ARM64_ERRATUM_834220=y
>  CONFIG_ARM64_VA_BITS_48=y
>  ## end choice
>  CONFIG_SCHED_MC=y
> +CONFIG_SCHED_SMT=y
>  CONFIG_NR_CPUS=256
>  CONFIG_NUMA=y
>  CONFIG_SECCOMP=y
> @@ -24,6 +25,7 @@ CONFIG_RANDOMIZE_BASE=y
>  CONFIG_RANDOMIZE_MODULE_REGION_FULL=y
>  CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
>  CONFIG_COMPAT=y
> +CONFIG_ARM64_LSE_ATOMICS=y
>  
>  ##
>  ## file: arch/arm64/crypto/Kconfig
> @@ -67,6 +69,21 @@ CONFIG_ARCH_XGENE=y
>  ##
>  CONFIG_ACPI=y
>  CONFIG_ACPI_NUMA=y
> +CONFIG_ACPI_PCI_SLOT=y
> +CONFIG_ACPI_HED=y
> +CONFIG_ACPI_BGRT=y
> +CONFIG_ACPI_WATCHDOG=y
> +CONFIG_ACPI_CONFIGFS=m
> +
> +##
> +## file: drivers/acpi/apei/Kconfig
> +##
> +CONFIG_ACPI_APEI=y
> +CONFIG_ACPI_APEI_GHES=y
> +CONFIG_ACPI_APEI_PCIEAER=y
> +CONFIG_ACPI_APEI_SEA=y
> +CONFIG_ACPI_APEI_MEMORY_FAILURE=y
> +CONFIG_ACPI_APEI_EINJ=m
>  
>  ##
>  ## file: drivers/ata/Kconfig
> @@ -212,6 +229,12 @@ CONFIG_EXTCON_USB_GPIO=m
>  ##
>  CONFIG_RASPBERRYPI_FIRMWARE=y
>  
> +##
> +## file: drivers/firmware/efi/Kconfig
> +##
> +CONFIG_UEFI_CPER=y
> +CONFIG_UEFI_CPER_ARM=y
> +
>  ##
>  ## file: drivers/gpio/Kconfig
>  ##
> @@ -1074,6 +1097,7 @@ CONFIG_VIRTIO_MMIO=m
>  ## file: drivers/watchdog/Kconfig
>  ##
>  CONFIG_GPIO_WATCHDOG=m
> +CONFIG_WDAT_WDT=m
>  CONFIG_ARM_SP805_WATCHDOG=m
>  CONFIG_ARM_SBSA_WATCHDOG=m
>  CONFIG_DW_WATCHDOG=m
> @@ -1084,11 +1108,6 @@ CONFIG_MESON_GXBB_WATCHDOG=m
>  CONFIG_MESON_WATCHDOG=m
>  CONFIG_BCM2835_WDT=m
>  
> -##
> -## file: fs/pstore/Kconfig
> -##
> -CONFIG_PSTORE=y
> -
>  ##
>  ## file: mm/Kconfig
>  ##
> -- 
> 2.14.1
> 

[toc] | [prev] | [next] | [standalone]

#61147

On 06/04/2018 03:51 AM, Riku Voipio wrote:
> On Fri, Jun 01, 2018 at 10:07:57AM -0700, Geoff Levand wrote:

>> o Change CONFIG_ACPI_NFIT=y to CONFIG_ACPI_NFIT=m.
>> o Enable CONFIG_SCHED_SMT for hyperthreading processors.
>> o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
>> o Enable a number of ACPI options likely to be available on servers.
>> o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.
> 
> ACPI_APEI breaks HP m400, the xgene moonshot:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1574718
>  
> The rest of options are generally fine. Wish more of these were modules tho.
> If we ok with telling M400 users to setting kernel command line of ghes.disable=1,
> we can enable APEI as well.

I think the hardware error logging/reporting features ACPI_APEI allows
is desired for servers.  The M400 problem is a problem with its firmware.
I don't think we should hold everyone else back because of one platform
with a known problem and relatively straight forward fix. M400 users would
in general need to work around the problem with kernels from other
sources/distros.  So, I think it OK to require M400 users to add a
command line fix.

>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing')
>> Architecture: arm64 (aarch64)
>>
>> Kernel: Linux 4.16.12 (SMP w/224 CPU cores)
> 
> Cheeky. I take that means Debian kernel works well on you plaform.

Seems to be working good with the kernel config updates.

[toc] | [prev] | [next] | [standalone]

#61148

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2018-06-04 at 08:29 -0700, Geoff Levand wrote:
> On 06/04/2018 03:51 AM, Riku Voipio wrote:
> > On Fri, Jun 01, 2018 at 10:07:57AM -0700, Geoff Levand wrote:
> > > o Change CONFIG_ACPI_NFIT=y to CONFIG_ACPI_NFIT=m.
> > > o Enable CONFIG_SCHED_SMT for hyperthreading processors.
> > > o Enable CONFIG_ARM64_LSE_ATOMICS for v8.1 processors.
> > > o Enable a number of ACPI options likely to be available on servers.
> > > o CONFIG_ACPI_APEI selects PSTORE, so remove the arm64 specific setting.
> > 
> > ACPI_APEI breaks HP m400, the xgene moonshot:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1574718
> >  
> > The rest of options are generally fine. Wish more of these were modules tho.
> > If we ok with telling M400 users to setting kernel command line of ghes.disable=1,
> > we can enable APEI as well.
> 
> I think the hardware error logging/reporting features ACPI_APEI allows
> is desired for servers.  The M400 problem is a problem with its firmware.
> I don't think we should hold everyone else back because of one platform
> with a known problem and relatively straight forward fix. M400 users would
> in general need to work around the problem with kernels from other
> sources/distros.  So, I think it OK to require M400 users to add a
> command line fix.

I don't think it's OK to cause a regression like this.  Since this is
problem affects a specific known platform, the driver ought to
recognise it and disable itself automatically.

Ben.

> > > -- System Information:
> > > Debian Release: buster/sid
> > >   APT prefers testing
> > >   APT policy: (500, 'testing')
> > > Architecture: arm64 (aarch64)
> > > 
> > > Kernel: Linux 4.16.12 (SMP w/224 CPU cores)
> > 
> > Cheeky. I take that means Debian kernel works well on you plaform.
> 
> Seems to be working good with the kernel config updates.
> 
-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

[toc] | [prev] | [next] | [standalone]

#61151

On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:

> I don't think it's OK to cause a regression like this.  Since this is
> problem affects a specific known platform, the driver ought to
> recognise it and disable itself automatically.

Indeed, while the Fedora bug upthread claims such a patch wouldn't be
upstreamable, AFAIK it is not uncommon to have such quirks for broken
firmware based upon DMI identifiers or similar.

Ian.

[toc] | [prev] | [next] | [standalone]

#61172

[Multipart message — attachments visible in raw view] — view raw

On 06/05/2018 12:28 AM, Ian Campbell wrote:
> On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> 
>> I don't think it's OK to cause a regression like this.  Since this is
>> problem affects a specific known platform, the driver ought to
>> recognise it and disable itself automatically.
> 
> Indeed, while the Fedora bug upthread claims such a patch wouldn't be
> upstreamable, AFAIK it is not uncommon to have such quirks for broken
> firmware based upon DMI identifiers or similar.

Just to mention it, Mark Salter submitted one of the work-around patches
for the m400 firmware.  The reply from the ACPI maintainer wasn't very
encouraging. See:

  https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)

CONFIG_ACPI_APEI allows for automated error reporting, so it is something
that is very desirable for unattended servers in a production environment.
Mark sent me a minimal patch that allows CONFIG_ACPI_APEI to work on m400.
I've attached a patch that puts his patch into the kernel patch series.  

  arm64-Add-fix-for-broken-HPE-moonshot-ACPI-APEI-supp.patch

Is this an acceptable solution?

[toc] | [prev] | [next] | [standalone]

#61174

On Fri, 2018-06-08 at 12:33 -0700, Geoff Levand wrote:
> On 06/05/2018 12:28 AM, Ian Campbell wrote:
> > On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote:
> > 
> >> I don't think it's OK to cause a regression like this.  Since this
> is
> >> problem affects a specific known platform, the driver ought to
> >> recognise it and disable itself automatically.
> > 
> > Indeed, while the Fedora bug upthread claims such a patch wouldn't
> be
> > upstreamable, AFAIK it is not uncommon to have such quirks for
> broken
> > firmware based upon DMI identifiers or similar.
> 
> Just to mention it, Mark Salter submitted one of the work-around
> patches
> for the m400 firmware.  The reply from the ACPI maintainer wasn't
> very
> encouraging. See:
> 
>   https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression
> related to X-Gene UARTs)

He said:
> I'm not convinced that making changes to the core ACPI device
> enumeration code in order to cover up for firmware bugs is the right
> approach.

That response seems fair, changing the core ACPI code at that point
indeed doesn't seem correct, especially with a one-off special case
(most such things are table and callback driven).

I think this is probably something for the arch (or perhaps platform)
code to deal with. See for example all the various platform quirks in
arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
disable features.

Although I would also note that there seems to be ~200 existing DMI
matches under drivers/acpi, just not in the core device enumeration
code, I don't read Rafael's response as ruling out a fix somewhere in
the ACPI code, just not in the enumeration paths as presented there.

> CONFIG_ACPI_APEI allows for automated error reporting, so it is something
> that is very desirable[...]

I don't think anyone is disputing that, but there are tradeoff to be
made here.

> Is this an acceptable solution?

It should be sent upstream. It at least seems to be a more targetted
fix than the one above.

Has anyone tried to detect this "slave device attached to itself"
situation in a more generic way? Perhaps that would also be worth
discussing with upstream too.

It's an expected consequence of ARM & co's push towards the ACPI model
which effectively requires that the (upstream) kernel must deal with
buggy firmware in the field, just like on x86.

I don't think it is right that the distros should have to carry and
support fixes for this sort of thing, it should be done upstream or by
vendors fixing firmware (and I don't hold out much hope for the latter
if x86 is any indication, especially for a platform now as old as the
m400).

Ian.

[toc] | [prev] | [next] | [standalone]

#61200

On 06/09/2018 05:15 AM, Ian Campbell wrote:

> I think this is probably something for the arch (or perhaps platform)
> code to deal with. See for example all the various platform quirks in
> arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> disable features.

I followed your advice and created a fix in the arm64 acpi init
code of arch/arm64/kernel/acpi.c.  Here's the submission:

  https://marc.info/?l=linux-acpi&m=152891415600796&w=2
  https://www.spinics.net/lists/linux-acpi/msg82887.html

[toc] | [prev] | [next] | [standalone]

#61209

On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> On 06/09/2018 05:15 AM, Ian Campbell wrote:
> 
> > I think this is probably something for the arch (or perhaps
> > platform)
> > code to deal with. See for example all the various platform quirks
> > in
> > arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> > disable features.
> 
> I followed your advice and created a fix in the arm64 acpi init
> code of arch/arm64/kernel/acpi.c.  Here's the submission:
> 
>   https://marc.info/?l=linux-acpi&m=152891415600796&w=2
>   https://www.spinics.net/lists/linux-acpi/msg82887.html

Thanks!

[toc] | [prev] | [next] | [standalone]

#61747

On Thu, Jun 14, 2018 at 09:58:56AM +0100, Ian Campbell wrote:
> On Wed, 2018-06-13 at 12:25 -0700, Geoff Levand wrote:
> > On 06/09/2018 05:15 AM, Ian Campbell wrote:
> > 
> > > I think this is probably something for the arch (or perhaps
> > > platform)
> > > code to deal with. See for example all the various platform quirks
> > > in
> > > arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or
> > > disable features.
> > 
> > I followed your advice and created a fix in the arm64 acpi init
> > code of arch/arm64/kernel/acpi.c.  Here's the submission:
> > 
> >   https://marc.info/?l=linux-acpi&m=152891415600796&w=2
> >   https://www.spinics.net/lists/linux-acpi/msg82887.html
> 
> Thanks!

Thanks indeed - unfortunately we seem to be endind up in 
a dead end with the upstream developers:

https://www.spinics.net/lists/arm-kernel/msg669674.html

Considering HPE didn't actually release the firmware, I think we
can go with just enabling the options and documenting the command line
option.

Riku

[toc] | [prev] | [next] | [standalone]

#61755

Hi All,

On 08/06/2018 06:29 AM, Riku Voipio wrote:
> Thanks indeed - unfortunately we seem to be endind up in 
> a dead end with the upstream developers:
> 
> https://www.spinics.net/lists/arm-kernel/msg669674.html
> 
> Considering HPE didn't actually release the firmware, I think we
> can go with just enabling the options and documenting the command line
> option.

Just to mention it, I went through and verified the info James Morse had
posted regarding m400 System ROM releases [1] and came to the same
conclusion; the latest official release of m400 System ROM did not support
ACPI HEST/AEPI.

[1]  https://www.spinics.net/lists/arm-kernel/msg670446.html

-Geoff

[toc] | [prev] | [next] | [standalone]

#61963

[Multipart message — attachments visible in raw view] — view raw

Hi,

I've rebased my two kernel config patches, attached, to the latest
v4.17.17-1 buster kernel.  These patches enable kernel features for
newer ARM64 servers. 

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch

The issue that Riku brought up of how to support HPE m400 moonshot
systems when ACPI_APEI is enabled has been resolved on the
arm-kernel ML [1].  In summary, the latest released m400 firmware
did not support APEI, and so no special work-around or kernel quirk
support is needed.

With the resolution of that issue I feel these patches are ready to
apply.  Please consider.

[1] https://www.spinics.net/lists/arm-kernel/msg670446.html (efi: add contents of LinuxExtraArgs EFI var to command line)

-Geoff
 

[toc] | [prev] | [next] | [standalone]

#61967

On Fri, 2018-08-31 at 14:52 -0700, Geoff Levand wrote:
> In summary, the latest released m400 firmware
> did not support APEI, and so no special work-around or kernel quirk
> support is needed.

That seems reasonable enough to me, no reason to support random back-
channel (un)released firmware. Ben?

Ian.

[toc] | [prev] | [next] | [standalone]

#61964

[Multipart message — attachments visible in raw view] — view raw

Hi,

I've rebased my two kernel config patches, attached, to the latest
v4.17.17-1 buster kernel.  These patches enable kernel features for
newer ARM64 servers. 

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch

The issue that Riku brought up of how to support HPE m400 moonshot
systems when ACPI_APEI is enabled has been resolved on the
arm-kernel ML [1].  In summary, the latest released m400 firmware
did not support APEI, and so no special work-around or kernel quirk
support is needed.

With the resolution of that issue I feel these patches are ready to
apply.  Please consider.

[1] https://www.spinics.net/lists/arm-kernel/msg670446.html (efi: add contents of LinuxExtraArgs EFI var to command line)

-Geoff
 

[toc] | [prev] | [next] | [standalone]

#61988

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2018-08-31 at 15:42 -0700, Geoff Levand wrote:
> Hi,
> 
> I've rebased my two kernel config patches, attached, to the latest
> v4.17.17-1 buster kernel.  These patches enable kernel features for
> newer ARM64 servers. 
> 
>   0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
>   0002-arm64-Updates-for-ACPI-servers.patch
> 
> The issue that Riku brought up of how to support HPE m400 moonshot
> systems when ACPI_APEI is enabled has been resolved on the
> arm-kernel ML [1].  In summary, the latest released m400 firmware
> did not support APEI, and so no special work-around or kernel quirk
> support is needed.
>
> With the resolution of that issue I feel these patches are ready to
> apply.  Please consider.

Is it resolved? Graeme Gregory claimed
(https://www.spinics.net/lists/arm-kernel/msg669946.html) that "most
people are running the firmware provided from HPe support but was never
put on release site".

Ben.

> [1] https://www.spinics.net/lists/arm-kernel/msg670446.html (efi: add
> contents of LinuxExtraArgs EFI var to command line)
> 
> -Geoff
>  
> 
-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[toc] | [prev] | [next] | [standalone]

#61989

Hi Ben,

On 09/04/2018 10:25 AM, Ben Hutchings wrote:
> On Fri, 2018-08-31 at 15:42 -0700, Geoff Levand wrote:
>> I've rebased my two kernel config patches, attached, to the latest
>> v4.17.17-1 buster kernel.  These patches enable kernel features for
>> newer ARM64 servers. 
>>
>>   0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
>>   0002-arm64-Updates-for-ACPI-servers.patch
>>
>> The issue that Riku brought up of how to support HPE m400 moonshot
>> systems when ACPI_APEI is enabled has been resolved on the
>> arm-kernel ML [1].  In summary, the latest released m400 firmware
>> did not support APEI, and so no special work-around or kernel quirk
>> support is needed.
>>
>> With the resolution of that issue I feel these patches are ready to
>> apply.  Please consider.
> 
> Is it resolved? Graeme Gregory claimed
> (https://www.spinics.net/lists/arm-kernel/msg669946.html) that "most
> people are running the firmware provided from HPe support but was never
> put on release site".

I took that as just a comment on the discussion which it follows, which
seemed to end with 'distro maintainers deciding how to handle the problem'
and then Riku recommending to document the need in Debian for a m400
specific command line option.

Based on the several mail list discussions that came out of this I
think it very unlikely we'll get an upstream kernel fix.  My appeal
directly to Will Deacon for guidance even went unanswered.

At this point I feel our choices are:

1) Merge the kernel config patch I proposed and add a comment to
the arm64 Installation Guide about the need to add 'hest_disable=1'
to the kernel command line for the m400.

2) Merge the kernel config patch and the
'Add fix for broken HPE moonshot ACPI-APEI support' patch I proposed.

3) Remove the CONFIG_ACPI_APEI options from the the kernel config patch
I proposed and merge that.

I prefer #2, which would get us ACPI_APEI support and a seamless
install for m400 users.

If there is anything you recommend I could try it.  I'm not apposed
to any solution.  I just want to get the kernel config updated so
Buster better supports newer systems.

-Geoff

[toc] | [prev] | [next] | [standalone]

#61991

On Tue, Sep 04, 2018 at 11:43:07AM -0700, Geoff Levand wrote:
> > Is it resolved? Graeme Gregory claimed
> > (https://www.spinics.net/lists/arm-kernel/msg669946.html) that "most
> > people are running the firmware provided from HPe support but was never
> > put on release site".
> 
> I took that as just a comment on the discussion which it follows, which
> seemed to end with 'distro maintainers deciding how to handle the problem'
> and then Riku recommending to document the need in Debian for a m400
> specific command line option.

Generally I'm just dissapointed the way upstream discussion turned out,
and willing to throw hands in the air.

Given it seems ACPI only really worked on moonshot with an unofficial
firmware, out-of-box working isn't that meaningful anyways.

> At this point I feel our choices are:
> 
> 1) Merge the kernel config patch I proposed and add a comment to
> the arm64 Installation Guide about the need to add 'hest_disable=1'
> to the kernel command line for the m400.

I think that people capable of running an unnofficial firmware are also
capable of setting and kernel command line option.

> 2) Merge the kernel config patch and the
> 'Add fix for broken HPE moonshot ACPI-APEI support' patch I proposed.

Personally I'd prefer to avoid accumating delta against upstream, but
Geoff's patch is quite low-impact.

> 3) Remove the CONFIG_ACPI_APEI options from the the kernel config patch
> I proposed and merge that.

We should really enable APEI support for the benefit of platforms that
do support it.

Riku

[toc] | [prev] | [next] | [standalone]

#62015

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2018-09-04 at 11:43 -0700, Geoff Levand wrote:
[...]
> At this point I feel our choices are:
> 
> 1) Merge the kernel config patch I proposed and add a comment to
> the arm64 Installation Guide about the need to add 'hest_disable=1'
> to the kernel command line for the m400.
> 
> 2) Merge the kernel config patch and the
> 'Add fix for broken HPE moonshot ACPI-APEI support' patch I proposed.
> 
> 3) Remove the CONFIG_ACPI_APEI options from the the kernel config patch
> I proposed and merge that.
> 
> I prefer #2, which would get us ACPI_APEI support and a seamless
> install for m400 users.
> 
> If there is anything you recommend I could try it.  I'm not apposed
> to any solution.  I just want to get the kernel config updated so
> Buster better supports newer systems.

I also favour #2.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

[toc] | [prev] | [next] | [standalone]

#62202

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,

Attached are the two kernel config patches rebased to the latest v4.18.6-1
Buster kernel. 

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch

Do you plan to merge these?  If there is anything I can do to make
things easier for you please let me know.

-Geoff

[toc] | [prev] | [next] | [standalone]

#62207

[Multipart message — attachments visible in raw view] — view raw

On 09/20/2018 12:49 PM, Geoff Levand wrote:
> Attached are the two kernel config patches rebased to the latest v4.18.6-1
> Buster kernel. 

Forgot to include the rebased m400 fixup patch.

  0001-arm64-Use-default-of-CONFIG_ACPI_NFIT-m.patch
  0002-arm64-Updates-for-ACPI-servers.patch
  0003-arm64-Add-fixup-for-HPE-m400-APEI-firmware-problems.patch

-Geoff

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web