From: Rafael J. Wysocki <[email protected]>
ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
HP xw4600 Workstation is known to require the "old" (ie. compatible
with ACPI 1.0) suspend code ordering, so blacklist it for this
purpose.
Signed-off-by: Rafael J. Wysocki <[email protected]>
Tested-by: John Brown <[email protected]>
---
drivers/acpi/sleep/main.c | 8 ++++++++
1 file changed, 8 insertions(+)
Index: linux-2.6/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6/drivers/acpi/sleep/main.c
@@ -298,6 +298,14 @@ static struct dmi_system_id __initdata a
DMI_MATCH(DMI_BOARD_NAME, "KN9 Series(NF-CK804)"),
},
},
+ {
+ .callback = init_old_suspend_ordering,
+ .ident = "HP xw4600 Workstation",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
+ },
+ },
{},
};
#endif /* CONFIG_SUSPEND */
On Tue, Oct 14, 2008 at 10:54:06PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[email protected]>
>
> ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
>
> HP xw4600 Workstation is known to require the "old" (ie. compatible
> with ACPI 1.0) suspend code ordering, so blacklist it for this
> purpose.
This doesn't seem to be scaling especially well. The xw4600 is a new
machine, so if it needs the "old" code ordering then that's a strong
indication that we're doing something wrong. I think trying to work out
what would be more useful than just adding it to a blacklist.
--
Matthew Garrett | [email protected]
On Wednesday, 15 of October 2008, Matthew Garrett wrote:
> On Tue, Oct 14, 2008 at 10:54:06PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[email protected]>
> >
> > ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
> >
> > HP xw4600 Workstation is known to require the "old" (ie. compatible
> > with ACPI 1.0) suspend code ordering, so blacklist it for this
> > purpose.
>
> This doesn't seem to be scaling especially well. The xw4600 is a new
> machine, so if it needs the "old" code ordering then that's a strong
> indication that we're doing something wrong.
No, sorry.
> I think trying to work out what would be more useful than just adding it to
> a blacklist.
Well, machines that require the "old" ordering are simply broken, because
you just can't assume that specific devices are not in D3 before you
execute _PTS.
IOW, we aren't doing anything wrong and the BIOS is buggy.
Thanks,
Rafael
On Wed, Oct 15, 2008 at 04:05:35PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 15 of October 2008, Matthew Garrett wrote:
> > I think trying to work out what would be more useful than just adding it to
> > a blacklist.
>
> Well, machines that require the "old" ordering are simply broken, because
> you just can't assume that specific devices are not in D3 before you
> execute _PTS.
>
> IOW, we aren't doing anything wrong and the BIOS is buggy.
So how does Windows cope with this?
--
Matthew Garrett | [email protected]
I don't know the technical details behind *how* Windows copes with it, but I can tell you that it works fine on Windows. Naturally we'd like it to work fine on Linux, too, and Rafael's blacklist fix accomplishes that. There may be other solutions to this issue on Linux that are worth looking into, but perhaps we can accept Rafael's fix as a workaround for now.
BTW, there is probably at least one more fairly recent vintage HP workstation that will require this same fix. My testing isn't complete yet, though.
John
-----Original Message-----
From: Matthew Garrett [mailto:[email protected]]
Sent: Wednesday, October 15, 2008 8:15 AM
To: Rafael J. Wysocki
Cc: Len Brown; ACPI Devel Maling List; Andrew Morton; LKML; Brown, John M (WGBU R&D)
Subject: Re: [PATCH] ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
On Wed, Oct 15, 2008 at 04:05:35PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 15 of October 2008, Matthew Garrett wrote:
> > I think trying to work out what would be more useful than just
> > adding it to a blacklist.
>
> Well, machines that require the "old" ordering are simply broken,
> because you just can't assume that specific devices are not in D3
> before you execute _PTS.
>
> IOW, we aren't doing anything wrong and the BIOS is buggy.
So how does Windows cope with this?
--
Matthew Garrett | [email protected]
On Wednesday, 15 of October 2008, Matthew Garrett wrote:
> On Wed, Oct 15, 2008 at 04:05:35PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 15 of October 2008, Matthew Garrett wrote:
> > > I think trying to work out what would be more useful than just adding it to
> > > a blacklist.
> >
> > Well, machines that require the "old" ordering are simply broken, because
> > you just can't assume that specific devices are not in D3 before you
> > execute _PTS.
> >
> > IOW, we aren't doing anything wrong and the BIOS is buggy.
>
> So how does Windows cope with this?
I don't know. :-(
One possible explanation is that the device causing the trouble is not put
into D3 at all during suspend, but I'm speculating here.
Thanks,
Rafael
Matthew,
You are right, of course, we're not doing something right
if a new machine needs this workaround.
However, we don't yet know what we're not doing right:-)
Until we figure that out, the blacklist is a practical way
forward. There have been several cases in the past where
we grew a blacklist -- some of them quite large,
before we figured out what bug-compatibility
magic we needed in order to delete the blacklist.
I'm hopeful the same story will play out here.
applied.
thanks,
-Len
On Wednesday, 15 of October 2008, Len Brown wrote:
> Matthew,
> You are right, of course, we're not doing something right
> if a new machine needs this workaround.
Isn't that possible, however, that the BIOS of this new machine is based on an
older one that used to have this problem?
> However, we don't yet know what we're not doing right:-)
Well, John, can you please post the output of acpidump from this machine?
Thanks,
Rafael
> From: Rafael J. Wysocki <[email protected]>
>
> ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
>
> HP xw4600 Workstation is known to require the "old" (ie. compatible
> with ACPI 1.0) suspend code ordering, so blacklist it for this
> purpose.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> Tested-by: John Brown <[email protected]>
ACK.
> ---
> drivers/acpi/sleep/main.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> Index: linux-2.6/drivers/acpi/sleep/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/acpi/sleep/main.c
> +++ linux-2.6/drivers/acpi/sleep/main.c
> @@ -298,6 +298,14 @@ static struct dmi_system_id __initdata a
> DMI_MATCH(DMI_BOARD_NAME, "KN9 Series(NF-CK804)"),
> },
> },
> + {
> + .callback = init_old_suspend_ordering,
> + .ident = "HP xw4600 Workstation",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP xw4600 Workstation"),
> + },
> + },
> {},
> };
> #endif /* CONFIG_SUSPEND */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> On Tue, Oct 14, 2008 at 10:54:06PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[email protected]>
> >
> > ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
> >
> > HP xw4600 Workstation is known to require the "old" (ie. compatible
> > with ACPI 1.0) suspend code ordering, so blacklist it for this
> > purpose.
>
> This doesn't seem to be scaling especially well. The xw4600 is a new
> machine, so if it needs the "old" code ordering then that's a strong
> indication that we're doing something wrong. I think trying to work out
> what would be more useful than just adding it to a blacklist.
HP seems pretty responsive in this case, you are welcome to work with
them...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi folks -
Attached is a txt file with output of acpidump for the xw4600.
I also noted that acpidump printed this message to stderr:
Wrong checksum for FADT!
Can any of you tell me what that message implies?
Thanks,
John
-----Original Message-----
From: Rafael J. Wysocki [mailto:[email protected]]
Sent: Wednesday, October 15, 2008 4:01 PM
To: Len Brown
Cc: Brown, John M (WGBU R&D); Matthew Garrett; ACPI Devel Maling List; Andrew Morton; LKML
Subject: Re: [PATCH] ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
On Wednesday, 15 of October 2008, Len Brown wrote:
> Matthew,
> You are right, of course, we're not doing something right if a new
> machine needs this workaround.
Isn't that possible, however, that the BIOS of this new machine is based on an older one that used to have this problem?
> However, we don't yet know what we're not doing right:-)
Well, John, can you please post the output of acpidump from this machine?
Thanks,
Rafael
> I also noted that acpidump printed this message to stderr:
> Wrong checksum for FADT!
The RSDT has a pointer to an FACP at DEFC2014 (aka FADT),
and that FACP has a bad checksum.
But this system has an XSDT, which the OS prefers
over the RSDT. The XSDT points to an FACP at DEFC2088
and its checksum is fine.
This difference is moot here,
because both FACP's point to the same DSDT at DEFC2647,
and it is the DSDT that has the AML related to ordering.
The reason you see this error message from acpidump
and not from Linux is that the kernel only uses the 'active'
tables, while acpidump snags both the active and insactive tables
for debugging.
cheers,
-Len
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:[email protected]]
> Sent: Wednesday, October 15, 2008 4:01 PM
> To: Len Brown
> Cc: Brown, John M (WGBU R&D); Matthew Garrett; ACPI Devel Maling List; Andrew Morton; LKML
> Subject: Re: [PATCH] ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering
>
> On Wednesday, 15 of October 2008, Len Brown wrote:
> > Matthew,
> > You are right, of course, we're not doing something right if a new
> > machine needs this workaround.
>
> Isn't that possible, however, that the BIOS of this new machine is based on an older one that used to have this problem?
>
> > However, we don't yet know what we're not doing right:-)
>
> Well, John, can you please post the output of acpidump from this machine?
>
> Thanks,
> Rafael
>
Rafael J. Wysocki wrote:
> On Wednesday, 15 of October 2008, Len Brown wrote:
>> Matthew,
>> You are right, of course, we're not doing something right
>> if a new machine needs this workaround.
>
> Isn't that possible, however, that the BIOS of this new machine is based on an
> older one that used to have this problem?
Maybe, but it doesn't matter. If it's a new machine it's presumably
going to work fine on Vista, etc. so it doesn't make much sense that
this machine should require the old ACPI code ordering.
On Wednesday 15 October 2008 22:20:05 Rafael J. Wysocki wrote:
> > > IOW, we aren't doing anything wrong and the BIOS is buggy.
> >
> > So how does Windows cope with this?
>
> I don't know. :-(
>
> One possible explanation is that the device causing the trouble is not put
> into D3 at all during suspend, but I'm speculating here.
Do we know which device it is that causes the trouble on this HP box?
-Carlos
--
E-Mail: [email protected]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
On Saturday, 22 of November 2008, Carlos Corbacho wrote:
> On Wednesday 15 October 2008 22:20:05 Rafael J. Wysocki wrote:
> > > > IOW, we aren't doing anything wrong and the BIOS is buggy.
> > >
> > > So how does Windows cope with this?
> >
> > I don't know. :-(
> >
> > One possible explanation is that the device causing the trouble is not put
> > into D3 at all during suspend, but I'm speculating here.
>
> Do we know which device it is that causes the trouble on this HP box?
Not really, but most probably is one of the USB controllers. Hopefully, we'll
find out.
Thanks,
Rafael