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

2018-06-08 Thread Geoff Levand
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?
>From e2bbf7bd8ef0231dcaa440a5baa8722a11634f75 Mon Sep 17 00:00:00 2001
From: Geoff Levand 
Date: Fri, 8 Jun 2018 10:52:29 -0700
Subject: [PATCH] [arm64] Add fix for broken HPE moonshot ACPI-APEI support

Signed-off-by: Geoff Levand 
---
 ...4-Ignore-broken-HPE-moonshot-APEI-support.patch | 39 ++
 debian/patches/series  |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/bugfix/arm64/ACPI-APEI-arm64-Ignore-broken-HPE-moonshot-APEI-support.patch

diff --git a/debian/patches/bugfix/arm64/ACPI-APEI-arm64-Ignore-broken-HPE-moonshot-APEI-support.patch b/debian/patches/bugfix/arm64/ACPI-APEI-arm64-Ignore-broken-HPE-moonshot-APEI-support.patch
new file mode 100644
index ..ca7a7bf67258
--- /dev/null
+++ b/debian/patches/bugfix/arm64/ACPI-APEI-arm64-Ignore-broken-HPE-moonshot-APEI-support.patch
@@ -0,0 +1,39 @@
+From 2c4be2497e1cdbeaeee2decd9f85bfd9926d0321 Mon Sep 17 00:00:00 2001
+From: Mark Salter 
+Date: Tue, 27 Feb 2018 00:21:23 -0500
+Subject: [PATCH] ACPI: APEI: arm64: Ignore broken HPE moonshot APEI support
+
+The aarch64 HP moonshot platforms have a firmware bug which causes a
+spurious fatal memory error via APEI at boot time. This platform is no
+longer supported and no further firmware updates are expected. This is
+a downstream-only hack to avoid the problem by bailing out of HEST
+table probing if we detect a moonshot HEST table.
+
+Signed-off-by: Mark Salter 
+Signed-off-by: Geoff Levand 
+---
+ drivers/acpi/apei/hest.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
+index 9cb74115a43d..9305daabe24c 100644
+--- a/drivers/acpi/apei/hest.c
 b/drivers/acpi/apei/hest.c
+@@ -89,6 +89,14 @@ int apei_hest_parse(apei_hest_func_t func, void *data)
+ 	if (hest_disable || !hest_tab)
+ 		return -EINVAL;
+ 
++#ifdef CONFIG_ARM64
++	/* Ignore broken firmware */
++	if (!strncmp(hest_tab->header.oem_id, "HPE   ", 6) &&
++	!strncmp(hest_tab->header.oem_table_id, "ProLiant", 8) &&
++	MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM)
++		return -EINVAL;
++#endif
++
+ 	hest_hdr = (struct acpi_hest_header *)(hest_tab + 1);
+ 	for (i = 0; i < hest_tab->error_source_count; i++) {
+ 		len = hest_esrc_len(hest_hdr);
+-- 
+2.14.1
+
diff --git a/debian/patches/series b/debian/patches/series
index cb1d40074141..d77fa2bf4faf 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -68,6 +68,7 @@ bugfix/x86/perf-tools-fix-unwind-build-on-i386.patch
 bugfix/sh/sh-boot-do-not-use-hyphen-in-exported-variable-name.patch
 bugfix/x86/mmap-remember-the-map_fixed-flag-as-vm_fixed.patch
 bugfix/x86/mmap-add-an-exception-to-the-stack-gap-for-hotspot-jvm.patch
+bugfix/arm64/ACPI-APEI-arm64-Ignore-broken-HPE-moonshot-APEI-support.patch
 
 # Arch features
 features/mips/MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch
-- 
2.14.1



Re: Scheduling 9.5

2018-06-08 Thread Laura Arjona Reina



El 8 de junio de 2018 19:51:18 CEST, "Adam D. Barratt" 
 escribió:
>[Cc += debian-kernel]
>
>On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote:
>> On 15037 March 1977, Jonathan Wiltshire wrote:
>> >  - May 26th (meaning freeze this coming weekend, which might be a
>> > big
>> >  ask)
>> 
>> No.
>> 
>> >  - Jun 2nd (which may require an unusual SRM)
>> 
>> Possible.
>> 
>> >  - Jun 9th (getting quite a way out of cadence, but maybe that
>> > can't be
>> >    helped)
>> 
>> Possible.
>
>We're past any of the above by now, and while looking through the to-do
>
>list for the final jessie point release, I noticed that we currently
>have some packages in opu with versions higher than stable.
>
>We can either accept the packages and put up with the situation for a
>short while, or do 9.5 before 8.11. In practical terms, that would
>likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend.
>How do people feel about that?
>

Ok for publicity.

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail



Re: Scheduling 9.5

2018-06-08 Thread Steve McIntyre
On Fri, Jun 08, 2018 at 06:51:18PM +0100, Adam Barratt wrote:
>[Cc += debian-kernel]
>
>On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote:
>> On 15037 March 1977, Jonathan Wiltshire wrote:
>> >  - May 26th (meaning freeze this coming weekend, which might be a
>> > big
>> >  ask)
>> 
>> No.
>> 
>> >  - Jun 2nd (which may require an unusual SRM)
>> 
>> Possible.
>> 
>> >  - Jun 9th (getting quite a way out of cadence, but maybe that
>> > can't be
>> >    helped)
>> 
>> Possible.
>
>We're past any of the above by now, and while looking through the to-do 
>list for the final jessie point release, I noticed that we currently
>have some packages in opu with versions higher than stable.
>
>We can either accept the packages and put up with the situation for a
>short while, or do 9.5 before 8.11. In practical terms, that would
>likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend.
>How do people feel about that?

That works ok for me.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess



Re: Scheduling 9.5

2018-06-08 Thread Adam D. Barratt
[Cc += debian-kernel]

On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote:
> On 15037 March 1977, Jonathan Wiltshire wrote:
> >  - May 26th (meaning freeze this coming weekend, which might be a
> > big
> >  ask)
> 
> No.
> 
> >  - Jun 2nd (which may require an unusual SRM)
> 
> Possible.
> 
> >  - Jun 9th (getting quite a way out of cadence, but maybe that
> > can't be
> >    helped)
> 
> Possible.

We're past any of the above by now, and while looking through the to-do 
list for the final jessie point release, I noticed that we currently
have some packages in opu with versions higher than stable.

We can either accept the packages and put up with the situation for a
short while, or do 9.5 before 8.11. In practical terms, that would
likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend.
How do people feel about that?

Cheers,

Adam



Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

2018-06-08 Thread Chris Nospam
Meanwhile my Debian Testing systems have (per default) upgraded to libbsd
0.9.1 (and kernel 4.16.0-2). Unfortunaetly, this does not fix the problem
(long ssdm start) under virtualization by kvm, although according to #898088
libvirt 0.9.0-1 should have alredy fixed this.

On productive bare metal I cannot say anything, as I have set kernel 4.16 on
hold by apt.

Thx, Chris