[2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

Hello,

After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.

2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).

my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt

So this is on a vaio Sz72B,
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 15)
09:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
09:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)

Any idea where to start from? (bisecting is ok, but it'll take some
time...)
-- 
mattia
:wq!

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Andrew Morton]

On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:

> Hello,
> 
> After finally catching fw-{ohci,core} to be problematic during resume,
> I'm now experiencing an immediate resume after suspending.
> 
> 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> 2.6.21-rc6-mm* after the cpuidle fixes).
> 
> my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> and a str cycle with PM_DEBUG=y:
> http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> 
> So this is on a vaio Sz72B,
> 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
> 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
> 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
> 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
> 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
> 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
> 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
> 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
> 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
> 06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
> 07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 15)
> 09:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
> 09:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
> 09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
> 
> Any idea where to start from? (bisecting is ok, but it'll take some
> time...)

Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> 
> > Hello,
> > 
> > After finally catching fw-{ohci,core} to be problematic during resume,
> > I'm now experiencing an immediate resume after suspending.
> > 
> > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > 2.6.21-rc6-mm* after the cpuidle fixes).
> > 
> > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > and a str cycle with PM_DEBUG=y:
> > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
...
> > Any idea where to start from? (bisecting is ok, but it'll take some
> > time...)
> 
> Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.

ok, git-acpi.patch is not the bad boy :)
Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
can.
I'm now bisecting this, will come to -mm1 later when done with this one.

Who is the regression-guy?
 
-- 
mattia
:wq!

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Andrew Morton]

On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:

> On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > 
> > > Hello,
> > > 
> > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > I'm now experiencing an immediate resume after suspending.
> > > 
> > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > 
> > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > and a str cycle with PM_DEBUG=y:
> > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> ...
> > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > time...)
> > 
> > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> 
> ok, git-acpi.patch is not the bad boy :)
> Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> can.
> I'm now bisecting this, will come to -mm1 later when done with this one.

OK, thanks.

> Who is the regression-guy?

Len, usually ;)    But I think you meant Michal, cc'ed here.

2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Mattia Dongili]

On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> 
> > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > 
> > > > Hello,
> > > > 
> > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > I'm now experiencing an immediate resume after suspending.
> > > > 
> > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > 
> > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > and a str cycle with PM_DEBUG=y:
> > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > ...
> > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > time...)
> > > 
> > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > 
> > ok, git-acpi.patch is not the bad boy :)
> > Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> > suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> > can.
> > I'm now bisecting this, will come to -mm1 later when done with this one.
> 
> OK, thanks.
> 
> > Who is the regression-guy?
> 
> Len, usually ;)    But I think you meant Michal, cc'ed here.

LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
added):

3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
Author: Alex Dubov <oakad@yahoo.com>
Date:   Thu Apr 12 16:59:15 2007 +1000

    tifm: replace per-adapter kthread with freezeable workqueue
    
    Freezeable workqueue makes sure that adapter work items (device insertions
    and removals) would be handled after the system is fully resumed. Previously
    this was achieved by explicit freezing of the kthread.
    
    Signed-off-by: Alex Dubov <oakad@yahoo.com>
    Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
immediately-resumes-after-str problem (unfortunately the commint doesn't
revert cleanly).
-- 
mattia
:wq!

Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Mattia Dongili]

On Sun, May 20, 2007 at 12:11:10AM +0900, Mattia Dongili wrote:
...
> I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
> immediately-resumes-after-str problem (unfortunately the commint doesn't
> revert cleanly).

as (almost) expected it is not related... tomorrow is another bisecting
day...

-- 
mattia
:wq!

Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Michal Piotrowski]

Hi,

On 19/05/07, Mattia Dongili <malattia@linux.it> wrote:
> On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> >
> > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > > I'm now experiencing an immediate resume after suspending.
> > > > >
> > > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > >
> > > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > and a str cycle with PM_DEBUG=y:
> > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > > ...
> > > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > > time...)
> > > >
> > > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > >
> > > ok, git-acpi.patch is not the bad boy :)
> > > Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> > > suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> > > can.
> > > I'm now bisecting this, will come to -mm1 later when done with this one.
> >
> > OK, thanks.
> >
> > > Who is the regression-guy?
> >
> > Len, usually ;)    But I think you meant Michal, cc'ed here.
>
> LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
> added):
>
> 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
> commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
> Author: Alex Dubov <oakad@yahoo.com>
> Date:   Thu Apr 12 16:59:15 2007 +1000
>

Subject    : Broken suspend on SMP with tifm
References : http://lkml.org/lkml/2007/5/13/161
Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
Status     : patch was suggested

Actually should be "a few patches was suggested"

Rafael, please point me the right patch.

>     tifm: replace per-adapter kthread with freezeable workqueue
>
>     Freezeable workqueue makes sure that adapter work items (device insertions
>     and removals) would be handled after the system is fully resumed. Previously
>     this was achieved by explicit freezing of the kthread.
>
>     Signed-off-by: Alex Dubov <oakad@yahoo.com>
>     Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
>
> I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
> immediately-resumes-after-str problem (unfortunately the commint doesn't
> revert cleanly).
> --
> mattia
> :wq!
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Rafael J. Wysocki]

On Saturday, 19 May 2007 19:17, Michal Piotrowski wrote:
> Hi,
> 
> On 19/05/07, Mattia Dongili <malattia@linux.it> wrote:
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > >
> > > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > > > I'm now experiencing an immediate resume after suspending.
> > > > > >
> > > > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > >
> > > > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > > and a str cycle with PM_DEBUG=y:
> > > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > > > ...
> > > > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > > > time...)
> > > > >
> > > > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > > >
> > > > ok, git-acpi.patch is not the bad boy :)
> > > > Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> > > > suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> > > > can.
> > > > I'm now bisecting this, will come to -mm1 later when done with this one.
> > >
> > > OK, thanks.
> > >
> > > > Who is the regression-guy?
> > >
> > > Len, usually ;)    But I think you meant Michal, cc'ed here.
> >
> > LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
> > added):
> >
> > 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
> > commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
> > Author: Alex Dubov <oakad@yahoo.com>
> > Date:   Thu Apr 12 16:59:15 2007 +1000
> >
> 
> Subject    : Broken suspend on SMP with tifm
> References : http://lkml.org/lkml/2007/5/13/161
> Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
> Status     : patch was suggested
> 
> Actually should be "a few patches was suggested"
> 
> Rafael, please point me the right patch.

Fixed in the mainline, by

commit e3dfd2964ea86ae65f511b10d62ea54d46db3708
make freezeable workqueues singlethread

Greetings,
Rafael

Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]

[Michal Piotrowski]

On 19/05/07, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday, 19 May 2007 19:17, Michal Piotrowski wrote:
[..]
> > Subject    : Broken suspend on SMP with tifm
> > References : http://lkml.org/lkml/2007/5/13/161
> > Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
> > Status     : patch was suggested
> >
> > Actually should be "a few patches was suggested"
> >
> > Rafael, please point me the right patch.
>
> Fixed in the mainline, by
>
> commit e3dfd2964ea86ae65f511b10d62ea54d46db3708
> make freezeable workqueues singlethread

Thanks for the information.

>
> Greetings,
> Rafael
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> 
> > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > 
> > > > Hello,
> > > > 
> > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > I'm now experiencing an immediate resume after suspending.
> > > > 
> > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > 
> > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > and a str cycle with PM_DEBUG=y:
> > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > ...
> > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > time...)
> > > 
> > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > 
> > ok, git-acpi.patch is not the bad boy :)

but very very close:
acpi-driver-model-flags-and-platform_enable_wake.patch

cheers
-- 
mattia
:wq!

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Andrew Morton]

On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <malattia@linux.it> wrote:

> On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > 
> > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > > 
> > > > > Hello,
> > > > > 
> > > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > > I'm now experiencing an immediate resume after suspending.
> > > > > 
> > > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > 
> > > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > and a str cycle with PM_DEBUG=y:
> > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > > ...
> > > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > > time...)
> > > > 
> > > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> > > 
> > > ok, git-acpi.patch is not the bad boy :)
> 
> but very very close:
> acpi-driver-model-flags-and-platform_enable_wake.patch
> 

Thanks very much for working that out - it saves lots of people heaps of
pain.  I dropped the patch.

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

On Sat, May 19, 2007 at 11:47:23PM -0700, Andrew Morton wrote:
> On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <malattia@linux.it> wrote:
> 
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
...
> > > > ok, git-acpi.patch is not the bad boy :)
> > 
> > but very very close:
> > acpi-driver-model-flags-and-platform_enable_wake.patch
> > 
> 
> Thanks very much for working that out - it saves lots of people heaps of
> pain.  I dropped the patch.

oh dear... and now, with the full series applied, I hit the
immediately-resuspend-after-resume someone already reported...

aargh
-- 
mattia
:wq!

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[David Brownell]

On Saturday 19 May 2007, Mattia Dongili wrote:
> On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > 
> > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > > 
> > > > > Hello,
> > > > > 
> > > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > > I'm now experiencing an immediate resume after suspending.
> > > > > 
> > > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > 
> > > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > and a str cycle with PM_DEBUG=y:
> > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt

Can you also provide /proc/acpi/wakeup and /proc/bus/usb/devices?
Plus "ethool eth0" and "ethtool -i eth0"?

And, for a bit more info, the output of the appended script.

(That's all *with* the patch listed below -- not reverted.)


> > > ...
> > > 
> 
> but very very close:
> acpi-driver-model-flags-and-platform_enable_wake.patch

Which only affects PCI devices at this time, FWIW ...

This is a symptom of a device or driver misbehaving.  You can
work around that; update the relevant /sys/devices/.../power/wakeup
value(s) to "disabled", pending a driver bugfix (or workaround).

In fact, you could turn them all off (see appended diagnostic
script) then turn them on one at a time to highlight problems

Reverting that patch just papers over the problem...


My suspicion, based on the dmesg and seeing what drivers actually
try to enable wakeup, would be the 'sky2' driver.  The other two
obvious candidates are EHCI (which behaves for me on non-Intel
hardware) and UHCI ... but USB has had a fair amount of testing
in terms of wakeup mechanisms, so that seems a bit less likely
to me (assuming no hardware bugs).

However, since after reverting the patch above you still saw
other problems (immediate re-suspend) I'm suspecting this isn't
a single simple problem you're finding.

- Dave


==========	CUT HERE
#!/bin/bash

# show the wakeup-capable devices and what's enabled/disabled

# class_label *:* ==> $type
class_label ()
{
	case $1 in
	# recognize common types of wakeup-capable devices
	i2c-dev:*)	type="smbus     "; return 0;;
	input:*)	type="input     "; return 0;;
	mmc_host:*)	type="mmc_host  "; return 0;;
	net:eth*)	type="lan       "; return 0;;
	net:*)		type="net       "; return 0;;
	pcmcia_socket:*)type="pcmcia    "; return 0;;
	rtc:*)		type="rtc       "; return 0;;
	sound:*)	type="modem     "; return 0;;
	tty:*)		type="tty       "; return 0;;
	usb_host:*)	type="usb_host  "; return 0;;
	esac
	return 1
}

# interface_label $PATH ==> $type
interface_label ()
{
	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		class_label $F && return
	done
}

# devtype $PATH ==> $type
devtype ()
{
	local F T

	# fixed length, currently ten spaces
	type=""

	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		if [ ! -d "$1/$F" ]
		then
			break;
		fi

		# is this a usb interface?
		if [ -f $1/$F/bInterfaceClass ]
		then
			interface_label $1/$F && return
		fi

		case $F in
		# use interface's label if possible, else generic
		usb_device:*)
			read T < $1/maxchild
			if [ 0 -lt $T ]
			then
				type="hub       "
				return
			fi
			type="(usb)     "
			continue;;
		*:*)	class_label $F && return ;;
		esac

	done

	if [ "$type" = "" ]
	then
		for T in $(cd $1 >/dev/null 2>&1 ; echo fw-host*/ieee1394_host:*)
		do
			if [ ! -L "$1/$T" ]
			then
				break;
			fi
			type="firewire  "
			return
		done
	fi

	if [ "$type" = "" ]
		then
		type="          "
	fi
}

cd /sys/devices
for F in $(find * -name 'wakeup')
do
	# F=.../power/wakeup
	read value < $F
	if [ "$value" = "" ]
	then
		continue
	fi

	# F=...
	F=$(dirname $(dirname $F))
	devtype $F

	# for each entry that actually supports wakeup, one line with:
	#  - device type (if recognized)
	#  - wake on/OFF
	#  - /sys/devices/... path
	case "$value" in
	"disabled")	echo "$type OFF $F" ;;
	"enabled")	echo "$type on  $F" ;;
	esac
done

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

On Sun, May 20, 2007 at 11:38:04AM -0700, David Brownell wrote:
> On Saturday 19 May 2007, Mattia Dongili wrote:
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > 
> > > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <malattia@linux.it> wrote:
> > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > > > I'm now experiencing an immediate resume after suspending.
> > > > > > 
> > > > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > > 
> > > > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > > and a str cycle with PM_DEBUG=y:
> > > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> 
> Can you also provide /proc/acpi/wakeup and /proc/bus/usb/devices?
> Plus "ethool eth0" and "ethtool -i eth0"?

here we go:

$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
PWRB	  S4	*enabled   
S1F0	  S4	 disabled  
S1F1	  S4	 disabled  
S1F2	  S4	 disabled  
S1F3	  S4	 disabled  
S1F4	  S4	 disabled  
S1F5	  S4	 disabled  
S1F6	  S4	 disabled  
S1F7	  S4	 disabled  
TLAN	  S3	 disabled  pci:0000:07:00.0
DLAN	  S3	 disabled  
S6F0	  S4	 disabled  
S6F1	  S4	 disabled  
S6F2	  S4	 disabled  
S6F3	  S4	 disabled  
S6F4	  S4	 disabled  
S6F5	  S4	 disabled  
S6F6	  S4	 disabled  
S6F7	  S4	 disabled  
USB1	  S3	 disabled  pci:0000:00:1d.0
USB2	  S3	 disabled  pci:0000:00:1d.1
USB3	  S3	 disabled  pci:0000:00:1d.2
USB4	  S3	 disabled  pci:0000:00:1d.3
USB7	  S3	 disabled  pci:0000:00:1d.7
SLT0	  S4	 disabled  
LANC	  S3	 disabled  
EC0	  S5	 disabled  

$ cat /proc/bus/usb/devices

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 45/900 us ( 5%), #Int=  1, #Iso=  1
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=054c ProdID=01bb Rev= 1.28
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

T:  Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=044e ProdID=300c Rev=19.15
S:  Manufacturer=ALPS
S:  Product=UGX
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0483 ProdID=2016 Rev= 0.01
S:  Manufacturer=STMicroelectronics
S:  Product=Biometric Coprocessor
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   4 Ivl=20ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=054c ProdID=0281 Rev= 4.52
S:  Manufacturer=Sony
S:  Product=UMH-U09
S:  SerialNumber=F000001C9B3A
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05ca ProdID=1830 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=06(still) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=86(I) Atr=01(Isoc) MxPS=   0 Ivl=125us
I:  If#= 0 Alt= 1 #EPs= 2 Cls=06(still) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=86(I) Atr=01(Isoc) MxPS=2048 Ivl=125us
I:  If#= 0 Alt= 2 #EPs= 2 Cls=06(still) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=86(I) Atr=01(Isoc) MxPS=3072 Ivl=125us

$ sudo ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pg
	Wake-on: d
	Current message level: 0x000000ff (255)
	Link detected: yes

$ sudo ethtool -i eth0
driver: sky2
version: 1.14
firmware-version: N/A
bus-info: 0000:07:00.0

> And, for a bit more info, the output of the appended script.

           on  acpi_system:00/device:00/PNP0C0C:00
           on  pci0000:00/0000:00:1d.7/usb1
           on  pci0000:00/0000:00:1d.7
           on  pci0000:00/0000:00:1d.3/usb5
           on  pci0000:00/0000:00:1d.3
           on  pci0000:00/0000:00:1d.2/usb4/4-1
           on  pci0000:00/0000:00:1d.2/usb4
           on  pci0000:00/0000:00:1d.2
           on  pci0000:00/0000:00:1d.1/usb3
           on  pci0000:00/0000:00:1d.1
           on  pci0000:00/0000:00:1d.0/usb2
           on  pci0000:00/0000:00:1d.0
           on  pci0000:00/0000:00:1c.2/0000:07:00.0

> (That's all *with* the patch listed below -- not reverted.)

sure :)

...
> > but very very close:
> > acpi-driver-model-flags-and-platform_enable_wake.patch
> 
> Which only affects PCI devices at this time, FWIW ...
> 
> This is a symptom of a device or driver misbehaving.  You can
> work around that; update the relevant /sys/devices/.../power/wakeup
> value(s) to "disabled", pending a driver bugfix (or workaround).
> 
> In fact, you could turn them all off (see appended diagnostic
> script) then turn them on one at a time to highlight problems
> 
> Reverting that patch just papers over the problem...
> 
> 
> My suspicion, based on the dmesg and seeing what drivers actually
> try to enable wakeup, would be the 'sky2' driver.  The other two

FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod,
modprobe and ifup again to get some networking...

> obvious candidates are EHCI (which behaves for me on non-Intel
> hardware) and UHCI ... but USB has had a fair amount of testing
> in terms of wakeup mechanisms, so that seems a bit less likely
> to me (assuming no hardware bugs).
> 
> However, since after reverting the patch above you still saw
> other problems (immediate re-suspend) I'm suspecting this isn't
> a single simple problem you're finding.

eheheh, bisecting this one too, let's see...

Thanks
-- 
mattia
:wq!

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[David Brownell]

On Sunday 20 May 2007, Mattia Dongili wrote:
> 
> $ cat /proc/acpi/wakeup
> Device	S-state	  Status   Sysfs node
> PWRB	  S4	*enabled   
> S1F0	  S4	 disabled  
> S1F1	  S4	 disabled  
> S1F2	  S4	 disabled  
> S1F3	  S4	 disabled  
> S1F4	  S4	 disabled  
> S1F5	  S4	 disabled  
> S1F6	  S4	 disabled  
> S1F7	  S4	 disabled  
> TLAN	  S3	 disabled  pci:0000:07:00.0
> DLAN	  S3	 disabled  
> S6F0	  S4	 disabled  
> S6F1	  S4	 disabled  
> S6F2	  S4	 disabled  
> S6F3	  S4	 disabled  
> S6F4	  S4	 disabled  
> S6F5	  S4	 disabled  
> S6F6	  S4	 disabled  
> S6F7	  S4	 disabled  
> USB1	  S3	 disabled  pci:0000:00:1d.0
> USB2	  S3	 disabled  pci:0000:00:1d.1
> USB3	  S3	 disabled  pci:0000:00:1d.2
> USB4	  S3	 disabled  pci:0000:00:1d.3
> USB7	  S3	 disabled  pci:0000:00:1d.7
> SLT0	  S4	 disabled  
> LANC	  S3	 disabled  
> EC0	  S5	 disabled  

That's strangely busy ... what ARE all those devices?  :)

But only the PCI ones -- or certain devices connected to USB
root hubs -- could be affected by that patch.

So another experiment you could do, if you want faster info
than "git bisect" can provide, is building drivers for those
PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then
finding which one causes the trouble by removing them before
STR.


> $ cat /proc/bus/usb/devices
> 
> T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
> B:  Alloc= 45/900 us ( 5%), #Int=  1, #Iso=  1
> D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=0000 ProdID=0000 Rev= 2.06
> S:  Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
> S:  Product=UHCI Host Controller
> S:  SerialNumber=0000:00:1d.3
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
                          ^^
Just FYI, any USB device with the 0x20 bit set could in
some cases become a wakeup event source.  All hubs (root
and otherwise) set that.  So do a couple of the devices
you show ...

> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
> E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
> 
> ...
> 
> T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
> D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0483 ProdID=2016 Rev= 0.01
> S:  Manufacturer=STMicroelectronics
> S:  Product=Biometric Coprocessor
> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
                          ^^
This one does.  I seem to recall hearing about some trouble associated
with this and sleep/wakeup processing, but I forget about the
details.


> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
> E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=83(I) Atr=03(Int.) MxPS=   4 Ivl=20ms
> 
> ...
> 
> 
> $ sudo ethtool eth0
> Settings for eth0:
> 	Supported ports: [ TP ]
> 	Supported link modes:   10baseT/Half 10baseT/Full 
> 	                        100baseT/Half 100baseT/Full 
> 	                        1000baseT/Half 1000baseT/Full 
> 	Supports auto-negotiation: Yes
> 	Advertised link modes:  10baseT/Half 10baseT/Full 
> 	                        100baseT/Half 100baseT/Full 
> 	Advertised auto-negotiation: Yes
> 	Speed: 100Mb/s
> 	Duplex: Full
> 	Port: Twisted Pair
> 	PHYAD: 0
> 	Transceiver: internal
> 	Auto-negotiation: on
> 	Supports Wake-on: pg
> 	Wake-on: d

So wake-on-LAN is disabled here ... it *should* avoid
turning on the PCI wake mechanisms.  On the other hand,
a quick look at that driver shows that it's rather
broken in how it calls pci_enable_wake().


> 	Current message level: 0x000000ff (255)
> 	Link detected: yes
> 
> $ sudo ethtool -i eth0
> driver: sky2
> version: 1.14
> firmware-version: N/A
> bus-info: 0000:07:00.0
> 
> > And, for a bit more info, the output of the appended script.
> 
>            on  acpi_system:00/device:00/PNP0C0C:00
>            on  pci0000:00/0000:00:1d.7/usb1
>            on  pci0000:00/0000:00:1d.7
>            on  pci0000:00/0000:00:1d.3/usb5
>            on  pci0000:00/0000:00:1d.3
>            on  pci0000:00/0000:00:1d.2/usb4/4-1
>            on  pci0000:00/0000:00:1d.2/usb4
>            on  pci0000:00/0000:00:1d.2
>            on  pci0000:00/0000:00:1d.1/usb3
>            on  pci0000:00/0000:00:1d.1
>            on  pci0000:00/0000:00:1d.0/usb2
>            on  pci0000:00/0000:00:1d.0
>            on  pci0000:00/0000:00:1c.2/0000:07:00.0

Other than the curious lack of labeling on the USB and
network nodes there (maybe the script cares about the
legacy sysfs files? it's a couple years old now) that
doesn't say anything new.


> > My suspicion, based on the dmesg and seeing what drivers actually
> > try to enable wakeup, would be the 'sky2' driver.  The other two
> 
> FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod,
> modprobe and ifup again to get some networking...

Try "rmmod sky2" *before* suspend, to see if that matters.

Also "rmmod uhci-hcd", which will keep USB from doing anything
with that biometric thingie.

I suspect one or the other of those will be the issue.

- Dave

Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR

[Mattia Dongili]

On Sun, May 20, 2007 at 06:22:23PM -0700, David Brownell wrote:
> On Sunday 20 May 2007, Mattia Dongili wrote:
> > 
> > $ cat /proc/acpi/wakeup
> > Device	S-state	  Status   Sysfs node
> > PWRB	  S4	*enabled   
> > S1F0	  S4	 disabled  
> > S1F1	  S4	 disabled  
> > S1F2	  S4	 disabled  
> > S1F3	  S4	 disabled  
> > S1F4	  S4	 disabled  
> > S1F5	  S4	 disabled  
> > S1F6	  S4	 disabled  
> > S1F7	  S4	 disabled  
> > TLAN	  S3	 disabled  pci:0000:07:00.0
> > DLAN	  S3	 disabled  
> > S6F0	  S4	 disabled  
> > S6F1	  S4	 disabled  
> > S6F2	  S4	 disabled  
> > S6F3	  S4	 disabled  
> > S6F4	  S4	 disabled  
> > S6F5	  S4	 disabled  
> > S6F6	  S4	 disabled  
> > S6F7	  S4	 disabled  
> > USB1	  S3	 disabled  pci:0000:00:1d.0
> > USB2	  S3	 disabled  pci:0000:00:1d.1
> > USB3	  S3	 disabled  pci:0000:00:1d.2
> > USB4	  S3	 disabled  pci:0000:00:1d.3
> > USB7	  S3	 disabled  pci:0000:00:1d.7
> > SLT0	  S4	 disabled  
> > LANC	  S3	 disabled  
> > EC0	  S5	 disabled  
> 
> That's strangely busy ... what ARE all those devices?  :)

the S[16]F* are tons of acpi devices... don't know what they are, they
are attached to the PCI-E port
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
if you're interested the DSDT is here:
http://www.linux.it/~malattia/sony-laptop/DSDT.sz72b.type3.dsl

> But only the PCI ones -- or certain devices connected to USB
> root hubs -- could be affected by that patch.
> 
> So another experiment you could do, if you want faster info
> than "git bisect" can provide, is building drivers for those
> PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then
> finding which one causes the trouble by removing them before
> STR.

it's ehci-hcd! and apart from the fact that removing it causes a BUG in
cpufreq no the system stays correctly asleep when suspended.

...
> > > My suspicion, based on the dmesg and seeing what drivers actually
> > > try to enable wakeup, would be the 'sky2' driver.  The other two
> > 
> > FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod,
> > modprobe and ifup again to get some networking...
> 
> Try "rmmod sky2" *before* suspend, to see if that matters.
> 
> Also "rmmod uhci-hcd", which will keep USB from doing anything
> with that biometric thingie.
> 
> I suspect one or the other of those will be the issue.

very close :)
-- 
mattia
:wq!