ILK ACPI boot-up problem on HP 8100 SFF, bisected

ILK ACPI boot-up problem on HP 8100 SFF, bisected

[Tomi Sarvela]

Hello there,

We have couple of Iron Lake machines here, and one started hanging around Christmas in early boot on ACPI initialization. Dmesg below, full dmesgs available on request.

Exact model of the machine is HP Compaq 8100 Elite Small Form Factor PC. BIOS update from 2010 to 2011 (newest) didn't change anything.
HP Elite laptop (ILK m540) or Dell SFF PC (ILK 650) don't have this particular problem.

I've bisected the problem to the following commit:

----
commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Wed Dec 14 15:04:25 2016 +0800

    ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
    
    ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
----

The affected machine is a testhost and readily available for any patches that might help pinpoint this bug.

If you need any more information, you can contact me directly to this address.

Best regards,

Tomi Sarvela

Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



Bad kernel hard hangs to the point:

[    0.851020] ACPI: Added _OSI(Module Device)
[    0.855257] ACPI: Added _OSI(Processor Device)
[    0.859753] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.864509] ACPI: Added _OSI(Processor Aggregator Device)
[    0.888923] ACPI: Dynamic OEM Table Load:
[    0.893050] ACPI: SSDT 0xFFFF880212313A78 0003BA (v01 COMPAQ CPU_TM2  00000001 MSFT 0100000E)

Good kernel looks like this:

[    0.216085] ACPI: Added _OSI(Module Device)
[    0.216087] ACPI: Added _OSI(Processor Device)
[    0.216088] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.216089] ACPI: Added _OSI(Processor Aggregator Device)
[    0.217988] ACPI: Dynamic OEM Table Load:
[    0.217993] ACPI: SSDT 0xFFFF880211DE2400 0003BA (v01 COMPAQ CPU_TM2  00000001 MSFT 0100000E)
[    0.218238] ACPI: Dynamic OEM Table Load:
[    0.218241] ACPI: SSDT 0xFFFF880211DE2800 0003D8 (v01 COMPAQ CST      00000001 MSFT 0100000E)
[    0.218693] ACPI: Interpreter enabled
[    0.218708] ACPI: (supports S0 S3 S4 S5)
[    0.218709] ACPI: Using IOAPIC for interrupt routing
[    0.218726] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.221751] acpi LNXCPU:00: Invalid PBLK length [7]
[    0.221758] acpi LNXCPU:01: Invalid PBLK length [7]
[    0.221763] acpi LNXCPU:02: Invalid PBLK length [7]
[    0.221768] acpi LNXCPU:03: Invalid PBLK length [7]
[    0.221898] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.221903] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.221906] ACPI BIOS Error (bug): \_SB_.PCI0._OSC: Excess arguments - ASL declared 5, ACPI requires 4 (20150930/nsarguments-189)
[    0.221938] ACPI Error: [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS (20150930/dsfield-211)
[    0.221942] ACPI Error: Method parse/execution failed [\_SB.PCI0._OSC] (Node ffff8802130b1668), AE_ALREADY_EXISTS (20150930/psparse-542)
[    0.221948] acpi PNP0A08:00: _OSC failed (AE_ALREADY_EXISTS); disabling ASPM
[    0.222162] PCI host bridge to bus 0000:00

Re: ILK ACPI boot-up problem on HP 8100 SFF, bisected

[Rafael J. Wysocki]

Hi,

On Mon, Jan 9, 2017 at 5:01 PM, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
> Hello there,
>
> We have couple of Iron Lake machines here, and one started hanging around Christmas in early boot on ACPI initialization. Dmesg below, full dmesgs available on request.
>
> Exact model of the machine is HP Compaq 8100 Elite Small Form Factor PC. BIOS update from 2010 to 2011 (newest) didn't change anything.
> HP Elite laptop (ILK m540) or Dell SFF PC (ILK 650) don't have this particular problem.
>
> I've bisected the problem to the following commit:
>
> ----
> commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
> Author: Lv Zheng <lv.zheng@intel.com>
> Date:   Wed Dec 14 15:04:25 2016 +0800
>
>     ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
>
>     ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
> ----
>
> The affected machine is a testhost and readily available for any patches that might help pinpoint this bug.
>
> If you need any more information, you can contact me directly to this address.

Thanks for the report!

Does this patch make any difference:
https://patchwork.kernel.org/patch/9504277/ ?

Thanks,
Rafael

Re: ILK ACPI boot-up problem on HP 8100 SFF, bisected

[Rafael J. Wysocki]

On Mon, Jan 9, 2017 at 11:07 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> Hi,
>
> On Mon, Jan 9, 2017 at 5:01 PM, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
>> Hello there,
>>
>> We have couple of Iron Lake machines here, and one started hanging around Christmas in early boot on ACPI initialization. Dmesg below, full dmesgs available on request.
>>
>> Exact model of the machine is HP Compaq 8100 Elite Small Form Factor PC. BIOS update from 2010 to 2011 (newest) didn't change anything.
>> HP Elite laptop (ILK m540) or Dell SFF PC (ILK 650) don't have this particular problem.
>>
>> I've bisected the problem to the following commit:
>>
>> ----
>> commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
>> Author: Lv Zheng <lv.zheng@intel.com>
>> Date:   Wed Dec 14 15:04:25 2016 +0800
>>
>>     ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
>>
>>     ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
>> ----
>>
>> The affected machine is a testhost and readily available for any patches that might help pinpoint this bug.
>>
>> If you need any more information, you can contact me directly to this address.
>
> Thanks for the report!
>
> Does this patch make any difference:
> https://patchwork.kernel.org/patch/9504277/ ?

Please also check this alternative patch from Paul:

https://patchwork.kernel.org/patch/9506033/

Thanks,
Rafael

Re: ILK ACPI boot-up problem on HP 8100 SFF, bisected

[Tomi Sarvela]

On Monday, 9 January 2017 23:28:32 EET Rafael J. Wysocki wrote:
> On Mon, Jan 9, 2017 at 11:07 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Mon, Jan 9, 2017 at 5:01 PM, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
> >> We have couple of Iron Lake machines here, and one started
> >> hanging around Christmas in early boot on ACPI initialization.
> >> Dmesg below, full dmesgs available on request.
> >> 
> >> Exact model of the machine is HP Compaq 8100 Elite Small Form
> >> Factor PC. BIOS update from 2010 to 2011 (newest) didn't change
> >> anything. HP Elite laptop (ILK m540) or Dell SFF PC (ILK 650)
> >> don't have this particular problem.
> >> 
> >> I've bisected the problem to the following commit:
> >> 
> >> ----
> >> commit 174cc7187e6f088942c8e74daa7baff7b44b33c9
> >> Author: Lv Zheng <lv.zheng@intel.com>
> >> Date:   Wed Dec 14 15:04:25 2016 +0800
> >> 
> >>     ACPICA: Tables: Back port acpi_get_table_with_size() and
> >>     early_acpi_os_unmap_memory() from Linux kernel
> >>     
> >>     ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
> >> 
> >> ----
> > Thanks for the report!
> > 
> > Does this patch make any difference:
> > https://patchwork.kernel.org/patch/9504277/ ?
> 
> Please also check this alternative patch from Paul:
> 
> https://patchwork.kernel.org/patch/9506033/

I've tested both patches on top of latest kernel head (separate tries, to make it clear).

Neither patch does any difference. In both cases kernel still hangs to the same spot in boot, and 5sec powerbutton or AC reboot is needed.

Best regards,

Tomi Sarvela

[PATCH] ACPICA: Tables: Remove a hidden logic related to acpi_tb_install_standard_table()

[Lv Zheng]

There is a hidden logic for acpi_tb_install_standard_table() as it can be
invoked from boot stage and during runtime.
1. When it is invoked from the OS boot stage, ACPICA mutex may not be
   available, and thus no acpi_ut_acquire_mutex()/acpi_ut_release_mutex() are
   invoked in these code paths:
   acpi_initialize_tables
     acpi_tb_parse_root_table
       acpi_tb_install_standard_table (4 invocations)
   acpi_install_table
       acpi_tb_install_standard_table
2. When it is invoked during the runtime, ACPICA mutex is correctly used:
   acpi_ex_load_op
     acpi_tb_install_and_load_table
       acpi_tb_install_standard_table
   acpi_load_table
     acpi_tb_install_and_load_table
       acpi_tb_install_standard_table
So the mutex is now used in acpi_tb_install_and_load_table(), while it actually
should be in acpi_tb_install_standard_table().

This introduces another problem in acpi_tb_install_standard_table() where
acpi_gbl_table_handler is invoked from and the lock contexts are thus not
consistent for the table handlers. This triggers a regression when
acpi_get_table()/acpi_put_table() start to hold table mutex during runtime.

The regression is noticed by LKP as new errors reported by ACPICA mutex
debugging facility.
[    2.043693] ACPI Error: Mutex [ACPI_MTX_Tables] already acquired by this thread [497483776] (20160930/utmutex-254)
[    2.054084] ACPI Error: Mutex [0x2] is not acquired, cannot release (20160930/utmutex-326)

And it triggers a dead lock:
[  247.066214] INFO: task swapper/0:1 blocked for more than 120 seconds.
...
[  247.091271] Call Trace:
...
[  247.121523]  down_timeout+0x47/0x50
[  247.125065]  acpi_os_wait_semaphore+0x47/0x62
[  247.129475]  acpi_ut_acquire_mutex+0x43/0x81
[  247.133798]  acpi_get_table+0x2d/0x84
[  247.137513]  acpi_table_attr_init+0xcd/0x100
[  247.146590]  acpi_sysfs_table_handler+0x5d/0xb8
[  247.151174]  acpi_bus_table_handler+0x23/0x2a
[  247.155583]  acpi_tb_install_standard_table+0xe0/0x213
[  247.164489]  acpi_tb_install_and_load_table+0x3a/0x82
[  247.169592]  acpi_ex_load_op+0x194/0x201
...
[  247.200108]  acpi_ns_evaluate+0x1bb/0x247
[  247.204170]  acpi_evaluate_object+0x178/0x274
[  247.213249]  acpi_processor_set_pdc+0x154/0x17b
...
The table mutex is held in acpi_tb_install_and_load_table() and is re-visited by
acpi_get_table().

Noticing that the early mutex requirement actually belongs to the OSL layer
and has already been handled in Linux
acpi_os_wait_semaphore()/acpi_os_signal_semaphore(). This patch then can
fix the regression by removing this hidden logic from ACPICA core and
leaving it to OSPMs. A documentation update should also be required.

Fixes: 174cc7187e6f ('ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel')
Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: Ye Xiaolong <xiaolong.ye@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
---
 drivers/acpi/acpica/tbdata.c   |  9 ++-------
 drivers/acpi/acpica/tbinstal.c | 17 +++++++++++++++--
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index 82b0b57..b0399e8 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -852,23 +852,18 @@ acpi_tb_install_and_load_table(acpi_physical_address address,
 
 	ACPI_FUNCTION_TRACE(tb_install_and_load_table);
 
-	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
-
 	/* Install the table and load it into the namespace */
 
 	status = acpi_tb_install_standard_table(address, flags, TRUE,
 						override, &i);
 	if (ACPI_FAILURE(status)) {
-		goto unlock_and_exit;
+		goto exit;
 	}
 
-	(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
 	status = acpi_tb_load_table(i, acpi_gbl_root_node);
-	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 
-unlock_and_exit:
+exit:
 	*table_index = i;
-	(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
 	return_ACPI_STATUS(status);
 }
 
diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c
index 5fdf251..01e1b3d 100644
--- a/drivers/acpi/acpica/tbinstal.c
+++ b/drivers/acpi/acpica/tbinstal.c
@@ -217,6 +217,10 @@ acpi_tb_install_standard_table(acpi_physical_address address,
 		goto release_and_exit;
 	}
 
+	/* Acquire the table lock */
+
+	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
+
 	if (reload) {
 		/*
 		 * Validate the incoming table signature.
@@ -244,7 +248,7 @@ acpi_tb_install_standard_table(acpi_physical_address address,
 					 new_table_desc.signature.integer));
 
 			status = AE_BAD_SIGNATURE;
-			goto release_and_exit;
+			goto unlock_and_exit;
 		}
 
 		/* Check if table is already registered */
@@ -279,7 +283,7 @@ acpi_tb_install_standard_table(acpi_physical_address address,
 				/* Table is still loaded, this is an error */
 
 				status = AE_ALREADY_EXISTS;
-				goto release_and_exit;
+				goto unlock_and_exit;
 			} else {
 				/*
 				 * Table was unloaded, allow it to be reloaded.
@@ -290,6 +294,7 @@ acpi_tb_install_standard_table(acpi_physical_address address,
 				 * indicate the re-installation.
 				 */
 				acpi_tb_uninstall_table(&new_table_desc);
+				(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
 				*table_index = i;
 				return_ACPI_STATUS(AE_OK);
 			}
@@ -303,11 +308,19 @@ acpi_tb_install_standard_table(acpi_physical_address address,
 
 	/* Invoke table handler if present */
 
+	(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
 	if (acpi_gbl_table_handler) {
 		(void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_INSTALL,
 					     new_table_desc.pointer,
 					     acpi_gbl_table_handler_context);
 	}
+	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
+
+unlock_and_exit:
+
+	/* Release the table lock */
+
+	(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
 
 release_and_exit:
 
-- 
2.7.4

Re: [PATCH] ACPICA: Tables: Remove a hidden logic related to acpi_tb_install_standard_table()

[Tomi Sarvela]

On Thursday, 19 January 2017 15:21:34 EET Lv Zheng wrote:
> There is a hidden logic for acpi_tb_install_standard_table() as it
> can be invoked from boot stage and during runtime.
> 1. When it is invoked from the OS boot stage, ACPICA mutex may not
> be available, and thus no
> acpi_ut_acquire_mutex()/acpi_ut_release_mutex() are invoked in
> these code paths:
>    acpi_initialize_tables
>      acpi_tb_parse_root_table
>        acpi_tb_install_standard_table (4 invocations)
>    acpi_install_table
>        acpi_tb_install_standard_table
> 2. When it is invoked during the runtime, ACPICA mutex is correctly
> used: acpi_ex_load_op
>      acpi_tb_install_and_load_table
>        acpi_tb_install_standard_table
>    acpi_load_table
>      acpi_tb_install_and_load_table
>        acpi_tb_install_standard_table
> So the mutex is now used in acpi_tb_install_and_load_table(), while
> it actually should be in acpi_tb_install_standard_table().
> 
> This introduces another problem in acpi_tb_install_standard_table()
> where acpi_gbl_table_handler is invoked from and the lock contexts
> are thus not consistent for the table handlers. This triggers a
> regression when acpi_get_table()/acpi_put_table() start to hold
> table mutex during runtime.
> 
> The regression is noticed by LKP as new errors reported by ACPICA
> mutex debugging facility.
> [    2.043693] ACPI Error: Mutex [ACPI_MTX_Tables] already acquired
> by this thread [497483776] (20160930/utmutex-254) [    2.054084]
> ACPI Error: Mutex [0x2] is not acquired, cannot release
> (20160930/utmutex-326)
> 
> And it triggers a dead lock:
> [  247.066214] INFO: task swapper/0:1 blocked for more than 120
> seconds. ...
> [  247.091271] Call Trace:
> ...
> [  247.121523]  down_timeout+0x47/0x50
> [  247.125065]  acpi_os_wait_semaphore+0x47/0x62
> [  247.129475]  acpi_ut_acquire_mutex+0x43/0x81
> [  247.133798]  acpi_get_table+0x2d/0x84
> [  247.137513]  acpi_table_attr_init+0xcd/0x100
> [  247.146590]  acpi_sysfs_table_handler+0x5d/0xb8
> [  247.151174]  acpi_bus_table_handler+0x23/0x2a
> [  247.155583]  acpi_tb_install_standard_table+0xe0/0x213
> [  247.164489]  acpi_tb_install_and_load_table+0x3a/0x82
> [  247.169592]  acpi_ex_load_op+0x194/0x201
> ...
> [  247.200108]  acpi_ns_evaluate+0x1bb/0x247
> [  247.204170]  acpi_evaluate_object+0x178/0x274
> [  247.213249]  acpi_processor_set_pdc+0x154/0x17b
> ...
> The table mutex is held in acpi_tb_install_and_load_table() and is
> re-visited by acpi_get_table().
> 
> Noticing that the early mutex requirement actually belongs to the
> OSL layer and has already been handled in Linux
> acpi_os_wait_semaphore()/acpi_os_signal_semaphore(). This patch then
> can fix the regression by removing this hidden logic from ACPICA
> core and leaving it to OSPMs. A documentation update should also be
> required.
> 
> Fixes: 174cc7187e6f ('ACPICA: Tables: Back port
> acpi_get_table_with_size() and early_acpi_os_unmap_memory() from
> Linux kernel') Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
> Cc: Ye Xiaolong <xiaolong.ye@intel.com>
> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> ---

This patch helps ILK-650 testhost survive past the boot ACPI setup.

Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>

Best regards,

Tomi Sarvela

Re: [PATCH] ACPICA: Tables: Remove a hidden logic related to acpi_tb_install_standard_table()

[Rafael J. Wysocki]

On Thu, Jan 19, 2017 at 10:38 AM, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
> On Thursday, 19 January 2017 15:21:34 EET Lv Zheng wrote:
>> There is a hidden logic for acpi_tb_install_standard_table() as it
>> can be invoked from boot stage and during runtime.
>> 1. When it is invoked from the OS boot stage, ACPICA mutex may not
>> be available, and thus no
>> acpi_ut_acquire_mutex()/acpi_ut_release_mutex() are invoked in
>> these code paths:
>>    acpi_initialize_tables
>>      acpi_tb_parse_root_table
>>        acpi_tb_install_standard_table (4 invocations)
>>    acpi_install_table
>>        acpi_tb_install_standard_table
>> 2. When it is invoked during the runtime, ACPICA mutex is correctly
>> used: acpi_ex_load_op
>>      acpi_tb_install_and_load_table
>>        acpi_tb_install_standard_table
>>    acpi_load_table
>>      acpi_tb_install_and_load_table
>>        acpi_tb_install_standard_table
>> So the mutex is now used in acpi_tb_install_and_load_table(), while
>> it actually should be in acpi_tb_install_standard_table().
>>
>> This introduces another problem in acpi_tb_install_standard_table()
>> where acpi_gbl_table_handler is invoked from and the lock contexts
>> are thus not consistent for the table handlers. This triggers a
>> regression when acpi_get_table()/acpi_put_table() start to hold
>> table mutex during runtime.
>>
>> The regression is noticed by LKP as new errors reported by ACPICA
>> mutex debugging facility.
>> [    2.043693] ACPI Error: Mutex [ACPI_MTX_Tables] already acquired
>> by this thread [497483776] (20160930/utmutex-254) [    2.054084]
>> ACPI Error: Mutex [0x2] is not acquired, cannot release
>> (20160930/utmutex-326)
>>
>> And it triggers a dead lock:
>> [  247.066214] INFO: task swapper/0:1 blocked for more than 120
>> seconds. ...
>> [  247.091271] Call Trace:
>> ...
>> [  247.121523]  down_timeout+0x47/0x50
>> [  247.125065]  acpi_os_wait_semaphore+0x47/0x62
>> [  247.129475]  acpi_ut_acquire_mutex+0x43/0x81
>> [  247.133798]  acpi_get_table+0x2d/0x84
>> [  247.137513]  acpi_table_attr_init+0xcd/0x100
>> [  247.146590]  acpi_sysfs_table_handler+0x5d/0xb8
>> [  247.151174]  acpi_bus_table_handler+0x23/0x2a
>> [  247.155583]  acpi_tb_install_standard_table+0xe0/0x213
>> [  247.164489]  acpi_tb_install_and_load_table+0x3a/0x82
>> [  247.169592]  acpi_ex_load_op+0x194/0x201
>> ...
>> [  247.200108]  acpi_ns_evaluate+0x1bb/0x247
>> [  247.204170]  acpi_evaluate_object+0x178/0x274
>> [  247.213249]  acpi_processor_set_pdc+0x154/0x17b
>> ...
>> The table mutex is held in acpi_tb_install_and_load_table() and is
>> re-visited by acpi_get_table().
>>
>> Noticing that the early mutex requirement actually belongs to the
>> OSL layer and has already been handled in Linux
>> acpi_os_wait_semaphore()/acpi_os_signal_semaphore(). This patch then
>> can fix the regression by removing this hidden logic from ACPICA
>> core and leaving it to OSPMs. A documentation update should also be
>> required.
>>
>> Fixes: 174cc7187e6f ('ACPICA: Tables: Back port
>> acpi_get_table_with_size() and early_acpi_os_unmap_memory() from
>> Linux kernel') Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
>> Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
>> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
>> Cc: Ye Xiaolong <xiaolong.ye@intel.com>
>> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
>> ---
>
> This patch helps ILK-650 testhost survive past the boot ACPI setup.
>
> Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>

OK

I'm queuing this up as a fix for 4.10.

Thanks,
Rafael