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
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.
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"
> wrote:
>> On
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" 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
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
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
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
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
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
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
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
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
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
We are unambiguously dead after BIOS. There is no retry possible...
On March 2, 2014 2:39:02 AM PST, "Li, Aubrey" 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
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
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
We are unambiguously dead after BIOS. There is no retry possible...
On March 2, 2014 2:39:02 AM PST, Li, Aubrey aubrey...@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
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
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
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
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
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
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.
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
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 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
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...@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
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...@linux.intel.com
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 wrote:
>On Sat, Mar 01, 2014 at 06:07:18PM -0800, H. Peter Anvin wrote:
>
>> We obviously have been over this a number of
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.
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
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.
>
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
>>> wrote:
if we've hit the keyboard controller and ACPI twice, and the system is
still alive, and
if we have standard PCI ports,
>>
On 03/01/2014 04:26 PM, Li, Aubrey wrote:
>>
>> On March 1, 2014 12:21:39 PM PST, Matthew Garrett
>> 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
>
> On March 1, 2014 12:21:39 PM PST, Matthew Garrett 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
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
True... trying cf9_cond with low priority probably makes sense.
On March 1, 2014 12:21:39 PM PST, Matthew Garrett 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.
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
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
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 | mj...@srcf.ucam.org
--
To unsubscribe from
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
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
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
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
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
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
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
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
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 | mj...@srcf.ucam.org
--
To unsubscribe from
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
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
True... trying cf9_cond with low priority probably makes sense.
On March 1, 2014 12:21:39 PM PST, Matthew Garrett mj...@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
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.
On March 1, 2014 12:21:39 PM PST, Matthew Garrett mj...@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
On 03/01/2014 04:26 PM, Li, Aubrey wrote:
On March 1, 2014 12:21:39 PM PST, Matthew Garrett mj...@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
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 mj...@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
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
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
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
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 mj...@srcf.ucam.org wrote:
On Sat, Mar 01, 2014 at 06:07:18PM -0800, H. Peter Anvin wrote:
We obviously have been over
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
88 matches
Mail list logo
