[patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

This patch is to introduce BOOT_EFI and BOOT_CF9 in the reboot sequence
loop, to fix the reboot problem on the known Intel Bay Trail-T based
platform, for example, ASUS-T100 and Dell Venue 8/11 Pro. These
platforms don't support ACPI reboot, we expect to call EFI runtime
service to handle this case, and CF9 is an alternate after EFI.

We don't need any dmidecode based quirks any more, we don't need extra
"reboot=efi" or "reboot=p" in the command line. The machine can be
rebooted automatically with the patch.

References: https://bugzilla.kernel.org/show_bug.cgi?id=70931
Signed-off-by Aubrey Li <aubrey.li@intel.com>
---
 arch/x86/kernel/reboot.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index c752cb4..1b58e00 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -462,11 +462,12 @@ void __attribute__((weak)) mach_reboot_fixups(void)
  *
  * 1) If the FADT has the ACPI reboot register flag set, try it
  * 2) If still alive, write to the keyboard controller
- * 3) If still alive, write to the ACPI reboot register again
- * 4) If still alive, write to the keyboard controller again
+ * 3) If still alive, call EFI runtime service
+ * 4) If still alive, write to the PCI IO port 0xCF9
+ * 5) If still alive, try (1)~(4) one time again
  *
  * If the machine is still alive at this stage, it gives up. We default to
- * following the same pattern, except that if we're still alive after
(4) we'll
+ * following the same pattern, except that if we're still alive after
(5) we'll
  * try to force a triple fault and then cycle between hitting the keyboard
  * controller and doing that
  */
@@ -500,7 +501,7 @@ static void native_machine_emergency_restart(void)
 			}
 			if (attempt == 0 && orig_reboot_type == BOOT_ACPI) {
 				attempt = 1;
-				reboot_type = BOOT_ACPI;
+				reboot_type = BOOT_EFI;
 			} else {
 				reboot_type = BOOT_TRIPLE;
 			}
@@ -530,7 +531,7 @@ static void native_machine_emergency_restart(void)
 						 EFI_RESET_WARM :
 						 EFI_RESET_COLD,
 						 EFI_SUCCESS, 0, NULL);
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_CF9;
 			break;

 		case BOOT_CF9:
@@ -548,7 +549,7 @@ static void native_machine_emergency_restart(void)
 				outb(cf9|reboot_code, 0xcf9);
 				udelay(50);
 			}
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_ACPI;
 			break;
 		}
 	}
-- 
1.7.10.4

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Fri, Feb 28, 2014 at 12:11:57PM +0800, Li, Aubrey wrote:
> This patch is to introduce BOOT_EFI and BOOT_CF9 in the reboot sequence
> loop, to fix the reboot problem on the known Intel Bay Trail-T based
> platform, for example, ASUS-T100 and Dell Venue 8/11 Pro. These
> platforms don't support ACPI reboot, we expect to call EFI runtime
> service to handle this case, and CF9 is an alternate after EFI.

EFI reboot is still somewhat unreliable - it may be safe after the 
recent patches to provide a 1:1 mapping. CF9 is, as far as I know, not 
part of any spec, so it seems like a bad idea to put it in the default 
list.

What do the ACPI reboot vectors look like on these systems?

> - * 3) If still alive, write to the ACPI reboot register again
> - * 4) If still alive, write to the keyboard controller again
> + * 3) If still alive, call EFI runtime service
> + * 4) If still alive, write to the PCI IO port 0xCF9

This is definitely incorrect. The ACPI write *must* occur twice in order 
to be effective on various systems. EFI shouldn't be attempted until 
after the second ACPI write.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/2/28 12:56, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 12:11:57PM +0800, Li, Aubrey wrote:
>> This patch is to introduce BOOT_EFI and BOOT_CF9 in the reboot sequence
>> loop, to fix the reboot problem on the known Intel Bay Trail-T based
>> platform, for example, ASUS-T100 and Dell Venue 8/11 Pro. These
>> platforms don't support ACPI reboot, we expect to call EFI runtime
>> service to handle this case, and CF9 is an alternate after EFI.
> 
> EFI reboot is still somewhat unreliable - it may be safe after the 
> recent patches to provide a 1:1 mapping.

So it's acceptable to put EFI in the default list.


> CF9 is, as far as I know, not  part of any spec, so it seems like a bad
> idea to put it in the default list.

Any hurt known if put it in the default list?

> 
> What do the ACPI reboot vectors look like on these systems?

Reset register address: 0xCF9
Value to cause reset:   0x6

> 
>> - * 3) If still alive, write to the ACPI reboot register again
>> - * 4) If still alive, write to the keyboard controller again
>> + * 3) If still alive, call EFI runtime service
>> + * 4) If still alive, write to the PCI IO port 0xCF9
> 
> This is definitely incorrect. The ACPI write *must* occur twice in order 
> to be effective on various systems. EFI shouldn't be attempted until 
> after the second ACPI write.
> 

Do we have any spec mentioned that?

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Fri, Feb 28, 2014 at 01:22:37PM +0800, Li, Aubrey wrote:
> On 2014/2/28 12:56, Matthew Garrett wrote:
> > EFI reboot is still somewhat unreliable - it may be safe after the 
> > recent patches to provide a 1:1 mapping.
> 
> So it's acceptable to put EFI in the default list.

Probably, once we've got those patches landed (I've lost track of 
whether they're in 3.13 or aimed at 3.14)

> > CF9 is, as far as I know, not  part of any spec, so it seems like a bad
> > idea to put it in the default list.
> 
> Any hurt known if put it in the default list?

Mm. Not all x86 platforms support cf8/cf9 (Moorestown, for instance) and 
so it's theoretically possible that they'd put some different hardware 
there instead. But then, Moorestown probably has its own reboot code, so 
that may not matter?

> > 
> > What do the ACPI reboot vectors look like on these systems?
> 
> Reset register address: 0xCF9
> Value to cause reset:   0x6

Huh. But that's almost exactly what the PCI reboot code would do. Why 
does the PCI method work but the ACPI one fail? Does it really depend on 
ORing the original value with the reset value? Or is the timing just 
somehow marginal?

> > This is definitely incorrect. The ACPI write *must* occur twice in order 
> > to be effective on various systems. EFI shouldn't be attempted until 
> > after the second ACPI write.
> > 
> 
> Do we have any spec mentioned that?

Nope. This is entirely unspecified, it's just how things work - several 
vendors use cf9 for the ACPI reboot vector, and there have to be two 
writes to cf9 to trigger the reboot. Windows attempts the write twice, 
and as a result things work.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/2/28 13:56, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 01:22:37PM +0800, Li, Aubrey wrote:
>> On 2014/2/28 12:56, Matthew Garrett wrote:
>>> EFI reboot is still somewhat unreliable - it may be safe after the 
>>> recent patches to provide a 1:1 mapping.
>>
>> So it's acceptable to put EFI in the default list.
> 
> Probably, once we've got those patches landed (I've lost track of 
> whether they're in 3.13 or aimed at 3.14)

You didn't look the reference I quoted in the patch.

It's stable if 32/64 bit linux call the corresponding 32/64bit EFI
runtime service. Matt Fleming's mixed mode is aiming at 3.15:

http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=mixed-mode

> 
>>> CF9 is, as far as I know, not  part of any spec, so it seems like a bad
>>> idea to put it in the default list.
>>
>> Any hurt known if put it in the default list?
> 
> Mm. Not all x86 platforms support cf8/cf9 (Moorestown, for instance) and 
> so it's theoretically possible that they'd put some different hardware 
> there instead. But then, Moorestown probably has its own reboot code, so 
> that may not matter?

Yes, Moorestown has its own machine_ops. Instead of the system hanging
after issue "reboot" command, I think and suggest CF9 is worth to have a
try.

> 
>>>
>>> What do the ACPI reboot vectors look like on these systems?
>>
>> Reset register address: 0xCF9
>> Value to cause reset:   0x6
> 
> Huh. But that's almost exactly what the PCI reboot code would do. Why 
> does the PCI method work but the ACPI one fail? Does it really depend on 
> ORing the original value with the reset value? Or is the timing just 
> somehow marginal?

reboot returns at:

if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER))
                return;

This is a ACPI bug or intention, who knows.

> 
>>> This is definitely incorrect. The ACPI write *must* occur twice in order 
>>> to be effective on various systems. EFI shouldn't be attempted until 
>>> after the second ACPI write.
>>>
>>
>> Do we have any spec mentioned that?
> 
> Nope. This is entirely unspecified, it's just how things work - several 
> vendors use cf9 for the ACPI reboot vector, and there have to be two 
> writes to cf9 to trigger the reboot. Windows attempts the write twice, 
> and as a result things work.
> 

Thanks to clarify this, I'll refine the patch, including CF9 if you
don't have more concern.

-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Fri, Feb 28, 2014 at 02:07:58PM +0800, Li, Aubrey wrote:
> On 2014/2/28 13:56, Matthew Garrett wrote:
> > Probably, once we've got those patches landed (I've lost track of 
> > whether they're in 3.13 or aimed at 3.14)
> 
> You didn't look the reference I quoted in the patch.
> 
> It's stable if 32/64 bit linux call the corresponding 32/64bit EFI
> runtime service. Matt Fleming's mixed mode is aiming at 3.15:
> 
> http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=mixed-mode

It's stable as long as you have the 1:1 mapping patches, which are 
different to the mixed mode patches. Otherwise it'll work on some 
hardware and crash on others.

> > Mm. Not all x86 platforms support cf8/cf9 (Moorestown, for instance) and 
> > so it's theoretically possible that they'd put some different hardware 
> > there instead. But then, Moorestown probably has its own reboot code, so 
> > that may not matter?
> 
> Yes, Moorestown has its own machine_ops. Instead of the system hanging
> after issue "reboot" command, I think and suggest CF9 is worth to have a
> try.

Writing to arbitrary register addresses isn't a good plan if we're on a 
platform that might have different hardware there.

> >> Reset register address: 0xCF9
> >> Value to cause reset:   0x6
> > 
> > Huh. But that's almost exactly what the PCI reboot code would do. Why 
> > does the PCI method work but the ACPI one fail? Does it really depend on 
> > ORing the original value with the reset value? Or is the timing just 
> > somehow marginal?
> 
> reboot returns at:
> 
> if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER))
>                 return;
> 
> This is a ACPI bug or intention, who knows.

Well, how about we figure that out? Is there a full acpi dump of one of 
these machines somewhere?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

On 2014/2/28 14:12, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:07:58PM +0800, Li, Aubrey wrote:
>> On 2014/2/28 13:56, Matthew Garrett wrote:
>>> Probably, once we've got those patches landed (I've lost track of 
>>> whether they're in 3.13 or aimed at 3.14)
>>
>> You didn't look the reference I quoted in the patch.
>>
>> It's stable if 32/64 bit linux call the corresponding 32/64bit EFI
>> runtime service. Matt Fleming's mixed mode is aiming at 3.15:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=mixed-mode
> 
> It's stable as long as you have the 1:1 mapping patches, which are 
> different to the mixed mode patches. Otherwise it'll work on some 
> hardware and crash on others.
> 
>>> Mm. Not all x86 platforms support cf8/cf9 (Moorestown, for instance) and 
>>> so it's theoretically possible that they'd put some different hardware 
>>> there instead. But then, Moorestown probably has its own reboot code, so 
>>> that may not matter?
>>
>> Yes, Moorestown has its own machine_ops. Instead of the system hanging
>> after issue "reboot" command, I think and suggest CF9 is worth to have a
>> try.
> 
> Writing to arbitrary register addresses isn't a good plan if we're on a 
> platform that might have different hardware there.
> 

Do we have one actually? if we have, I'll remove CF9, if no, I persist
in keeping it, because without it my box can't reboot now, :)

>>>> Reset register address: 0xCF9
>>>> Value to cause reset:   0x6
>>>
>>> Huh. But that's almost exactly what the PCI reboot code would do. Why 
>>> does the PCI method work but the ACPI one fail? Does it really depend on 
>>> ORing the original value with the reset value? Or is the timing just 
>>> somehow marginal?
>>
>> reboot returns at:
>>
>> if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER))
>>                 return;
>>
>> This is a ACPI bug or intention, who knows.
> 
> Well, how about we figure that out? Is there a full acpi dump of one of 
> these machines somewhere?
> 

Well, I already figured that out. Reset Register Supported flag is ZERO
in FACP table. I attached this table for your interesting.

When I said "this is a ACPI bug or intention", I actually meant it's a
bug or intention created by OEM.

Thanks,
-Aubrey


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: facp.dsl --]
[-- Type: text/plain; charset=gb18030; name="facp.dsl", Size: 9129 bytes --]

/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20140114-64 [Jan 15 2014]
 * Copyright (c) 2000 - 2014 Intel Corporation
 * 
 * Disassembly of facp.dat, Fri Jan 24 01:34:59 2014
 *
 * ACPI Data Table [FACP]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000   4]                    Signature : "FACP"    [Fixed ACPI Description Table (FADT)]
[004h 0004   4]                 Table Length : 000000F4
[008h 0008   1]                     Revision : 05
[009h 0009   1]                     Checksum : 03     /* Incorrect checksum, should be 2C */
[00Ah 0010   6]                       Oem ID : "_ASUS_"
[010h 0016   8]                 Oem Table ID : "A M I   "
[018h 0024   4]                 Oem Revision : 00000003
[01Ch 0028   4]              Asl Compiler ID : "AMI "
[020h 0032   4]        Asl Compiler Revision : 0100000D

[024h 0036   4]                 FACS Address : 78EED000
[028h 0040   4]                 DSDT Address : 78D49000
[02Ch 0044   1]                        Model : 01
[02Dh 0045   1]                   PM Profile : 08 [Tablet]
[02Eh 0046   2]                SCI Interrupt : 0000
[030h 0048   4]             SMI Command Port : 000000B2
[034h 0052   1]            ACPI Enable Value : 00
[035h 0053   1]           ACPI Disable Value : 00
[036h 0054   1]               S4BIOS Command : 00
[037h 0055   1]              P-State Control : 00
[038h 0056   4]     PM1A Event Block Address : 00000000
[03Ch 0060   4]     PM1B Event Block Address : 00000000
[040h 0064   4]   PM1A Control Block Address : 00000000
[044h 0068   4]   PM1B Control Block Address : 00000000
[048h 0072   4]    PM2 Control Block Address : 00000000
[04Ch 0076   4]       PM Timer Block Address : 00000000
[050h 0080   4]           GPE0 Block Address : 00000000
[054h 0084   4]           GPE1 Block Address : 00000000
[058h 0088   1]       PM1 Event Block Length : 00
[059h 0089   1]     PM1 Control Block Length : 00
[05Ah 0090   1]     PM2 Control Block Length : 00
[05Bh 0091   1]        PM Timer Block Length : 00
[05Ch 0092   1]            GPE0 Block Length : 00
[05Dh 0093   1]            GPE1 Block Length : 00
[05Eh 0094   1]             GPE1 Base Offset : 00
[05Fh 0095   1]                 _CST Support : 00
[060h 0096   2]                   C2 Latency : 0000
[062h 0098   2]                   C3 Latency : 0000
[064h 0100   2]               CPU Cache Size : 0000
[066h 0102   2]           Cache Flush Stride : 0000
[068h 0104   1]            Duty Cycle Offset : 00
[069h 0105   1]             Duty Cycle Width : 00
[06Ah 0106   1]          RTC Day Alarm Index : 00
[06Bh 0107   1]        RTC Month Alarm Index : 00
[06Ch 0108   1]            RTC Century Index : 00
[06Dh 0109   2]   Boot Flags (decoded below) : 0004
               Legacy Devices Supported (V2) : 0
            8042 Present on ports 60/64 (V2) : 0
                        VGA Not Present (V4) : 1
                      MSI Not Supported (V4) : 0
                PCIe ASPM Not Supported (V4) : 0
                   CMOS RTC Not Present (V5) : 0
[06Fh 0111   1]                     Reserved : 00
[070h 0112   4]        Flags (decoded below) : 00300021
      WBINVD instruction is operational (V1) : 1
              WBINVD flushes all caches (V1) : 0
                    All CPUs support C1 (V1) : 0
                  C2 works on MP system (V1) : 0
            Control Method Power Button (V1) : 0
            Control Method Sleep Button (V1) : 1
        RTC wake not in fixed reg space (V1) : 0
            RTC can wake system from S4 (V1) : 0
                        32-bit PM Timer (V1) : 0
                      Docking Supported (V1) : 0
               Reset Register Supported (V2) : 0
                            Sealed Case (V3) : 0
                    Headless - No Video (V3) : 0
        Use native instr after SLP_TYPx (V3) : 0
              PCIEXP_WAK Bits Supported (V4) : 0
                     Use Platform Timer (V4) : 0
               RTC_STS valid on S4 wake (V4) : 0
                Remote Power-on capable (V4) : 0
                 Use APIC Cluster Model (V4) : 0
     Use APIC Physical Destination Mode (V4) : 0
                       Hardware Reduced (V5) : 1
                      Low Power S0 Idle (V5) : 1

[074h 0116  12]               Reset Register : [Generic Address Structure]
[074h 0116   1]                     Space ID : 01 [SystemIO]
[075h 0117   1]                    Bit Width : 08
[076h 0118   1]                   Bit Offset : 00
[077h 0119   1]         Encoded Access Width : 00 [Undefined/Legacy]
[078h 0120   8]                      Address : 0000000000000CF9

[080h 0128   1]         Value to cause reset : 06
[081h 0129   3]                     Reserved : 000000
[084h 0132   8]                 FACS Address : 0000000078EED000
[08Ch 0140   8]                 DSDT Address : 0000000078D49000
[094h 0148  12]             PM1A Event Block : [Generic Address Structure]
[094h 0148   1]                     Space ID : 00 [SystemMemory]
[095h 0149   1]                    Bit Width : 00
[096h 0150   1]                   Bit Offset : 00
[097h 0151   1]         Encoded Access Width : 00 [Undefined/Legacy]
[098h 0152   8]                      Address : 0000000000000000

[0A0h 0160  12]             PM1B Event Block : [Generic Address Structure]
[0A0h 0160   1]                     Space ID : 00 [SystemMemory]
[0A1h 0161   1]                    Bit Width : 00
[0A2h 0162   1]                   Bit Offset : 00
[0A3h 0163   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0A4h 0164   8]                      Address : 0000000000000000

[0ACh 0172  12]           PM1A Control Block : [Generic Address Structure]
[0ACh 0172   1]                     Space ID : 00 [SystemMemory]
[0ADh 0173   1]                    Bit Width : 00
[0AEh 0174   1]                   Bit Offset : 00
[0AFh 0175   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0B0h 0176   8]                      Address : 0000000000000000

[0B8h 0184  12]           PM1B Control Block : [Generic Address Structure]
[0B8h 0184   1]                     Space ID : 00 [SystemMemory]
[0B9h 0185   1]                    Bit Width : 00
[0BAh 0186   1]                   Bit Offset : 00
[0BBh 0187   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0BCh 0188   8]                      Address : 0000000000000000

[0C4h 0196  12]            PM2 Control Block : [Generic Address Structure]
[0C4h 0196   1]                     Space ID : 00 [SystemMemory]
[0C5h 0197   1]                    Bit Width : 00
[0C6h 0198   1]                   Bit Offset : 00
[0C7h 0199   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0C8h 0200   8]                      Address : 0000000000000000

[0D0h 0208  12]               PM Timer Block : [Generic Address Structure]
[0D0h 0208   1]                     Space ID : 00 [SystemMemory]
[0D1h 0209   1]                    Bit Width : 00
[0D2h 0210   1]                   Bit Offset : 00
[0D3h 0211   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0D4h 0212   8]                      Address : 0000000000000000

[0DCh 0220  12]                   GPE0 Block : [Generic Address Structure]
[0DCh 0220   1]                     Space ID : 00 [SystemMemory]
[0DDh 0221   1]                    Bit Width : 00
[0DEh 0222   1]                   Bit Offset : 00
[0DFh 0223   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0E0h 0224   8]                      Address : 0000000000000000

[0E8h 0232  12]                   GPE1 Block : [Generic Address Structure]
[0E8h 0232   1]                     Space ID : 00 [SystemMemory]
[0E9h 0233   1]                    Bit Width : 00
[0EAh 0234   1]                   Bit Offset : 00
[0EBh 0235   1]         Encoded Access Width : 00 [Undefined/Legacy]
[0ECh 0236   8]                      Address : 0000000000000000


// ACPI Warning: FADT revision 5 does not match length: found F4 expected 10C

Raw Table Data: Length 244 (0xF4)

  0000: 46 41 43 50 F4 00 00 00 05 03 5F 41 53 55 53 5F  FACP......_ASUS_
  0010: 41 20 4D 20 49 20 20 20 03 00 00 00 41 4D 49 20  A M I   ....AMI 
  0020: 0D 00 00 01 00 D0 EE 78 00 90 D4 78 01 08 00 00  .......x...x....
  0030: B2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00  ................
  0070: 21 00 30 00 01 08 00 00 F9 0C 00 00 00 00 00 00  !.0.............
  0080: 06 00 00 00 00 D0 EE 78 00 00 00 00 00 90 D4 78  .......x.......x
  0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00F0: 00 00 00 00                                      ....

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Fri, Feb 28, 2014 at 02:20:41PM +0800, Li, Aubrey wrote:

> Well, I already figured that out. Reset Register Supported flag is ZERO
> in FACP table. I attached this table for your interesting.

Ok, in that case we need to check how Windows deals with a FACP that has 
this flag set to 0 but valid looking registers defined. I'll see if I 
can do that tomorrow.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/2/28 14:23, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:20:41PM +0800, Li, Aubrey wrote:
> 
>> Well, I already figured that out. Reset Register Supported flag is ZERO
>> in FACP table. I attached this table for your interesting.
> 
> Ok, in that case we need to check how Windows deals with a FACP that has 
> this flag set to 0 but valid looking registers defined. I'll see if I 
> can do that tomorrow.
> 

Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.

I'll be surprise if other windows version ignores RESET_REG_SUP to use
ACPI reset registers.

=========ACPI spec ==============================
RESET_REG_SUP: If set, indicates the system supports system reset via
the FADT RESET_REG as described in Section 4.8.3.6
=================================================

Thanks for checking that, please keep me posted. I'll re-submit the
patch after you have an update.

-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:

> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.

Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
mapping support has landed. The right place to try it is probably after 
the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
about adding cf9 by default.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/2/28 14:44, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
> 
>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
> 
> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
> mapping support has landed. The right place to try it is probably after 
> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
> about adding cf9 by default.
> 

I'll defer to you if no one on the list supports me to add cf9.

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 02/27/2014 10:54 PM, Li, Aubrey wrote:
> On 2014/2/28 14:44, Matthew Garrett wrote:
>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>
>>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
>>
>> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
>> mapping support has landed. The right place to try it is probably after 
>> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
>> about adding cf9 by default.
>>
> 
> I'll defer to you if no one on the list supports me to add cf9.
> 

I believe we *had* it in the default list for a while, and it caused
hangs on some systems.

	-hpa

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/1 1:47, H. Peter Anvin wrote:
> On 02/27/2014 10:54 PM, Li, Aubrey wrote:
>> On 2014/2/28 14:44, Matthew Garrett wrote:
>>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>>
>>>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
>>>
>>> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
>>> mapping support has landed. The right place to try it is probably after 
>>> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
>>> about adding cf9 by default.
>>>
>>
>> I'll defer to you if no one on the list supports me to add cf9.
>>
> 
> I believe we *had* it in the default list for a while, and it caused
> hangs on some systems.

So this can be finalized, add EFI after twice ACPI reboot attempt. I'll
update the bugzilla and the patch.

Thanks,
-Aubrey
> 
> 	-hpa
> 
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Adam Williamson]

On Sat, 2014-03-01 at 06:11 +0800, Li, Aubrey wrote:
> On 2014/3/1 1:47, H. Peter Anvin wrote:
> > On 02/27/2014 10:54 PM, Li, Aubrey wrote:
> >> On 2014/2/28 14:44, Matthew Garrett wrote:
> >>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
> >>>
> >>>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
> >>>
> >>> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
> >>> mapping support has landed. The right place to try it is probably after 
> >>> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
> >>> about adding cf9 by default.
> >>>
> >>
> >> I'll defer to you if no one on the list supports me to add cf9.
> >>
> > 
> > I believe we *had* it in the default list for a while, and it caused
> > hangs on some systems.
> 
> So this can be finalized, add EFI after twice ACPI reboot attempt. I'll
> update the bugzilla and the patch.
> 
> Thanks,
> -Aubrey

I believe Matt still wanted to check the status of "the recent patches
to provide a 1:1 mapping" and only commit this after those. I was trying
to figure out what patches he meant exactly so I could check that status
(I'm helping! I'm helping!) but I couldn't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/1 6:11, Li, Aubrey wrote:
> On 2014/3/1 1:47, H. Peter Anvin wrote:
>> On 02/27/2014 10:54 PM, Li, Aubrey wrote:
>>> On 2014/2/28 14:44, Matthew Garrett wrote:
>>>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>>>
>>>>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
>>>>
>>>> Ok, in that case we should add EFI reboot to the list once Matt's 1:1 
>>>> mapping support has landed. The right place to try it is probably after 
>>>> the second attempt to perform an ACPI reboot. I'm still not enthusiastic 
>>>> about adding cf9 by default.
>>>>
>>>
>>> I'll defer to you if no one on the list supports me to add cf9.
>>>
>>
>> I believe we *had* it in the default list for a while, and it caused
>> hangs on some systems.

Well, keep pressing the power button for 20 seconds to power off my
ASUS-T100 makes me to re-read this thread.

Peter - Can you please clarify writing to cf9 caused some system hang.
If CF9 is the last way to try, that means ACPI, KBD takes no effect,
then if no CF9, the system hangs there in  infinite for() loop. If CF9
is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
system hang, right? If the answer is no, can you please point me which
system hangs by CF9. I'd like to investigate what the ACPI reboot
vectors look like on these systems.

I know, cf9 is not an architectural way, twice ACPI call has no spec
support as well.

Please remember, reboot/power off is the last service Linux kernel can
do for our users, why can't we just make it more robust?

IMHO, we should try all of the way we know. Don't worry, we are in the
shutdown context so we don't have a chance to break any other OS components.

Again, I'd like to suggest we try all of the known methods in the
default list, unless you have a functional reason to object.

(1) ACPI
(2) keyboard
(3) ACPI
(4) keyboard
(5) FADT sleep register as long as it's valid(!=0)
(6) FADT sleep registers once again(since we try ACPI twice)
(7) EFI (interesting, I found it's eventually CF9 on some my
investigated systems. No need to wait Matt's patch, it gives a chance to
reboot 32bit kernel on 32bit EFI today)
(8) CF9
(9) BIOS
(10) TRIPLE

Also, we should add if a new method is emerged, instead of keeping
adding those freak/endless reboot dmidecode table. Those quirks were not
supposed to be in the kernel. We should remove them.

Welcome any comments.

Thanks,
-Aubrey

> 
> So this can be finalized, add EFI after twice ACPI reboot attempt. I'll
> update the bugzilla and the patch.
> 
> Thanks,
> -Aubrey
>>
>> 	-hpa
>>
>>
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:

> Peter - Can you please clarify writing to cf9 caused some system hang.
> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
> then if no CF9, the system hangs there in  infinite for() loop. If CF9
> is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
> system hang, right? If the answer is no, can you please point me which
> system hangs by CF9. I'd like to investigate what the ACPI reboot
> vectors look like on these systems.

I think I'm fine with cf9 being in there as long as it comes after the 
ACPI calls and as long as we're using either conf1 or conf2 access.

> I know, cf9 is not an architectural way, twice ACPI call has no spec

> (1) ACPI
> (2) keyboard
> (3) ACPI
> (4) keyboard
> (5) FADT sleep register as long as it's valid(!=0)
> (6) FADT sleep registers once again(since we try ACPI twice)

ACPI is the FADT sleep register - there's no separate ACPI reboot call. 
Do you mean try this again even if the valid bit isn't set?

> (7) EFI (interesting, I found it's eventually CF9 on some my
> investigated systems. No need to wait Matt's patch, it gives a chance to
> reboot 32bit kernel on 32bit EFI today)

No. The EFI reboot call jumps into the firmware and executes code. We 
don't want to do that until we ensure that there's an appropriate 
mapping in place because the consequences could be unpleasent. There is 
code to do this, let's just wait until it's merged.

> Also, we should add if a new method is emerged, instead of keeping
> adding those freak/endless reboot dmidecode table. Those quirks were not
> supposed to be in the kernel. We should remove them.

Hey I am absolutely fine with removing DMI lists under almost all 
circumstances.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/2 1:22, Matthew Garrett wrote:
> On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:
> 
>> Peter - Can you please clarify writing to cf9 caused some system hang.
>> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
>> then if no CF9, the system hangs there in  infinite for() loop. If CF9
>> is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
>> system hang, right? If the answer is no, can you please point me which
>> system hangs by CF9. I'd like to investigate what the ACPI reboot
>> vectors look like on these systems.
> 
> I think I'm fine with cf9 being in there as long as it comes after the 
> ACPI calls and as long as we're using either conf1 or conf2 access.
> 
>> I know, cf9 is not an architectural way, twice ACPI call has no spec
> 
>> (1) ACPI
>> (2) keyboard
>> (3) ACPI
>> (4) keyboard
>> (5) FADT sleep register as long as it's valid(!=0)
>> (6) FADT sleep registers once again(since we try ACPI twice)
> 
> ACPI is the FADT sleep register - there's no separate ACPI reboot call. 
> Do you mean try this again even if the valid bit isn't set?

Yes. we already have a case that the registers is valid without the bit set.

> 
>> (7) EFI (interesting, I found it's eventually CF9 on some my
>> investigated systems. No need to wait Matt's patch, it gives a chance to
>> reboot 32bit kernel on 32bit EFI today)
> 
> No. The EFI reboot call jumps into the firmware and executes code.

Firmware actually writes CF9.


> We don't want to do that until we ensure that there's an appropriate 
> mapping in place because the consequences could be unpleasent. There is 
> code to do this, let's just wait until it's merged.

The design philosophy is as above. We didn't confirm, we try, we try to
match the user's final requirement. And it can be successful on 32bit
linux&EFI system. Do you have an explicit unpleasant result share with me?

> 
>> Also, we should add if a new method is emerged, instead of keeping
>> adding those freak/endless reboot dmidecode table. Those quirks were not
>> supposed to be in the kernel. We should remove them.
> 
> Hey I am absolutely fine with removing DMI lists under almost all 
> circumstances.
> 
I'm glad to hear this, :)

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Sun, Mar 02, 2014 at 01:31:13AM +0800, Li, Aubrey wrote:
> On 2014/3/2 1:22, Matthew Garrett wrote:
> > No. The EFI reboot call jumps into the firmware and executes code.
> 
> Firmware actually writes CF9.

Your firmware writes CF9. Other firmware may hit some other addresses. 
We don't know what the behaviour of that firmware will be if it takes a 
fault in the process.

By and large the rule when it comes to dealing with firmware interaction 
is "Copy Windows as closely as possible". Older versions of Windows 
didn't appear to hit the EFI reset vector, but if they're doing it now 
then we should do the same - but we should only do so once we have an 
expectation that it'll work rather than dumping an oops all over 
someone's screen. And, as I keep saying, the code to handle this case is 
written. Let's just make sure that your code ends up behind it in the 
queue.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

In fact, this is already merged 
(d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c), so adding EFI by default 
should be fine. It'd be nice to instrument Windows on OVMF/qemu in order 
to verify the ordering used in different situations.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/2 3:01, Matthew Garrett wrote:
> In fact, this is already merged 
> (d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c), so adding EFI by default 
> should be fine. It'd be nice to instrument Windows on OVMF/qemu in order 
> to verify the ordering used in different situations.
> 
So EFI is finalized. Thanks, -Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 03/01/2014 09:22 AM, Matthew Garrett wrote:
> On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:
> 
>> Peter - Can you please clarify writing to cf9 caused some system hang.
>> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
>> then if no CF9, the system hangs there in  infinite for() loop. If CF9
>> is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
>> system hang, right? If the answer is no, can you please point me which
>> system hangs by CF9. I'd like to investigate what the ACPI reboot
>> vectors look like on these systems.
> 
> I think I'm fine with cf9 being in there as long as it comes after the 
> ACPI calls and as long as we're using either conf1 or conf2 access.
> 

Be careful.  This is *exactly* what I tried back in checkin
14d7ca5c575853664d8fe4f225a77b8df1b7de7d.  We had to back that out quite
quickly.

This was before we had the Link: tags pointing back to the LKML
discussion, but the date (2008-11-11) and title of the patch should give
a good hint for finding the discussion I would think.

    x86: attempt reboot via port CF9 if we have standard PCI ports

    Impact: Changes reboot behavior.

    If port CF9 seems to be safe to touch, attempt it before trying the
    keyboard controller.  Port CF9 is not available on all chipsets (a
    significant but decreasing number of modern chipsets don't implement
    it), but port CF9 itself should in general be safe to poke (no ill
    effects if unimplemented) on any system which has PCI Configuration
    Method #1 or #2, as it falls inside the PCI configuration port range
    in both cases.  No chipset without PCI is known to have port CF9,
    either, although an explicit "pci=bios" would mean we miss this and
    therefore don't use port CF9.  An explicit "reboot=pci" can be used to
    force the use of port CF9.

    Signed-off-by: H. Peter Anvin <hpa@zytor.com>

	-hpa

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Sat, Mar 01, 2014 at 12:06:39PM -0800, H. Peter Anvin wrote:

> Be careful.  This is *exactly* what I tried back in checkin
> 14d7ca5c575853664d8fe4f225a77b8df1b7de7d.  We had to back that out quite
> quickly.

It's the difference between trying it before the keyboard controller and 
trying it after the keyboard controller and ACPI. It seems that it broke 
some systems where the keyboard controller worked - if we've hit the 
keyboard controller and ACPI twice, and the system is still alive, and 
if we have standard PCI ports, it doesn't seem like poking them is 
likely to make anything actively worse.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

True... trying cf9_cond with low priority probably makes sense.

On March 1, 2014 12:21:39 PM PST, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>On Sat, Mar 01, 2014 at 12:06:39PM -0800, H. Peter Anvin wrote:
>
>> Be careful.  This is *exactly* what I tried back in checkin
>> 14d7ca5c575853664d8fe4f225a77b8df1b7de7d.  We had to back that out
>quite
>> quickly.
>
>It's the difference between trying it before the keyboard controller
>and 
>trying it after the keyboard controller and ACPI. It seems that it
>broke 
>some systems where the keyboard controller worked - if we've hit the 
>keyboard controller and ACPI twice, and the system is still alive, and 
>if we have standard PCI ports, it doesn't seem like poking them is 
>likely to make anything actively worse.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

> 
> On March 1, 2014 12:21:39 PM PST, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> if we've hit the keyboard controller and ACPI twice, and the system is still alive, and 
>> if we have standard PCI ports, 

>> it doesn't seem like poking them is likely to make anything actively
worse.
> 
This is exactly what I'm trying to express. thanks Matt. It doesn't make
anything worse, it makes reboot working on some systems.

On 2014/3/2 4:26, H. Peter Anvin wrote:
> True... trying cf9_cond with low priority probably makes sense.

I'm not asking CF9 only, I'm asking all of the known method in reboot.c.
So, BIOS is appliable as well with the same logic and with low priority,
isn't it?

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 03/01/2014 04:26 PM, Li, Aubrey wrote:
>>
>> On March 1, 2014 12:21:39 PM PST, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>>> if we've hit the keyboard controller and ACPI twice, and the system is still alive, and 
>>> if we have standard PCI ports, 
> 
>>> it doesn't seem like poking them is likely to make anything actively
> worse.
>>
> This is exactly what I'm trying to express. thanks Matt. It doesn't make
> anything worse, it makes reboot working on some systems.
> 
> On 2014/3/2 4:26, H. Peter Anvin wrote:
>> True... trying cf9_cond with low priority probably makes sense.
> 
> I'm not asking CF9 only, I'm asking all of the known method in reboot.c.
> So, BIOS is appliable as well with the same logic and with low priority,
> isn't it?
> 

The problem comes in when a method doesn't just not work, but hangs the
machine.  BIOS *WILL* hang the machine if it doesn't work.  CF9 has been
known to hang the machine.

	-hpa

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/2 8:33, H. Peter Anvin wrote:
> On 03/01/2014 04:26 PM, Li, Aubrey wrote:
>>>
>>> On March 1, 2014 12:21:39 PM PST, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>>>> if we've hit the keyboard controller and ACPI twice, and the system is still alive, and 
>>>> if we have standard PCI ports, 
>>
>>>> it doesn't seem like poking them is likely to make anything actively
>> worse.
>>>
>> This is exactly what I'm trying to express. thanks Matt. It doesn't make
>> anything worse, it makes reboot working on some systems.
>>
>> On 2014/3/2 4:26, H. Peter Anvin wrote:
>>> True... trying cf9_cond with low priority probably makes sense.
>>
>> I'm not asking CF9 only, I'm asking all of the known method in reboot.c.
>> So, BIOS is appliable as well with the same logic and with low priority,
>> isn't it?
>>
> 
> The problem comes in when a method doesn't just not work, but hangs the
> machine.

If we don't do this, the machine hangs there as well. Again, we does not
make things worse.

> BIOS *WILL* hang the machine if it doesn't work.  CF9 has been
> known to hang the machine.
>

Since we are not able to make things worse, let's make it better. So
Let's dig into this. For the machine hangs by CF9, it's known to work by
KBD, right? For the machine hangs by BIOS, do you know which method will
make reboot work?

The answer will determine the sequence of the list. If BIOS hangs but
either of ACPI/KBD/EFI/CF9 works, BIOS is behind of those ways. If BIOS
hangs, no any other way can make it work. BIOS is still the last way.

If CF9 hangs while ACPI/KBD hangs as well, and BIOS happened to work(do
we really have one?), the above list still doesn't make things worse,
reboot=b and dmidecode table still work.

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 03/01/2014 05:47 PM, Li, Aubrey wrote:
> 
> Since we are not able to make things worse, let's make it better. So
> Let's dig into this. For the machine hangs by CF9, it's known to work by
> KBD, right? For the machine hangs by BIOS, do you know which method will
> make reboot work?
> 

No.

> The answer will determine the sequence of the list. If BIOS hangs but
> either of ACPI/KBD/EFI/CF9 works, BIOS is behind of those ways. If BIOS
> hangs, no any other way can make it work. BIOS is still the last way.
> 
> If CF9 hangs while ACPI/KBD hangs as well, and BIOS happened to work(do
> we really have one?), the above list still doesn't make things worse,
> reboot=b and dmidecode table still work.

We obviously have been over this a number of times, and the sad thing is
that we have very limited information.  It is more complex than that,
even... I believe in some cases KBD works but it is slow, and so takes a
while.

	-hpa

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/2 10:07, H. Peter Anvin wrote:
> On 03/01/2014 05:47 PM, Li, Aubrey wrote:
>>
>> Since we are not able to make things worse, let's make it better. So
>> Let's dig into this. For the machine hangs by CF9, it's known to work by
>> KBD, right? For the machine hangs by BIOS, do you know which method will
>> make reboot work?
>>
> 
> No.
> 
>> The answer will determine the sequence of the list. If BIOS hangs but
>> either of ACPI/KBD/EFI/CF9 works, BIOS is behind of those ways. If BIOS
>> hangs, no any other way can make it work. BIOS is still the last way.
>>
>> If CF9 hangs while ACPI/KBD hangs as well, and BIOS happened to work(do
>> we really have one?), the above list still doesn't make things worse,
>> reboot=b and dmidecode table still work.
> 
> We obviously have been over this a number of times.

This time is different, we won't touch the existing behavior, we add
success probability after that.

> and the sad thing is that we have very limited information.  It is more complex
> than that,even... I believe in some cases KBD works but it is slow,
and so takes a
> while.

This makes me to stop to consider to remove the existing dmidecode table
to be safe. But a more robust list will prevent us to add more quirks.
As long as we do not touch existing behavior, we reduce the number of
reboot hang machines in the world.

Does this make sense?

Thanks,
-Aubrey

> 
> 	-hpa
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Sat, Mar 01, 2014 at 06:07:18PM -0800, H. Peter Anvin wrote:

> We obviously have been over this a number of times, and the sad thing is
> that we have very limited information.  It is more complex than that,
> even... I believe in some cases KBD works but it is slow, and so takes a
> while.

And we still have the problem that the keyboard controller sometimes 
triggers SMM and that then hangs when it hits a piece of hardware in a 
state it doesn't expect. Sometimes reboot=b or reboot=p is just working 
around some assumptions that we could fix more convincingly.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

Of course.  It is primarily a testing problem - we just don't have a compatibility lab to test a bunch of strange hardware.

On March 1, 2014 6:23:34 PM PST, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>On Sat, Mar 01, 2014 at 06:07:18PM -0800, H. Peter Anvin wrote:
>
>> We obviously have been over this a number of times, and the sad thing
>is
>> that we have very limited information.  It is more complex than that,
>> even... I believe in some cases KBD works but it is slow, and so
>takes a
>> while.
>
>And we still have the problem that the keyboard controller sometimes 
>triggers SMM and that then hangs when it hits a piece of hardware in a 
>state it doesn't expect. Sometimes reboot=b or reboot=p is just working
>
>around some assumptions that we could fix more convincingly.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

Patch refined as below, welcome any comments.

Thanks,
-Aubrey

[PATCH] x86/reboot: Introduce all of the known reboot methods into the
default list

Reboot is the last service linux OS provides to the end user. We are
supposed to make this function more robust than today. This patch adds
all of the known reboot methods into the default attempt list. The
machines requiring reboot=efi or reboot=p or reboot=bios get a chance
to reboot automatically now.

If there is a new reboot method emerged, we are supposed to add it to
the default list as well, instead of adding the endless dmidecode entry.

If one method required is in the default list in this patch but the
machine reboot still hangs, that means some methods ahead of the
required method cause the system hangs, then reboot the machine by
passing reboot= arguments and submit the reboot dmidecode table quirk.

We are supposed to remove the reboot dmidecode table from the kernel,
but to be safe, we keep it. This patch prevents us from adding more.
If you happened to have a machine listed in the reboot dmidecode
table and this patch makes reboot work on your machine, please submit
a patch to remove the quirk.

Signed-off-by: Aubrey Li <aubrey.li@intel.com>
---
 arch/x86/kernel/reboot.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index c752cb4..807007f 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -464,9 +464,12 @@ void __attribute__((weak)) mach_reboot_fixups(void)
  * 2) If still alive, write to the keyboard controller
  * 3) If still alive, write to the ACPI reboot register again
  * 4) If still alive, write to the keyboard controller again
+ * 5) If still alive, call the EFI runtime service to reboot
+ * 6) If still alive, write to the PCI IO port 0xCF9 to reboot
+ * 7) If still alive, inform BIOS to do a proper reboot
  *
  * If the machine is still alive at this stage, it gives up. We default to
- * following the same pattern, except that if we're still alive after
(4) we'll
+ * following the same pattern, except that if we're still alive after
(7) we'll
  * try to force a triple fault and then cycle between hitting the keyboard
  * controller and doing that
  */
@@ -502,7 +505,7 @@ static void native_machine_emergency_restart(void)
 				attempt = 1;
 				reboot_type = BOOT_ACPI;
 			} else {
-				reboot_type = BOOT_TRIPLE;
+				reboot_type = BOOT_EFI;
 			}
 			break;

@@ -516,7 +519,7 @@ static void native_machine_emergency_restart(void)
 		case BOOT_BIOS:
 			machine_real_restart(MRR_BIOS);

-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_TRIPLE;
 			break;

 		case BOOT_ACPI:
@@ -530,7 +533,7 @@ static void native_machine_emergency_restart(void)
 						 EFI_RESET_WARM :
 						 EFI_RESET_COLD,
 						 EFI_SUCCESS, 0, NULL);
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_CF9;
 			break;

 		case BOOT_CF9:
@@ -548,7 +551,7 @@ static void native_machine_emergency_restart(void)
 				outb(cf9|reboot_code, 0xcf9);
 				udelay(50);
 			}
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_BIOS;
 			break;
 		}
 	}
-- 
1.7.10.4

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

We are unambiguously dead after BIOS.  There is no retry possible...

On March 2, 2014 2:39:02 AM PST, "Li, Aubrey" <aubrey.li@linux.intel.com> wrote:
>Patch refined as below, welcome any comments.
>
>Thanks,
>-Aubrey
>
>[PATCH] x86/reboot: Introduce all of the known reboot methods into the
>default list
>
>Reboot is the last service linux OS provides to the end user. We are
>supposed to make this function more robust than today. This patch adds
>all of the known reboot methods into the default attempt list. The
>machines requiring reboot=efi or reboot=p or reboot=bios get a chance
>to reboot automatically now.
>
>If there is a new reboot method emerged, we are supposed to add it to
>the default list as well, instead of adding the endless dmidecode
>entry.
>
>If one method required is in the default list in this patch but the
>machine reboot still hangs, that means some methods ahead of the
>required method cause the system hangs, then reboot the machine by
>passing reboot= arguments and submit the reboot dmidecode table quirk.
>
>We are supposed to remove the reboot dmidecode table from the kernel,
>but to be safe, we keep it. This patch prevents us from adding more.
>If you happened to have a machine listed in the reboot dmidecode
>table and this patch makes reboot work on your machine, please submit
>a patch to remove the quirk.
>
>Signed-off-by: Aubrey Li <aubrey.li@intel.com>
>---
> arch/x86/kernel/reboot.c |   13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
>diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>index c752cb4..807007f 100644
>--- a/arch/x86/kernel/reboot.c
>+++ b/arch/x86/kernel/reboot.c
>@@ -464,9 +464,12 @@ void __attribute__((weak))
>mach_reboot_fixups(void)
>  * 2) If still alive, write to the keyboard controller
>  * 3) If still alive, write to the ACPI reboot register again
>  * 4) If still alive, write to the keyboard controller again
>+ * 5) If still alive, call the EFI runtime service to reboot
>+ * 6) If still alive, write to the PCI IO port 0xCF9 to reboot
>+ * 7) If still alive, inform BIOS to do a proper reboot
>  *
>* If the machine is still alive at this stage, it gives up. We default
>to
>- * following the same pattern, except that if we're still alive after
>(4) we'll
>+ * following the same pattern, except that if we're still alive after
>(7) we'll
>* try to force a triple fault and then cycle between hitting the
>keyboard
>  * controller and doing that
>  */
>@@ -502,7 +505,7 @@ static void native_machine_emergency_restart(void)
> 				attempt = 1;
> 				reboot_type = BOOT_ACPI;
> 			} else {
>-				reboot_type = BOOT_TRIPLE;
>+				reboot_type = BOOT_EFI;
> 			}
> 			break;
>
>@@ -516,7 +519,7 @@ static void native_machine_emergency_restart(void)
> 		case BOOT_BIOS:
> 			machine_real_restart(MRR_BIOS);
>
>-			reboot_type = BOOT_KBD;
>+			reboot_type = BOOT_TRIPLE;
> 			break;
>
> 		case BOOT_ACPI:
>@@ -530,7 +533,7 @@ static void native_machine_emergency_restart(void)
> 						 EFI_RESET_WARM :
> 						 EFI_RESET_COLD,
> 						 EFI_SUCCESS, 0, NULL);
>-			reboot_type = BOOT_KBD;
>+			reboot_type = BOOT_CF9;
> 			break;
>
> 		case BOOT_CF9:
>@@ -548,7 +551,7 @@ static void native_machine_emergency_restart(void)
> 				outb(cf9|reboot_code, 0xcf9);
> 				udelay(50);
> 			}
>-			reboot_type = BOOT_KBD;
>+			reboot_type = BOOT_BIOS;
> 			break;
> 		}
> 	}

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 0:52, H. Peter Anvin wrote:
> We are unambiguously dead after BIOS.  There is no retry possible...

No really. Given that we add all of the known methods into the default
list, and BIOS is the last method, if your system hits BIOS, that means
ACPI/KBD/EFI/PCI can't make your system reboot, so BIOS should make it
work.

If you have a system can't be rebooted by all of the known methods, we
have to figure out how to make reboot work and add the new methods.

Does this make sense?

Thanks,
-Aubrey


> 
> On March 2, 2014 2:39:02 AM PST, "Li, Aubrey" <aubrey.li@linux.intel.com> wrote:
>> Patch refined as below, welcome any comments.
>>
>> Thanks,
>> -Aubrey
>>
>> [PATCH] x86/reboot: Introduce all of the known reboot methods into the
>> default list
>>
>> Reboot is the last service linux OS provides to the end user. We are
>> supposed to make this function more robust than today. This patch adds
>> all of the known reboot methods into the default attempt list. The
>> machines requiring reboot=efi or reboot=p or reboot=bios get a chance
>> to reboot automatically now.
>>
>> If there is a new reboot method emerged, we are supposed to add it to
>> the default list as well, instead of adding the endless dmidecode
>> entry.
>>
>> If one method required is in the default list in this patch but the
>> machine reboot still hangs, that means some methods ahead of the
>> required method cause the system hangs, then reboot the machine by
>> passing reboot= arguments and submit the reboot dmidecode table quirk.
>>
>> We are supposed to remove the reboot dmidecode table from the kernel,
>> but to be safe, we keep it. This patch prevents us from adding more.
>> If you happened to have a machine listed in the reboot dmidecode
>> table and this patch makes reboot work on your machine, please submit
>> a patch to remove the quirk.
>>
>> Signed-off-by: Aubrey Li <aubrey.li@intel.com>
>> ---
>> arch/x86/kernel/reboot.c |   13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
>> index c752cb4..807007f 100644
>> --- a/arch/x86/kernel/reboot.c
>> +++ b/arch/x86/kernel/reboot.c
>> @@ -464,9 +464,12 @@ void __attribute__((weak))
>> mach_reboot_fixups(void)
>>  * 2) If still alive, write to the keyboard controller
>>  * 3) If still alive, write to the ACPI reboot register again
>>  * 4) If still alive, write to the keyboard controller again
>> + * 5) If still alive, call the EFI runtime service to reboot
>> + * 6) If still alive, write to the PCI IO port 0xCF9 to reboot
>> + * 7) If still alive, inform BIOS to do a proper reboot
>>  *
>> * If the machine is still alive at this stage, it gives up. We default
>> to
>> - * following the same pattern, except that if we're still alive after
>> (4) we'll
>> + * following the same pattern, except that if we're still alive after
>> (7) we'll
>> * try to force a triple fault and then cycle between hitting the
>> keyboard
>>  * controller and doing that
>>  */
>> @@ -502,7 +505,7 @@ static void native_machine_emergency_restart(void)
>> 				attempt = 1;
>> 				reboot_type = BOOT_ACPI;
>> 			} else {
>> -				reboot_type = BOOT_TRIPLE;
>> +				reboot_type = BOOT_EFI;
>> 			}
>> 			break;
>>
>> @@ -516,7 +519,7 @@ static void native_machine_emergency_restart(void)
>> 		case BOOT_BIOS:
>> 			machine_real_restart(MRR_BIOS);
>>
>> -			reboot_type = BOOT_KBD;
>> +			reboot_type = BOOT_TRIPLE;
>> 			break;
>>
>> 		case BOOT_ACPI:
>> @@ -530,7 +533,7 @@ static void native_machine_emergency_restart(void)
>> 						 EFI_RESET_WARM :
>> 						 EFI_RESET_COLD,
>> 						 EFI_SUCCESS, 0, NULL);
>> -			reboot_type = BOOT_KBD;
>> +			reboot_type = BOOT_CF9;
>> 			break;
>>
>> 		case BOOT_CF9:
>> @@ -548,7 +551,7 @@ static void native_machine_emergency_restart(void)
>> 				outb(cf9|reboot_code, 0xcf9);
>> 				udelay(50);
>> 			}
>> -			reboot_type = BOOT_KBD;
>> +			reboot_type = BOOT_BIOS;
>> 			break;
>> 		}
>> 	}
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Mon, Mar 03, 2014 at 06:13:47AM +0800, Li, Aubrey wrote:

> If you have a system can't be rebooted by all of the known methods, we
> have to figure out how to make reboot work and add the new methods.

The only methods used by Windows are the keyboard controller, the ACPI 
registers and (according to your results) the EFI reboot mechanism. If 
none of those work under Linux but Windows is able to reboot 
successfully then we don't need to add new methods, we need to find out 
why the existing methods don't work.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 6:26, Matthew Garrett wrote:
> On Mon, Mar 03, 2014 at 06:13:47AM +0800, Li, Aubrey wrote:
> 
>> If you have a system can't be rebooted by all of the known methods, we
>> have to figure out how to make reboot work and add the new methods.
> 
> The only methods used by Windows are the keyboard controller, the ACPI 
> registers and (according to your results) the EFI reboot mechanism. If 
> none of those work under Linux but Windows is able to reboot 
> successfully then we don't need to add new methods, we need to find out 
> why the existing methods don't work.
> 

One example in my hand is, 32bit windows calls 32bit EFI firware, so
reboot works. However, I installed 64bit linux on this 32bit EFI
machine, so none of ACPI/KBD/EFI works.

Other cases even if we figured out why ACPI/KBD/EFI don't work, we still
have to make our change in the linux kernel, because we can't change
firmware.

So, if you are still suggesting we add EFI only, please let me know your
plan about adding dmidecode table and if it's acceptable to add new
tables, I have three waiting: ASUS-T100, Dell Venue 8 Pro, and Dell
Venue 11 Pro.

Or if you don't want to keep adding the dmidecode, please let me know
your plan so that I don't want to keep driving this patch.

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Mon, Mar 03, 2014 at 06:45:15AM +0800, Li, Aubrey wrote:

> One example in my hand is, 32bit windows calls 32bit EFI firware, so
> reboot works. However, I installed 64bit linux on this 32bit EFI
> machine, so none of ACPI/KBD/EFI works.

Yes. The correct fix for that is to ensure that the 64-bit kernel can 
make 32-bit runtime services calls.

> Other cases even if we figured out why ACPI/KBD/EFI don't work, we still
> have to make our change in the linux kernel, because we can't change
> firmware.

That's correct, yes. If Windows is able to reboot the system and Linux 
is not, then that's a bug in the Linux kernel.

> So, if you are still suggesting we add EFI only, please let me know your
> plan about adding dmidecode table and if it's acceptable to add new
> tables, I have three waiting: ASUS-T100, Dell Venue 8 Pro, and Dell
> Venue 11 Pro.

I don't think it's acceptable to add DMI entries to the reboot table. I 
think you should add the EFI call (since we expect that to work now), 
and I have no objection to adding cf9 to the end of the list if we have 
standard PCI io ports (Windows doesn't do it, but we can hardly make 
things worse).

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 7:11, Matthew Garrett wrote:

>> So, if you are still suggesting we add EFI only, please let me know your
>> plan about adding dmidecode table and if it's acceptable to add new
>> tables, I have three waiting: ASUS-T100, Dell Venue 8 Pro, and Dell
>> Venue 11 Pro.
> 
> I don't think it's acceptable to add DMI entries to the reboot table. I 
> think you should add the EFI call (since we expect that to work now), 
> and I have no objection to adding cf9 to the end of the list if we have 
> standard PCI io ports (Windows doesn't do it, but we can hardly make 
> things worse).
> 
Windows doesn't do because there is no 32/64 mixed windows and EFI on
the planet. Since the silicon is actually 64 bit, I failed to see a
reason to refuse the user install 64bit linux on it. So we encountered a
case windows didn't.

So, you didn't mention BOOT_BIOS, if you don't want to add BOOT_BIOS,
and you also don't like DMI entires, how do you want to deal with the
machines requiring BOOT_BIOS to reboot their machine?

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Matthew Garrett]

On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:

> Windows doesn't do because there is no 32/64 mixed windows and EFI on
> the planet. Since the silicon is actually 64 bit, I failed to see a
> reason to refuse the user install 64bit linux on it. So we encountered a
> case windows didn't.

And we'll call the 32 bit EFI call, so what's the problem?

> So, you didn't mention BOOT_BIOS, if you don't want to add BOOT_BIOS,
> and you also don't like DMI entires, how do you want to deal with the
> machines requiring BOOT_BIOS to reboot their machine?

I was planning on ignoring them.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 03/02/2014 04:07 PM, Matthew Garrett wrote:
> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
> 
>> Windows doesn't do because there is no 32/64 mixed windows and EFI on
>> the planet. Since the silicon is actually 64 bit, I failed to see a
>> reason to refuse the user install 64bit linux on it. So we encountered a
>> case windows didn't.
> 
> And we'll call the 32 bit EFI call, so what's the problem?
> 
>> So, you didn't mention BOOT_BIOS, if you don't want to add BOOT_BIOS,
>> and you also don't like DMI entires, how do you want to deal with the
>> machines requiring BOOT_BIOS to reboot their machine?
> 
> I was planning on ignoring them.
> 

I suspect we'll never get away from having a DMI table, if nothing else
because we can't test enough, but the current situation where it seems
like we need to add every since Dell box to the DMI table is clearly broken.

	-hpa

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 8:18, H. Peter Anvin wrote:
> On 03/02/2014 04:07 PM, Matthew Garrett wrote:
>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
>>
>>> Windows doesn't do because there is no 32/64 mixed windows and EFI on
>>> the planet. Since the silicon is actually 64 bit, I failed to see a
>>> reason to refuse the user install 64bit linux on it. So we encountered a
>>> case windows didn't.
>>
>> And we'll call the 32 bit EFI call, so what's the problem?

No problem after Fleming's mixed mode is landed.

>>
>>> So, you didn't mention BOOT_BIOS, if you don't want to add BOOT_BIOS,
>>> and you also don't like DMI entires, how do you want to deal with the
>>> machines requiring BOOT_BIOS to reboot their machine?
>>
>> I was planning on ignoring them.
>>

Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand, but
I'll bother you again with the same logic when I have one, heihei.
Do you need me to refine the patch to remove BOOT_BIOS?

> 
> I suspect we'll never get away from having a DMI table, if nothing else
> because we can't test enough, but the current situation where it seems
> like we need to add every since Dell box to the DMI table is clearly broken.
> 
> 	-hpa
> 
Agree, definitely.

Thanks,
-Aubrey

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

We are not removing BOOT_BIOS... whether or not we have it on buy default is another matter.

On March 2, 2014 5:36:02 PM PST, "Li, Aubrey" <aubrey.li@linux.intel.com> wrote:
>On 2014/3/3 8:18, H. Peter Anvin wrote:
>> On 03/02/2014 04:07 PM, Matthew Garrett wrote:
>>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
>>>
>>>> Windows doesn't do because there is no 32/64 mixed windows and EFI
>on
>>>> the planet. Since the silicon is actually 64 bit, I failed to see a
>>>> reason to refuse the user install 64bit linux on it. So we
>encountered a
>>>> case windows didn't.
>>>
>>> And we'll call the 32 bit EFI call, so what's the problem?
>
>No problem after Fleming's mixed mode is landed.
>
>>>
>>>> So, you didn't mention BOOT_BIOS, if you don't want to add
>BOOT_BIOS,
>>>> and you also don't like DMI entires, how do you want to deal with
>the
>>>> machines requiring BOOT_BIOS to reboot their machine?
>>>
>>> I was planning on ignoring them.
>>>
>
>Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand,
>but
>I'll bother you again with the same logic when I have one, heihei.
>Do you need me to refine the patch to remove BOOT_BIOS?
>
>> 
>> I suspect we'll never get away from having a DMI table, if nothing
>else
>> because we can't test enough, but the current situation where it
>seems
>> like we need to add every since Dell box to the DMI table is clearly
>broken.
>> 
>> 	-hpa
>> 
>Agree, definitely.
>
>Thanks,
>-Aubrey

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

On 2014/3/3 9:47, H. Peter Anvin wrote:
> We are not removing BOOT_BIOS... whether or not we have it on buy default is another matter.

Right, I meant I remove BOOT_BIOS from my second patch if needed.

Thanks,
-Aubrey

> 
> On March 2, 2014 5:36:02 PM PST, "Li, Aubrey" <aubrey.li@linux.intel.com> wrote:
>> On 2014/3/3 8:18, H. Peter Anvin wrote:
>>> On 03/02/2014 04:07 PM, Matthew Garrett wrote:
>>>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
>>>>
>>>>> Windows doesn't do because there is no 32/64 mixed windows and EFI
>> on
>>>>> the planet. Since the silicon is actually 64 bit, I failed to see a
>>>>> reason to refuse the user install 64bit linux on it. So we
>> encountered a
>>>>> case windows didn't.
>>>>
>>>> And we'll call the 32 bit EFI call, so what's the problem?
>>
>> No problem after Fleming's mixed mode is landed.
>>
>>>>
>>>>> So, you didn't mention BOOT_BIOS, if you don't want to add
>> BOOT_BIOS,
>>>>> and you also don't like DMI entires, how do you want to deal with
>> the
>>>>> machines requiring BOOT_BIOS to reboot their machine?
>>>>
>>>> I was planning on ignoring them.
>>>>
>>
>> Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand,
>> but
>> I'll bother you again with the same logic when I have one, heihei.
>> Do you need me to refine the patch to remove BOOT_BIOS?
>>
>>>
>>> I suspect we'll never get away from having a DMI table, if nothing
>> else
>>> because we can't test enough, but the current situation where it
>> seems
>>> like we need to add every since Dell box to the DMI table is clearly
>> broken.
>>>
>>> 	-hpa
>>>
>> Agree, definitely.
>>
>> Thanks,
>> -Aubrey
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[Li, Aubrey]

Do we have a conclusion here now?

Thanks,
-Aubrey


On 2014/3/3 9:49, Li, Aubrey wrote:
> On 2014/3/3 9:47, H. Peter Anvin wrote:
>> We are not removing BOOT_BIOS... whether or not we have it on buy default is another matter.
> 
> Right, I meant I remove BOOT_BIOS from my second patch if needed.
> 
> Thanks,
> -Aubrey
> 
>>
>> On March 2, 2014 5:36:02 PM PST, "Li, Aubrey" <aubrey.li@linux.intel.com> wrote:
>>> On 2014/3/3 8:18, H. Peter Anvin wrote:
>>>> On 03/02/2014 04:07 PM, Matthew Garrett wrote:
>>>>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
>>>>>
>>>>>> Windows doesn't do because there is no 32/64 mixed windows and EFI
>>> on
>>>>>> the planet. Since the silicon is actually 64 bit, I failed to see a
>>>>>> reason to refuse the user install 64bit linux on it. So we
>>> encountered a
>>>>>> case windows didn't.
>>>>>
>>>>> And we'll call the 32 bit EFI call, so what's the problem?
>>>
>>> No problem after Fleming's mixed mode is landed.
>>>
>>>>>
>>>>>> So, you didn't mention BOOT_BIOS, if you don't want to add
>>> BOOT_BIOS,
>>>>>> and you also don't like DMI entires, how do you want to deal with
>>> the
>>>>>> machines requiring BOOT_BIOS to reboot their machine?
>>>>>
>>>>> I was planning on ignoring them.
>>>>>
>>>
>>> Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand,
>>> but
>>> I'll bother you again with the same logic when I have one, heihei.
>>> Do you need me to refine the patch to remove BOOT_BIOS?
>>>
>>>>
>>>> I suspect we'll never get away from having a DMI table, if nothing
>>> else
>>>> because we can't test enough, but the current situation where it
>>> seems
>>>> like we need to add every since Dell box to the DMI table is clearly
>>> broken.
>>>>
>>>> 	-hpa
>>>>
>>> Agree, definitely.
>>>
>>> Thanks,
>>> -Aubrey
>>
> 

Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop

[H. Peter Anvin]

On 03/02/2014 02:13 PM, Li, Aubrey wrote:
> 
> No really. Given that we add all of the known methods into the default
> list, and BIOS is the last method, if your system hits BIOS, that means
> ACPI/KBD/EFI/PCI can't make your system reboot, so BIOS should make it
> work.
> 

Or it means the KBD port had delayed effects -- this is the really ugly one.

But yes, I suspect that sequence is the best that we can currently come
up with...

	-hpa

[tip:x86/reboot] x86, reboot: Add EFI and CF9 reboot methods into the default list

[tip-bot for Li, Aubrey]

Commit-ID:  a4f1987e4c5489a3877eaa7451a68d28c5a3f664
Gitweb:     http://git.kernel.org/tip/a4f1987e4c5489a3877eaa7451a68d28c5a3f664
Author:     Li, Aubrey <aubrey.li@linux.intel.com>
AuthorDate: Sun, 2 Mar 2014 18:39:02 +0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Wed, 5 Mar 2014 15:27:07 -0800

x86, reboot: Add EFI and CF9 reboot methods into the default list

Reboot is the last service linux OS provides to the end user. We are
supposed to make this function more robust than today. This patch adds
all of the known reboot methods into the default attempt list. The
machines requiring reboot=efi or reboot=p or reboot=bios get a chance
to reboot automatically now.

If there is a new reboot method emerged, we are supposed to add it to
the default list as well, instead of adding the endless dmidecode entry.

If one method required is in the default list in this patch but the
machine reboot still hangs, that means some methods ahead of the
required method cause the system hangs, then reboot the machine by
passing reboot= arguments and submit the reboot dmidecode table quirk.

We are supposed to remove the reboot dmidecode table from the kernel,
but to be safe, we keep it. This patch prevents us from adding more.
If you happened to have a machine listed in the reboot dmidecode
table and this patch makes reboot work on your machine, please submit
a patch to remove the quirk.

The default reboot order with this patch is now:

    ACPI > KBD > ACPI > KBD > EFI > CF9_COND > BIOS

Because BIOS and TRIPLE are mutually exclusive (either will either
work or hang the machine) that method is not included.

[ hpa: as with any changes to the reboot order, this patch will have
  to be monitored carefully for regressions. ]

Signed-off-by: Aubrey Li <aubrey.li@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Link: http://lkml.kernel.org/r/53130A46.1010801@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/kernel/reboot.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index c752cb4..f601295 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -464,9 +464,12 @@ void __attribute__((weak)) mach_reboot_fixups(void)
  * 2) If still alive, write to the keyboard controller
  * 3) If still alive, write to the ACPI reboot register again
  * 4) If still alive, write to the keyboard controller again
+ * 5) If still alive, call the EFI runtime service to reboot
+ * 6) If still alive, write to the PCI IO port 0xCF9 to reboot
+ * 7) If still alive, inform BIOS to do a proper reboot
  *
  * If the machine is still alive at this stage, it gives up. We default to
- * following the same pattern, except that if we're still alive after (4) we'll
+ * following the same pattern, except that if we're still alive after (7) we'll
  * try to force a triple fault and then cycle between hitting the keyboard
  * controller and doing that
  */
@@ -502,7 +505,7 @@ static void native_machine_emergency_restart(void)
 				attempt = 1;
 				reboot_type = BOOT_ACPI;
 			} else {
-				reboot_type = BOOT_TRIPLE;
+				reboot_type = BOOT_EFI;
 			}
 			break;
 
@@ -510,13 +513,15 @@ static void native_machine_emergency_restart(void)
 			load_idt(&no_idt);
 			__asm__ __volatile__("int3");
 
+			/* We're probably dead after this, but... */
 			reboot_type = BOOT_KBD;
 			break;
 
 		case BOOT_BIOS:
 			machine_real_restart(MRR_BIOS);
 
-			reboot_type = BOOT_KBD;
+			/* We're probably dead after this, but... */
+			reboot_type = BOOT_TRIPLE;
 			break;
 
 		case BOOT_ACPI:
@@ -530,7 +535,7 @@ static void native_machine_emergency_restart(void)
 						 EFI_RESET_WARM :
 						 EFI_RESET_COLD,
 						 EFI_SUCCESS, 0, NULL);
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_CF9;
 			break;
 
 		case BOOT_CF9:
@@ -548,7 +553,7 @@ static void native_machine_emergency_restart(void)
 				outb(cf9|reboot_code, 0xcf9);
 				udelay(50);
 			}
-			reboot_type = BOOT_KBD;
+			reboot_type = BOOT_BIOS;
 			break;
 		}
 	}

[tip:x86/reboot] x86, reboot: Only use CF9_COND automatically, not CF9

[tip-bot for H. Peter Anvin]

Commit-ID:  fb3bd7b19b2b6ef779d18573c10c00c53cd8add6
Gitweb:     http://git.kernel.org/tip/fb3bd7b19b2b6ef779d18573c10c00c53cd8add6
Author:     H. Peter Anvin <hpa@linux.intel.com>
AuthorDate: Wed, 5 Mar 2014 15:41:15 -0800
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Wed, 5 Mar 2014 15:41:15 -0800

x86, reboot: Only use CF9_COND automatically, not CF9

Only CF9_COND is appropriate for inclusion in the default chain, not
CF9; the latter will poke that register unconditionally, whereas
CF9_COND will at least look for PCI configuration method #1 or #2
first (a weak check, but better than nothing.)

CF9 should be used for explicit system configuration (command line or
DMI) only.

Cc: Aubrey Li <aubrey.li@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Link: http://lkml.kernel.org/r/53130A46.1010801@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/kernel/reboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index f601295..654b465 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -535,7 +535,7 @@ static void native_machine_emergency_restart(void)
 						 EFI_RESET_WARM :
 						 EFI_RESET_COLD,
 						 EFI_SUCCESS, 0, NULL);
-			reboot_type = BOOT_CF9;
+			reboot_type = BOOT_CF9_COND;
 			break;
 
 		case BOOT_CF9: