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 neede
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 2014/3/3
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 wr
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 po
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 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'
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-bi
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 ke
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 (accordi
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 rebo
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 las
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
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 t
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.
An
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
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.
> Th
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 ma
>
> 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 I
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 finaliz
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 a
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 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 thi
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 wha
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 i
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 mean
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 boxe
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 c
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 M
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 ri
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 atte
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 dea
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: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 refer
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
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
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
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 Ve
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 AC
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
44 matches
Mail list logo