linux-kernel - 3.14 x86 ACPI handover regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <541071DB.3010704@numascale.com>
Date:	Wed, 10 Sep 2014 23:44:27 +0800
From:	Daniel J Blueman <daniel@...ascale.com>
To:	Yinghai Lu <yinghai@...nel.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>
CC:	Dave Hansen <dave.hansen@...el.com>,
	Russell King <linux@....linux.org.uk>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Steffen Persvold <sp@...ascale.com>
Subject: 3.14 x86 ACPI handover regression

Kernels 3.14 and newer fail ACPI handover [1] on Supermicro H8QGL 
servers, invariant of BIOS version or settings, causing boot failure, 
confirmed across a bunch of servers.

Doing some bisect-fu, it turns out that reverting Yinghai's patch fixes 
the behaviour. Booting with Santosh's patch (5b6e529521d3, which Yinghai 
reverts) succeeds, but interestingly booting with the patch before 
Santosh's patch also succeeds, suggesting there's other interaction. 
Behaviour is stable at all places tested.

Any tips on how to proceed?

Thanks,
   Daniel

-- [1]

ACPI Error: Hardware did not enter ACPI mode (20131218/evxfevnt-113)
ACPI Warning: AcpiEnable failed (20131218/utxfinit-169)
ACPI: Unable to enable ACPI

-- [2]

commit 4ce7a8697cb795fda6bdf082c14743b4bcd551c3
Author: Yinghai Lu <yinghai@...nel.org>
Date:   Mon Jan 27 17:06:50 2014 -0800

     x86: revert wrong memblock current limit setting

     Dave reported big numa system booting is broken.

     It turns out that commit 5b6e529521d3 ("x86: memblock: set current 
limit
     to max low memory address") sets the limit to low wrongly.

     max_low_pfn_mapped is different from max_pfn_mapped.
     max_low_pfn_mapped is always under 4G.

     That will memblock_alloc_nid all go under 4G.

     Revert 5b6e529521d3 to fix a no-boot regression which was triggered by
     457ff1de2d24 ("lib/swiotlb.c: use memblock apis for early memory
     allocations").

     Signed-off-by: Yinghai Lu <yinghai@...nel.org>
     Reported-by: Dave Hansen <dave.hansen@...el.com>
     Acked-by: Santosh Shilimkar <santosh.shilimkar@...com>
     Cc: Russell King <linux@....linux.org.uk>
     Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
     Cc: Ingo Molnar <mingo@...e.hu>
     Cc: "H. Peter Anvin" <hpa@...or.com>
     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 2f59cce..f97fbe3 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -51,9 +51,9 @@ extern int devmem_is_allowed(unsigned long pagenr);
  extern unsigned long max_low_pfn_mapped;
  extern unsigned long max_pfn_mapped;

-static inline phys_addr_t get_max_low_mapped(void)
+static inline phys_addr_t get_max_mapped(void)
  {
-       return (phys_addr_t)max_low_pfn_mapped << PAGE_SHIFT;
+       return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
  }

  bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c967559..06853e6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1119,7 +1119,7 @@ void __init setup_arch(char **cmdline_p)

         setup_real_mode();

-       memblock_set_current_limit(get_max_low_mapped());
+       memblock_set_current_limit(get_max_mapped());
         dma_contiguous_reserve(0);

         /*
-- 
Daniel J Blueman
Principal Software Engineer, Numascale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/