Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[fanderay]

Hi,

I have a Vaio SR19VN (Radeon HD 3400 video) and resume after
suspend-to-ram fails with 2.6.30rc2/x86_64.  I have been testing with
the s2ram tool using the approach described at
http://en.opensuse.org/S2ram.  None of the s2ram options changes the
behavior, which is that the system freezes hard while attempting to
resume (screen stays off/black) and must be physically powered down.
The caps-lock test fails, which suggests this is more than just a
video problem.  Suspend/resume actually did work with the stock Debian
lenny kernel (2.6.26/amd64).  The kernel config is pasted at
http://pastebin.com/mb4dd790.  Any idea what might be wrong?

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[Rafael J. Wysocki]

On Monday 20 April 2009, fanderay wrote:
> Hi,

Hi,

> I have a Vaio SR19VN (Radeon HD 3400 video) and resume after
> suspend-to-ram fails with 2.6.30rc2/x86_64.  I have been testing with
> the s2ram tool using the approach described at
> http://en.opensuse.org/S2ram.  None of the s2ram options changes the
> behavior, which is that the system freezes hard while attempting to
> resume (screen stays off/black) and must be physically powered down.
> The caps-lock test fails, which suggests this is more than just a
> video problem.  Suspend/resume actually did work with the stock Debian
> lenny kernel (2.6.26/amd64).  The kernel config is pasted at
> http://pastebin.com/mb4dd790.  Any idea what might be wrong?

Have you tried to suspend after booting with init=/bin/bash ?
You'll need to mount /sys and /proc manually before the suspend for it to work.

Also it might be worth checking if anything changes with the fglrx binary
driver.

Thanks,
Rafael

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[fanderay]

On Mon, Apr 20, 2009 at 9:53 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> I have a Vaio SR19VN (Radeon HD 3400 video) and resume after
>> suspend-to-ram fails with 2.6.30rc2/x86_64.  I have been testing with
>> the s2ram tool using the approach described at
>> http://en.opensuse.org/S2ram.  None of the s2ram options changes the
>> behavior, which is that the system freezes hard while attempting to
>> resume (screen stays off/black) and must be physically powered down.
>> The caps-lock test fails, which suggests this is more than just a
>> video problem.  Suspend/resume actually did work with the stock Debian
>> lenny kernel (2.6.26/amd64).  The kernel config is pasted at
>> http://pastebin.com/mb4dd790.  Any idea what might be wrong?
>
> Have you tried to suspend after booting with init=/bin/bash ?
> You'll need to mount /sys and /proc manually before the suspend for it to work.
>
> Also it might be worth checking if anything changes with the fglrx binary
> driver.

Thanks, Rafael.  Yes, all my tests were run by booting with
init=/bin/bash and conducted at the console, so no X.  So it seems
like something quite low-level is broken.

> Thanks,
> Rafael

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[Rafael J. Wysocki]

On Tuesday 21 April 2009, fanderay wrote:
> On Mon, Apr 20, 2009 at 9:53 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> I have a Vaio SR19VN (Radeon HD 3400 video) and resume after
> >> suspend-to-ram fails with 2.6.30rc2/x86_64.  I have been testing with
> >> the s2ram tool using the approach described at
> >> http://en.opensuse.org/S2ram.  None of the s2ram options changes the
> >> behavior, which is that the system freezes hard while attempting to
> >> resume (screen stays off/black) and must be physically powered down.
> >> The caps-lock test fails, which suggests this is more than just a
> >> video problem.  Suspend/resume actually did work with the stock Debian
> >> lenny kernel (2.6.26/amd64).  The kernel config is pasted at
> >> http://pastebin.com/mb4dd790.  Any idea what might be wrong?
> >
> > Have you tried to suspend after booting with init=/bin/bash ?
> > You'll need to mount /sys and /proc manually before the suspend for it to work.
> >
> > Also it might be worth checking if anything changes with the fglrx binary
> > driver.
> 
> Thanks, Rafael.  Yes, all my tests were run by booting with
> init=/bin/bash and conducted at the console, so no X.  So it seems
> like something quite low-level is broken.

Please try if booting with acpi_sleep=old_ordering changes anything.

Best,
Rafael

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[fanderay]

On Tue, Apr 21, 2009 at 2:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

> Please try if booting with acpi_sleep=old_ordering changes anything.

Thanks, I tried various permutations of s2ram options together with
the acpi_sleep=old_ordering kernel option, but this did not change the
behavior at all.  I can also now confirm that resume after s2ram -f -p
works with the stock Debian 2.6.29 kernel.  So either the problem
appeared between .29 and .30rc2, or it's being tickled by something in
my kernel config (posted earlier).

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[Rafael J. Wysocki]

On Tuesday 21 April 2009, fanderay wrote:
> On Tue, Apr 21, 2009 at 2:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > Please try if booting with acpi_sleep=old_ordering changes anything.
> 
> Thanks, I tried various permutations of s2ram options together with
> the acpi_sleep=old_ordering kernel option, but this did not change the
> behavior at all.  I can also now confirm that resume after s2ram -f -p
> works with the stock Debian 2.6.29 kernel.  So either the problem
> appeared between .29 and .30rc2, or it's being tickled by something in
> my kernel config (posted earlier).

Well, unfortunately both are possible.  You can use scripts/diffconfig (in the
kernel source tree) to check differences between your configuration and the
debian one (if available).

Thanks,
Rafael

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[Rafael J. Wysocki]

On Tuesday 21 April 2009, fanderay wrote:
> On Tue, Apr 21, 2009 at 2:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 
> > Please try if booting with acpi_sleep=old_ordering changes anything.
> 
> Thanks, I tried various permutations of s2ram options together with
> the acpi_sleep=old_ordering kernel option, but this did not change the
> behavior at all.  I can also now confirm that resume after s2ram -f -p
> works with the stock Debian 2.6.29 kernel.  So either the problem
> appeared between .29 and .30rc2, or it's being tickled by something in
> my kernel config (posted earlier).

BTW, could you test .29 build from the same .config you use for building
.30-rc2?

Best,
Rafael

Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2

[fanderay]

Hi Rafael,

I found the problem: it's the Sony laptop driver.  With
CONFIG_SONY_LAPTOP=y, the hard freeze on resume occurs.  Without this
driver in the kernel, resume after s2ram -f -p appears to work
correctly.

[Regression] sony-laptop breaks resume from S2RAM (was: Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2)

[Rafael J. Wysocki]

On Wednesday 22 April 2009, fanderay wrote:
> Hi Rafael,
> 
> I found the problem: it's the Sony laptop driver.  With
> CONFIG_SONY_LAPTOP=y, the hard freeze on resume occurs.  Without this
> driver in the kernel, resume after s2ram -f -p appears to work
> correctly.

It seems to be an ACPI problem, then.  Added some CCs.

Thanks,
Rafael

Re: [Regression] sony-laptop breaks resume from S2RAM (was: Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2)

[fanderay]

On Wed, Apr 22, 2009 at 9:02 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> Hi Rafael,
>>
>> I found the problem: it's the Sony laptop driver.  With
>> CONFIG_SONY_LAPTOP=y, the hard freeze on resume occurs.  Without this
>> driver in the kernel, resume after s2ram -f -p appears to work
>> correctly.
>
> It seems to be an ACPI problem, then.  Added some CCs.

Thanks, I raised bug <http://bugzilla.kernel.org/show_bug.cgi?id=13148>.

> Thanks,
> Rafael

Re: [Regression] sony-laptop breaks resume from S2RAM (was: Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2)

[Mattia Dongili]

On Wed, Apr 22, 2009 at 09:35:13PM +0100, fanderay wrote:
> On Wed, Apr 22, 2009 at 9:02 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> Hi Rafael,
> >>
> >> I found the problem: it's the Sony laptop driver.  With
> >> CONFIG_SONY_LAPTOP=y, the hard freeze on resume occurs.  Without this

what happens if you configure it as a module instead?

> >> driver in the kernel, resume after s2ram -f -p appears to work
> >> correctly.
> >
> > It seems to be an ACPI problem, then.  Added some CCs.
> 
> Thanks, I raised bug <http://bugzilla.kernel.org/show_bug.cgi?id=13148>.

I'll try to reproduce it.

Almer,
you have an SR too, do you see the same problem as fanderay?

Thanks
-- 
mattia
:wq!

Re: [Regression] sony-laptop breaks resume from S2RAM (was: Re: Resume after suspend-to-ram broken for Vaio SR19VN in 30rc2)

[Almer S. Tigelaar]

Hi Mattia,

On Thu, 2009-04-23 at 21:50 +0900, Mattia Dongili wrote:
> On Wed, Apr 22, 2009 at 09:35:13PM +0100, fanderay wrote:
> > >> CONFIG_SONY_LAPTOP=y, the hard freeze on resume occurs.  Without this
> > >> driver in the kernel, resume after s2ram -f -p appears to work
> > >> correctly.
>
> Almer,
> you have an SR too, do you see the same problem as fanderay?

This problem does not occur with 2.6.30-rc2 for me (when using
sony-laptop as a module). It comes out of the resume just fine.

Note that this is with an Sony SR39VN, which is a newer version of the
SR model than fanderay's. If the same problem persists for him (even
when loading it as a module): I suspect this might be a firmware / BIOS
version issue.

Sidenote: I can not see many interesting differences between the DSDT's
of the two models (see below).

With kind regards,

Almer S. Tigelaar

--- SR19VN.dsl	2009-04-26 17:46:01.000000000 +0200
+++ SR39VN.dsl	2009-04-26 17:46:27.000000000 +0200
@@ -2,20 +2,20 @@
  * Intel ACPI Component Architecture
  * AML Disassembler version 20061109
  *
- * Disassembly of dsdt.bin, Thu Apr 23 17:48:38 2009
+ * Disassembly of DSDT.aml, Mon Mar  2 21:06:47 2009
  *
  *
  * Original Table Header:
  *     Signature        "DSDT"
- *     Length           0x0000857E (34174)
+ *     Length           0x00008505 (34053)
  *     Revision         0x01
  *     OEM ID           "Sony"
  *     OEM Table ID     "VAIO"
- *     OEM Revision     0x20081231 (537399857)
+ *     OEM Revision     0x20081113 (537399571)
  *     Creator ID       "INTL"
  *     Creator Revision 0x20051117 (537202967)
  */
-DefinitionBlock ("dsdt.aml", "DSDT", 1, "Sony", "VAIO", 0x20081231)
+DefinitionBlock ("DSDT.aml", "DSDT", 1, "Sony", "VAIO", 0x20081113)
 {
     External (PDC3)
     External (PDC2)
@@ -94,7 +94,7 @@
     Name (PDBR, 0x4D)
     Name (TPMF, 0x01)
     Name (SMBL, 0x10)
-    OperationRegion (GNVS, SystemMemory, 0xBDEEFD90, 0x0100)
+    OperationRegion (GNVS, SystemMemory, 0xBDEEDD90, 0x0100)
     Field (GNVS, AnyAcc, Lock, Preserve)
     {
         OSYS,   16, 
@@ -219,7 +219,7 @@
 
     Scope (\_SB)
     {
-        Name (PR00, Package (0x16)
+        Name (PR00, Package (0x15)
         {
             Package (0x04)
             {
@@ -311,14 +311,6 @@
 
             Package (0x04)
             {
-                0x001AFFFF, 
-                0x03, 
-                LNKC, 
-                0x00
-            }, 
-
-            Package (0x04)
-            {
                 0x001BFFFF, 
                 0x00, 
                 LNKG, 
@@ -397,7 +389,7 @@
                 0x00
             }
         })
-        Name (AR00, Package (0x16)
+        Name (AR00, Package (0x15)
         {
             Package (0x04)
             {
@@ -489,14 +481,6 @@
 
             Package (0x04)
             {
-                0x001AFFFF, 
-                0x03, 
-                0x00, 
-                0x12
-            }, 
-
-            Package (0x04)
-            {
                 0x001BFFFF, 
                 0x00, 
                 0x00, 
@@ -6221,7 +6205,7 @@
         }
     }
 
-    OperationRegion (SMI0, SystemMemory, 0xBDF04B90, 0x0420)
+    OperationRegion (SMI0, SystemMemory, 0xBDF05B90, 0x0420)
     Field (SMI0, AnyAcc, NoLock, Preserve)
     {
         BCMD,   8, 
@@ -6673,13 +6657,6 @@
                         Notify (\_SB.PCI0.LPCB.SNC, 0x93)
                     }
 
-                    Method (_Q43, 0, NotSerialized)
-                    {
-                        P8XH (0x00, 0x43)
-                        Or (\_SB.PCI0.LPCB.SNC.ESR, 0x08, \_SB.PCI0.LPCB.SNC.ESR)
-                        Notify (\_SB.PCI0.LPCB.SNC, 0x93)
-                    }
-
                     Name (MB1P, 0x81)
                     Name (MB1R, 0x01)
                     Name (MB2P, 0x82)