Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

References: http://bugzilla.kernel.org/show_bug.cgi?id=8246

Blacklist R40e, R51e and T40, T40p, T41, T41p, T42, T42p, R50 and R50p ThinkPads to use the RSDT instead of the XSDT.

Quoted 6 lines · Thomas Renninger

Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

References: http://bugzilla.kernel.org/show_bug.cgi?id=8246

Blacklist R40e, R51e and T40, T40p, T41, T41p, T42, T42p, R50 and R50p ThinkPads to use the RSDT instead of the XSDT.

I'm very sceptical about this. All of these machines were released years before Vista, which makes me unsure about the diagnosis that this is something to do with Vista readyness.

Quoted 11 lines · Matthew Garrett

Quoted 6 lines · Thomas Renninger

Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

References: http://bugzilla.kernel.org/show_bug.cgi?id=8246

Blacklist R40e, R51e and T40, T40p, T41, T41p, T42, T42p, R50 and R50p ThinkPads to use the RSDT instead of the XSDT.

I'm very sceptical about this. All of these machines were released years before Vista, which makes me unsure about the diagnosis that this is something to do with Vista readyness.

I believe you will find stuff broken due to Vista Readyness badly retro-fitted only on the Z-series and also the T60.

The R51e (BIOS TP-78) does NOT share a BIOS with the T40-T42 or any of the two R51 base models. The bugzilla bug report really cannot be used against them. Thomas, do you have extra data not in the bug report that causes you to doubt the TP-1R BIOS?

The others (these BIOSes seem to not be shared between that many machines) were tested that this patchset fixes sever bugs:
- system freeze when using C-states on R40e
- much faster booting on R50e

Quoted 4 lines · Thomas Renninger

The others (these BIOSes seem to not be shared between that many machines) were tested that this patchset fixes sever bugs:
- system freeze when using C-states on R40e
- much faster booting on R50e

I'm still not happy with just DMIing this. If Windows is behaving differently in terms of choosing which values to use, we should be duplicating that behaviour - there may well be other affected systems. Working around it for these specific machines just means it'll take longer to fix properly. Thomas, can Lenovo provide any information about why this hardware works in Windows?

I'm still not happy...

As said, probably because Vista is not supported at all or not showing the symptoms.

It's also very unlikely other machines show that. It looks like they started Vista support and left it half broken. If others show that, they now at least have a boot param to test if it helps.

Quoted 2 lines · Thomas Renninger

As said, probably because Vista is not supported at all or not showing the symptoms.

But *why* is Vista not showing the symptoms?

values in the table were never caught because, for some reason, Windows never used them. The bug is that we're not using the same heuristic as Windows. Applying a static list of hardware just results in it being likely that we'll never fix that bug.

Quoted 1 line · Matthew Garrett

But *why* is Vista not showing the symptoms?

I very much doubt anyone ever attempted to run Vista on a R40e or a R50e. It probably won't work well on the T4x/R51/R52 either, but I haven't tried.

Quoted 4 lines

values in the table were never caught because, for some reason, Windows never used them. The bug is that we're not using the same heuristic as Windows. Applying a static list of hardware just results in it being likely that we'll never fix that bug.

I am a bit lost, now. Are you talking about newer ThinkPads with Vista-capable BIOSes, or the older ones that can't handle it and thus are only subject to some ACPI access patterns when running Linux?

Quoted 5 lines · Henrique de Moraes Holschuh

Quoted 1 line · Matthew Garrett

But *why* is Vista not showing the symptoms?

I very much doubt anyone ever attempted to run Vista on a R40e or a R50e. It probably won't work well on the T4x/R51/R52 either, but I haven't tried.

I'd be surprised if nobody has done it. The hardware is above the minimum spec.

Quoted 8 lines

Quoted 4 lines

values in the table were never caught because, for some reason, Windows never used them. The bug is that we're not using the same heuristic as Windows. Applying a static list of hardware just results in it being likely that we'll never fix that bug.

I am a bit lost, now. Are you talking about newer ThinkPads with Vista-capable BIOSes, or the older ones that can't handle it and thus are only subject to some ACPI access patterns when running Linux?

The R40e and R50e have differing values in the RSDT and XSDT tables. Linux uses the values from the XSDT, which apparently results in a system hang whenever you attempt to perform C-state manipulation. Using the RSDT values instead avoids this. Windows works fine, so is clearly using the RSDT values. However, we have no knowledge of what mechanism Windows uses to choose between the two sets of values.

Quoted 2 lines · Matthew Garrett

I'd be surprised if nobody has done it. The hardware is above the minimum spec.

I'd ask someone that did before I assume it worked fine (i.e. "does it suspend and resume to RAM properly when running XP? when running Vista?")...

Quoted 7 lines · Henrique de Moraes Holschuh

Quoted 2 lines · Matthew Garrett

I'd be surprised if nobody has done it. The hardware is above the minimum spec.

I'd ask someone that did before I assume it worked fine (i.e. "does it suspend and resume to RAM properly when running XP? when running Vista?")...

C state transitions, not S state. Working properly here means not hanging the moment ACPI processor power management starts.

Quoted 2 lines · Matthew Garrett

C state transitions, not S state. Working properly here means not hanging the moment ACPI processor power management starts.

I see, but my point remains. Does a version of Windows that was tested to do C-state transitions on the R50e and R40e even use the XSDT?

Quoted 6 lines · Henrique de Moraes Holschuh

Quoted 2 lines · Matthew Garrett

C state transitions, not S state. Working properly here means not hanging the moment ACPI processor power management starts.

I see, but my point remains. Does a version of Windows that was tested to do C-state transitions on the R50e and R40e even use the XSDT?

Vista is known to run on the R50e. See
http://forums.lenovo.com/lnv/board/message?board.id=R_Series_Thinkpads&thread.id=3467
, for instance.

Quoted 6 lines · Henrique de Moraes Holschuh

Quoted 2 lines · Matthew Garrett

C state transitions, not S state. Working properly here means not hanging the moment ACPI processor power management starts.

I see, but my point remains. Does a version of Windows that was tested to do C-state transitions on the R50e and R40e even use the XSDT?

Vista is known to run on the R50e. See
http://forums.lenovo.com/lnv/board/message?board.id=R_Series_Thinkpads&thre
ad.id=3467 , for instance.

Quoted 6 lines · Henrique de Moraes Holschuh

Quoted 2 lines · Matthew Garrett

C state transitions, not S state. Working properly here means not hanging the moment ACPI processor power management starts.

I see, but my point remains. Does a version of Windows that was tested to do C-state transitions on the R50e and R40e even use the XSDT?

Vista is known to run on the R50e. See
http://forums.lenovo.com/lnv/board/message?board.id=R_Series_Thinkpads&thre
ad.id=3467 , for instance.

Quoted 6 lines · Henrique de Moraes Holschuh

Quoted 1 line · Matthew Garrett

But *why* is Vista not showing the symptoms?

I very much doubt anyone ever attempted to run Vista on a R40e or a R50e. It probably won't work well on the T4x/R51/R52 either, but I haven't tried.

I'd be surprised if nobody has done it. The hardware is above the minimum spec.

Quoted 8 lines

Quoted 4 lines

values in the table were never caught because, for some reason, Windows never used them. The bug is that we're not using the same heuristic as Windows. Applying a static list of hardware just results in it being likely that we'll never fix that bug.

I am a bit lost, now. Are you talking about newer ThinkPads with Vista-capable BIOSes, or the older ones that can't handle it and thus are only subject to some ACPI access patterns when running Linux?

The R40e and R50e have differing values in the RSDT and XSDT tables. Linux uses the values from the XSDT, which apparently results in a system hang whenever you attempt to perform C-state manipulation. Using the RSDT values instead avoids this. Windows works fine, so is clearly using the RSDT values. However, we have no knowledge of what mechanism Windows uses to choose between the two sets of values.

Yes we have:
- XP uses 32 bit addresses
- Vista uses the newer FADT revision and there the 64 bit addresses.

This information is from BIOS engineers who should know Windows behaviour much better than we ever could.

Quoted 4 lines · Thomas Renninger

Yes we have:
- XP uses 32 bit addresses
- Vista uses the newer FADT revision and there the 64 bit addresses.

Quoted 2 lines

This information is from BIOS engineers who should know Windows behaviour much better than we ever could.

If Vista is absolutely known to *always* use the 64-bit addresses under every single circumstance where they're present, then yes, I agree that this is probably the least bad situation. This is trivial to test - install Vista on an R40e and see if it hangs on boot. If it does, I withdraw my objection. If not, then we're not fixing it properly.

If Vista is absolutely known to *always* use the 64-bit addresses under every single circumstance where they're present, then yes I agree that ...

Even if this is not proven, the patchset should still go in to get the machines fixed for now and to easily test others, there was enough discussion around it.

Quoted 3 lines · Thomas Renninger

Even if this is not proven, the patchset should still go in to get the machines fixed for now and to easily test others, there was enough discussion around it.

What do you mean, "fixed"? They all already work, even if it's in a suboptimal way.

Quoted 5 lines · On Tuesday 21 October 2008 15:08:36 Matthew Garrett wrote:

Quoted 3 lines · Thomas Renninger

Even if this is not proven, the patchset should still go in to get the machines fixed for now and to easily test others, there was enough discussion around it.

Quoted 2 lines

What do you mean, "fixed"? They all already work, even if it's in a suboptimal way.

If C-states don't work and do work with a patch. I call the patch a fix. I also call the machine broken (even if it does boot) before and fixed afterwards.

I also call a machine broken which takes minutes to boot and fixed as soon as the problem is solved and the machine is booting in a reasonable amount of time.

Moreover, as soon as the real fix is developed we can remove the DMI list. Quite frankly, I don't see any downsides.

Quoted 2 lines · Rafael J. Wysocki

Moreover, as soon as the real fix is developed we can remove the DMI list. Quite frankly, I don't see any downsides.

The downside is that with the DMI list there's significantly less incentive to produce a "real" fix (assuming there is one). We've no idea how many other systems may be affected in one way or another.

Quoted 3 lines · On Tuesday 21 October 2008 16:00:14 Matthew Garrett wrote:

The downside is that with the DMI list there's significantly less incentive to produce a "real" fix (assuming there is one). We've no idea how many other systems may be affected in one way or another.

With the boot param you at least get an idea how many other sytems are affected.

Quoted 2 lines · Rafael J. Wysocki

Moreover, as soon as the real fix is developed we can remove the DMI list. Quite frankly, I don't see any downsides.

The downside is that with the DMI list there's significantly less incentive to produce a "real" fix (assuming there is one).

We've no idea how many other systems may be affected in one way or another.

Quoted 1 line · Matthew Garrett

We've no idea how many other systems may be affected in one way or another.

Yes, and the list may help us to get an idea IMO.

Quoted 5 lines · Rafael J. Wysocki

Quoted 2 lines · Matthew Garrett

We've no idea how many other systems may be affected in one way or another.

Yes, and the list may help us to get an idea IMO.

How? We *know* we're deviating from the behaviour of Windows here.

What
we don't know is how that will affect different machines. we'll end up with a bunch of "Well, I added this boot option and then my system booted slightly faster" and have no ability to work out whether the problem's actually related. See the number of people who reported that acpi_apic_instance made a difference, or even the fact that Thomas included a bunch of systems with no real assurance that they were hit by this.

A static list will eventually end up either filled with false positives or missing several machines that should be there.

Quoted 1 line · On Tuesday 21 October 2008 16:29:56 Matthew Garrett wrote:

How? We *know* we're deviating from the behaviour of Windows here.

Matthew, there is no solution to stick to the Windows behaviour. Even if hundreds of machines are affected, you have still not yet come up with a generic solution, but try to block the fix.

Quoted 4 lines · Rafael J. Wysocki

Quoted 1 line · Matthew Garrett

We've no idea how many other systems may be affected in one way or another.

Yes, and the list may help us to get an idea IMO.

How? We *know* we're deviating from the behaviour of Windows here. What we don't know is how that will affect different machines. I suspect we'll end up with a bunch of "Well, I added this boot option and then my system booted slightly faster" and have no ability to work out whether the problem's actually related.

See the number of people who reported that acpi_apic_instance made a difference, or even the fact that Thomas included a bunch of systems with no real assurance that they were hit by this.

A static list will eventually end up either filled with false positives or missing several machines that should be there.

Quoted 5 lines · Matthew Garrett

How? We *know* we're deviating from the behaviour of Windows here. What we don't know is how that will affect different machines. I suspect we'll end up with a bunch of "Well, I added this boot option and then my system booted slightly faster" and have no ability to work out whether the problem's actually related.

Well, this is similar to suspend problems where many different issues may give the same symptom. In these cases we also often have very limited possibility to figure out why some particular workaround actually works on given machine type, but with no access to the machine and with a bug reporter who can't compile the kernel himself all we can do is to verify that it sort of works. By putting the machine into a blacklist we can at least make Linux more usable to the user in question, which also is important.

Quoted 3 lines

See the number of people who reported that acpi_apic_instance made a difference, or even the fact that Thomas included a bunch of systems with no real assurance that they were hit by this.

Hm, this is not a good thing. Is there any reliable way to verify that?

Right, but in this case we understand the root cause of the problem - we behave differently to Windows in a very specific way. What we don't understand are the precise circumstances in which Windows behaves that way. It could be that Vista always uses the 64-bit addresses if available, and in that case this is the best possible solution. But it could also be that Vista swaps addresses based on whether _INI requests the Vista OSI or not. It could be that Vista uses the 32-bit addresses on 32-bit CPUs. Or where the addresses differ and there's a valid 32-bit entry, perhaps they use that. When there's a simple test to perform, we should do that before adding a static list.

Quoted 4 lines

Quoted 3 lines

See the number of people who reported that acpi_apic_instance made a difference, or even the fact that Thomas included a bunch of systems with no real assurance that they were hit by this.

Quoted 1 line

Hm, this is not a good thing. Is there any reliable way to verify that?

We can verify whether the addresses are actually different, but it's possible that that's harmless on some machines. However, history suggests that there's a placebo effect in adding boot options...

This is all nice and true, HOWEVER apparently all of us lack the hardware
and lab setup to perform the testing. And I haven't seen anyone publish
clear instructions we could ask a Vista user to do, either.

Quoted 3 lines · Henrique de Moraes Holschuh

This is all nice and true, HOWEVER apparently all of us lack the hardware
and lab setup to perform the testing. And I haven't seen anyone publish
clear instructions we could ask a Vista user to do, either.

Boot Vista on R40e. If machine hangs after ACPI is brought up, Vista uses 64-bit addresses under all circumstances.

Quoted 2 lines · Matthew Garrett

Boot Vista on R40e. If machine hangs after ACPI is brought up, Vista uses 64-bit addresses under all circumstances.

Is it hanging on Linux?

Quoted 7 lines · Matthew Garrett

Quoted 3 lines · Henrique de Moraes Holschuh

This is all nice and true, HOWEVER apparently all of us lack the hardware
and lab setup to perform the testing. And I haven't seen anyone publish
clear instructions we could ask a Vista user to do, either.

Boot Vista on R40e. If machine hangs after ACPI is brought up, Vista uses 64-bit addresses under all circumstances.

Is it hanging on Linux?

Anyway, I just asked if anyone managed to install Vista on the R40e in the thinkpad forums. Let's hope some kind soul with a R40e will reply. But I am against holding these patches any further. If we find a better way to do things in the future, we deal with it then.

Quoted 6 lines · Thomas Renninger

Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

References: http://bugzilla.kernel.org/show_bug.cgi?id=8246

Blacklist R40e, R51e and T40, T40p, T41, T41p, T42, T42p, R50 and R50p ThinkPads to use the RSDT instead of the XSDT.

I'm very sceptical about this. All of these machines were released years before Vista, which makes me unsure about the diagnosis that this is something to do with Vista readyness.

I'm very sceptical about this

Quoted 8 lines · On Monday 20 October 2008 03:01:42 Matthew Garrett wrote:

Quoted 6 lines · Thomas Renninger

Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt

References: http://bugzilla.kernel.org/show_bug.cgi?id=8246

Blacklist R40e, R51e and T40, T40p, T41, T41p, T42, T42p, R50 and R50p ThinkPads to use the RSDT instead of the XSDT.

Quoted 3 lines

I'm very sceptical about this. All of these machines were released years before Vista, which makes me unsure about the diagnosis that this is something to do with Vista readyness.

I sent you a link to BIOS updates where the last changelog entry stated VISTA support. Hmm, I double checked R40e and R50e and there is nothing about VISTA support.
Nevertheless, this would mean the addresses used by Linux are not supported.

XP uses the 32 bit adresses. Vista the 64 bit adresses.

Could you please point to a specific problem you have with the patches, these are safe, tested and verified fixes.

The rest share one BIOS and have been added in hope that this bug gets solved, but this is not proven:
T41p shutting down due to "temperature critical"
https://bugzilla.novell.com/show_bug.cgi?id=378327
I saw a kind of fixed temperature offset with the exact same machine models and exact same BIOS. Short after cold boot the one machine showed about 15 degree C more than the other. This looked like wrong, too high temperature values read from EC on the one machine. I never found out why, this could explain and fix it, but I did not double check.

Quoted 9 lines · Thomas Renninger

The rest share one BIOS and have been added in hope that this bug gets solved, but this is not proven:
T41p shutting down due to "temperature critical"
https://bugzilla.novell.com/show_bug.cgi?id=378327
I saw a kind of fixed temperature offset with the exact same machine models and exact same BIOS. Short after cold boot the one machine showed about 15 degree C more than the other. This looked like wrong, too high temperature values read from EC on the one machine. I never found out why, this could explain and fix it, but I did not double check.

How is using the RSDT instead of XSDT going to help with that?

I've now had confirmation from multiple sources that Vista still uses the 32-bit addresses for the GPE blocks.

We're actually seeing the same
bug on some currently shipping machines

, so again I'm going to suggest
that the blacklist model isn't going to scale and we should just behave like Windows. How about this patch instead? It does some sanity checking, so I doubt that there's any way it could break a legitimate system. I've left IA64 as-is because it seems more likely that there'd be a requirement for 64-bit setups there.

Signed-off-by Matthew Garrett <[email protected]>

---

Are there even any ACPI platforms where a system io address can be greater than 32 bits? It's limited to 16 bits on x86, so I *really* don't think this is going to break anything. The FADTs I've checked from Thinkpads all seem to have valid 32-bit addresses even using the one obtained from the XSDT.

(quoted diff) +0 -0

b/drivers/acpi/events/evgpeblk.c index 73c058e..eed35d7 100644

drivers/acpi/events/evgpeblk.c +26 -0

@@ -1107,6 +1107,32 @@ acpi_status acpi_ev_gpe_initialize(void)
 	 */
 
 	/*
+	 * The ACPI specification says that we should use the 64-bit
+	 * address offset for the GPE blocks if it exists. However,
+	 * Windows uses the legacy address. Various vendors have left
+	 * incorrect values in the 64-bit field, which then causes
+	 * problems later. Since the vast majority of machines have
+	 * never been tested with an OS that uses the 64-bit value by
+	 * default, we should behave like Windows and ignore the spec
+	 * by only using the 64-bit address if it contains something
+	 * that can't be represented in the legacy field. Since system
+	 * io space is only 16 bits on x86, this should be entirely
+	 * safe.
+	 */
+
+#ifdef CONFIG_X86
+	if (acpi_gbl_FADT.gpe0_block &&
+	    acpi_gbl_FADT.xgpe0_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe0_block.address =
+			(u64)acpi_gbl_FADT.gpe0_block;
+
+	if (acpi_gbl_FADT.gpe1_block &&
+	    acpi_gbl_FADT.xgpe1_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe1_block.address =
+			(u64)acpi_gbl_FADT.gpe1_block;
+#endif
+
+	/*
 	 * Determine the maximum GPE number for this machine.
 	 *
 	 * Note: both GPE0 and GPE1 are optional, and either can exist without

Quoted 2 lines · Matthew Garrett

I've now had confirmation from multiple sources that Vista still uses the 32-bit addresses for the GPE blocks.

Are you sure that Windows Server implementations also use 32-bit addresses?

Are you sure that upcoming Windows implementations will always use 32-bit addresses?

Do all X86 machines support Windows or could there be machines, especially servers which only support Mac OS, Solaris/Linux or other OSes which stick to the spec which you break with this change?

Quoted 2 lines

We're actually seeing the same
bug on some currently shipping machines

Which ones?

I also disagree with violating the spec unconditionally, breaking machines which would stick to it. It's likely that machines do not get a latest mainline kernel tests. Once this change is in distributions and machines do break, people are busted. There should at least be a boot param to switch back.

We might come away with it. But I have the strong feeling that there are machines running better using 32-bit and machines running better with 64-bit addresses used.

Quoted 2 lines · Matthew Garrett

I've now had confirmation from multiple sources that Vista still uses the 32-bit addresses for the GPE blocks.

Are you sure that Windows Server implementations also use 32-bit addresses? Are you sure that upcoming Windows implementations will always use 32-bit addresses?
Do all X86 machines support Windows or could there be machines, especially servers which only support Mac OS, Solaris/Linux or other OSes which stick to the spec which you break with this change?

Quoted 2 lines

We're actually seeing the same
bug on some currently shipping machines

Which ones?

Quoted 6 lines

, so again I'm going to suggest
that the blacklist model isn't going to scale and we should just behave like Windows. How about this patch instead? It does some sanity checking, so I doubt that there's any way it could break a legitimate system. I've left IA64 as-is because it seems more likely that there'd be a requirement for 64-bit setups there.

If at all, this should not be added for .28, but for .29 and stay in linux-next for a while.
I wonder why all (hmm, hard to say, at least a lot) recent machines have valid 64 bit addresses.
I also disagree with violating the spec unconditionally, breaking machines which would stick to it. It's likely that machines do not get a latest mainline kernel tests. Once this change is in distributions and machines do break, people are busted. There should at least be a boot param to switch back.

We might come away with it. But I have the strong feeling that there are machines running better using 32-bit and machines running better with 64-bit addresses used.

Thomas

Quoted 45 lines

Signed-off-by Matthew Garrett <[email protected]>

---

Are there even any ACPI platforms where a system io address can be greater than 32 bits? It's limited to 16 bits on x86, so I *really* don't think this is going to break anything. The FADTs I've checked from Thinkpads all seem to have valid 32-bit addresses even using the one obtained from the XSDT.

(quoted diff) +0 -0

b/drivers/acpi/events/evgpeblk.c index 73c058e..eed35d7 100644

drivers/acpi/events/evgpeblk.c +26 -0

@@ -1107,6 +1107,32 @@ acpi_status acpi_ev_gpe_initialize(void)
 	 */
 
 	/*
+	 * The ACPI specification says that we should use the 64-bit
+	 * address offset for the GPE blocks if it exists. However,
+	 * Windows uses the legacy address. Various vendors have left
+	 * incorrect values in the 64-bit field, which then causes
+	 * problems later. Since the vast majority of machines have
+	 * never been tested with an OS that uses the 64-bit value by
+	 * default, we should behave like Windows and ignore the spec
+	 * by only using the 64-bit address if it contains something
+	 * that can't be represented in the legacy field. Since system
+	 * io space is only 16 bits on x86, this should be entirely
+	 * safe.
+	 */
+
+#ifdef CONFIG_X86
+	if (acpi_gbl_FADT.gpe0_block &&
+	    acpi_gbl_FADT.xgpe0_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe0_block.address =
+			(u64)acpi_gbl_FADT.gpe0_block;
+
+	if (acpi_gbl_FADT.gpe1_block &&
+	    acpi_gbl_FADT.xgpe1_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe1_block.address =
+			(u64)acpi_gbl_FADT.gpe1_block;
+#endif
+
+	/*
 	 * Determine the maximum GPE number for this machine.

drivers/acpi/events/evgpeblk.c acpi_status acpi_ev_gpe_initialize(void) · line 1138

Quoted 2 lines

drivers/acpi/events/evgpeblk.c +0 -0

 	 *
 	 * Note: both GPE0 and GPE1 are optional, and either can exist without

_______________________________________________
Devel mailing list
[email protected]
https://lists.acpica.org/mailman/listinfo/devel

I have a test box which suspends well, but always reboots instead of resuming when pressing the power button.
I found that there are two FACS tables on this platform, XSDT-->FADT1-->Xfacs------>FACS1

	|----->facs-----|
			|->FACS2
RSDT-->FADT2-->facs-----|

Linux uses XSDT on this platform and sets the waking vector in FACS1 when suspending. But it seems that the BIOS only cares for the waking vector in FACS2, thus it reboots when resuming because the waking vector is not set at all.

My original proposal is to install both FADT1.Xfacs and FADT1.facs in to the global table list and set the waking vectors on both of them. now it seems that switching back to RSDT if multiple valid FACS tables exists is also a solution for this issue.

Quoted 11 lines · Zhang Rui

I have a test box which suspends well, but always reboots instead of resuming when pressing the power button.
I found that there are two FACS tables on this platform, XSDT-->FADT1-->Xfacs------>FACS1

	|----->facs-----|
			|->FACS2
RSDT-->FADT2-->facs-----|

Linux uses XSDT on this platform and sets the waking vector in FACS1 when suspending. But it seems that the BIOS only cares for the waking vector in FACS2, thus it reboots when resuming because the waking vector is not set at all.

That makes it sound like we should be using the 32-bit value in this case as well.

Quoted 4 lines

My original proposal is to install both FADT1.Xfacs and FADT1.facs in to the global table list and set the waking vectors on both of them. now it seems that switching back to RSDT if multiple valid FACS tables exists is also a solution for this issue.

Why? If there's a FADT entry in the XSDT we might as well use it - all the machines I've checked contain valid information in the 32-bit entry of the FADT there.

Quoted 4 lines · Matthew Garrett

Why? If there's a FADT entry in the XSDT we might as well use it - all the machines I've checked contain valid information in the 32-bit entry of the FADT there.

do you mean always using FADT1.facs and ignore the FADT.Xfacs in Linux?