[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!

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

[Zhang Rui]

On Sun, 2007-05-20 at 15:14 +0900, 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
> > > ...
> > > > > 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
> 
Hi, Mattia,

I tested this patch on several platforms but can not reproduce the bug.
Could you please help me do a simple test please?

Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
acpi-driver-model-flags-and-platform_enable_wake.patch.

Try to enable the wakeup GPE for all the USB devices first.
e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
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

Try STR and check if it resumes immediately after suspend.
I think the same problem will happen without this patch.

Thanks,
Rui

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

[Mattia Dongili]

On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
> On Sun, 2007-05-20 at 15:14 +0900, 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
> > > > ...
> > > > > > 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
> > 
> Hi, Mattia,
> 
> I tested this patch on several platforms but can not reproduce the bug.
> Could you please help me do a simple test please?
> 
> Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> acpi-driver-model-flags-and-platform_enable_wake.patch.
> 
> Try to enable the wakeup GPE for all the USB devices first.
> e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> 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
> 
> Try STR and check if it resumes immediately after suspend.
> I think the same problem will happen without this patch.

ok, building right now.
Anyway, I don't remember the details but ehci and uhci were already
spotted as being part of the problem. See the rest of the thread
starting here http://lkml.org/lkml/2007/5/20/223

Anyway I'm currently on 22-rc4-mm1 and having problems (=not even
suspending) but lack the necessary time to investigate/bisect
-- 
mattia
:wq!

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

[Zhang Rui]

On Tue, 2007-06-19 at 18:30 +0900, Mattia Dongili wrote:
> On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
> > On Sun, 2007-05-20 at 15:14 +0900, 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
> > > > > ...
> > > > > > > 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
> > > 
> > Hi, Mattia,
> > 
> > I tested this patch on several platforms but can not reproduce the bug.
> > Could you please help me do a simple test please?
> > 
> > Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> > acpi-driver-model-flags-and-platform_enable_wake.patch.
> > 
> > Try to enable the wakeup GPE for all the USB devices first.
> > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > 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
> > 
> > Try STR and check if it resumes immediately after suspend.
> > I think the same problem will happen without this patch.
> 
> ok, building right now.
> Anyway, I don't remember the details but ehci and uhci were already
> spotted as being part of the problem. See the rest of the thread
> starting here http://lkml.org/lkml/2007/5/20/223
> 
Yes, I've noticed this.

The above test is just to confirm that
acpi-driver-model-flags-and-platform_enable_wake.patch is not the root
cause of the problem.
Buggy drivers may cause this problem, but I can not debug further as I
can not reproduce this bug here.

> Anyway I'm currently on 22-rc4-mm1 and having problems (=not even
> suspending) but lack the necessary time to investigate/bisect
That's ok.
It would be great if you can verify the problem still exists,
i.e. try STR with this patch applied. :)

thanks,
Rui

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

[Mattia Dongili]

On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
...
> I tested this patch on several platforms but can not reproduce the bug.
> Could you please help me do a simple test please?
>
> Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> acpi-driver-model-flags-and-platform_enable_wake.patch.

2.6.22-rc5 *without* the patch

> Try to enable the wakeup GPE for all the USB devices first.
> e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> 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
> 
> Try STR and check if it resumes immediately after suspend.
> I think the same problem will happen without this patch.

only after enabling USB7 the broken behaviour showed.

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)

Quite consistent with the other findings.

Cheers
-- 
mattia
:wq!

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

[Rafael J. Wysocki]

On Tuesday, 19 June 2007 11:55, Zhang Rui wrote:
> On Tue, 2007-06-19 at 18:30 +0900, Mattia Dongili wrote:
> > On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
> > > On Sun, 2007-05-20 at 15:14 +0900, 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
> > > > > > ...
> > > > > > > > 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
> > > > 
> > > Hi, Mattia,
> > > 
> > > I tested this patch on several platforms but can not reproduce the bug.
> > > Could you please help me do a simple test please?
> > > 
> > > Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> > > acpi-driver-model-flags-and-platform_enable_wake.patch.
> > > 
> > > Try to enable the wakeup GPE for all the USB devices first.
> > > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > > 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
> > > 
> > > Try STR and check if it resumes immediately after suspend.
> > > I think the same problem will happen without this patch.
> > 
> > ok, building right now.
> > Anyway, I don't remember the details but ehci and uhci were already
> > spotted as being part of the problem. See the rest of the thread
> > starting here http://lkml.org/lkml/2007/5/20/223

Slightly off-topic, but I have a test box that resumes immediately after an STR
is ehci_hcd is loaded and suspends correctly otherwise (with an Intel chipset).

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

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

[Alan Stern]

On Tue, 19 Jun 2007, Mattia Dongili wrote:

> > Try to enable the wakeup GPE for all the USB devices first.
> > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > 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
> > 
> > Try STR and check if it resumes immediately after suspend.
> > I think the same problem will happen without this patch.
> 
> only after enabling USB7 the broken behaviour showed.
> 
> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
> 
> Quite consistent with the other findings.

Just as with Raphael, I suggest you build a kernel with 
CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
debugging messages during the suspend and immediate resume.  To reduce 
the amount of clutter you might want to rmmod uhci-hcd before starting 
the test.

Alan Stern

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

[Zhang Rui]

On Tue, 2007-06-19 at 13:26 +0200, Rafael J. Wysocki wrote:
> On Tuesday, 19 June 2007 11:55, Zhang Rui wrote:
> > On Tue, 2007-06-19 at 18:30 +0900, Mattia Dongili wrote:
> > > On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
> > > > On Sun, 2007-05-20 at 15:14 +0900, 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
> > > > > > > ...
> > > > > > > > > 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
> > > > > 
> > > > Hi, Mattia,
> > > > 
> > > > I tested this patch on several platforms but can not reproduce the bug.
> > > > Could you please help me do a simple test please?
> > > > 
> > > > Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> > > > acpi-driver-model-flags-and-platform_enable_wake.patch.
> > > > 
> > > > Try to enable the wakeup GPE for all the USB devices first.
> > > > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > > > 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
> > > > 
> > > > Try STR and check if it resumes immediately after suspend.
> > > > I think the same problem will happen without this patch.
> > > 
> > > ok, building right now.
> > > Anyway, I don't remember the details but ehci and uhci were already
> > > spotted as being part of the problem. See the rest of the thread
> > > starting here http://lkml.org/lkml/2007/5/20/223
> 
> Slightly off-topic, but I have a test box that resumes immediately after an STR
> is ehci_hcd is loaded and suspends correctly otherwise (with an Intel chipset).
> 
Did you manually override /proc/acpi/wakeup?
Attaching the content of /proc/acpi/wakeup may be helpful. :)

Thanks,
Rui

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

[Mattia Dongili]

On Tue, Jun 19, 2007 at 10:20:32AM -0400, Alan Stern wrote:
> On Tue, 19 Jun 2007, Mattia Dongili wrote:
> 
> > > Try to enable the wakeup GPE for all the USB devices first.
> > > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > > 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
> > > 
> > > Try STR and check if it resumes immediately after suspend.
> > > I think the same problem will happen without this patch.
> > 
> > only after enabling USB7 the broken behaviour showed.
> > 
> > 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
> > 
> > Quite consistent with the other findings.
> 
> Just as with Raphael, I suggest you build a kernel with 
> CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
> debugging messages during the suspend and immediate resume.  To reduce 
> the amount of clutter you might want to rmmod uhci-hcd before starting 
> the test.

here we go:
http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log

and by the way:
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)

with ehci only:
Bus 005 Device 007: ID 054c:0281 Sony Corp. 
Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd 
Bus 005 Device 001: ID 0000:0000  

-- 
mattia
:wq!

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

[Alan Stern]

On Wed, 20 Jun 2007, Mattia Dongili wrote:

> > Just as with Raphael, I suggest you build a kernel with 
> > CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
> > debugging messages during the suspend and immediate resume.  To reduce 
> > the amount of clutter you might want to rmmod uhci-hcd before starting 
> > the test.
> 
> here we go:
> http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log
> 
> and by the way:
> 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)
> 
> with ehci only:
> Bus 005 Device 007: ID 054c:0281 Sony Corp. 
> Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd 
> Bus 005 Device 001: ID 0000:0000  

The log shows suspicious behavior on the part of the Sony UMH-U09
device, the first one in your ehci-only list above.  When it was
suspended it apparently disconnected itself from the USB bus, thereby
triggering a wakeup signal.  If at all possible, try unplugging the USB
cable to that device and then see what happens when you suspend.

You also ought to be able to prevent this immediate resume by disabling
wakeup on the EHCI controller.  For example:

	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup

(Maybe you only need one of those two lines; in principle either one
should be sufficient.)  After doing this it's probably a good idea to
run lsusb, to force the new settings to take effect in case the root
hub was autosuspended.

Alan Stern

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

[Rafael J. Wysocki]

On Wednesday, 20 June 2007 03:52, Zhang Rui wrote:
> On Tue, 2007-06-19 at 13:26 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 19 June 2007 11:55, Zhang Rui wrote:
> > > On Tue, 2007-06-19 at 18:30 +0900, Mattia Dongili wrote:
> > > > On Tue, Jun 19, 2007 at 04:57:55PM +0800, Zhang Rui wrote:
> > > > > On Sun, 2007-05-20 at 15:14 +0900, 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
> > > > > > > > ...
> > > > > > > > > > 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
> > > > > > 
> > > > > Hi, Mattia,
> > > > > 
> > > > > I tested this patch on several platforms but can not reproduce the bug.
> > > > > Could you please help me do a simple test please?
> > > > > 
> > > > > Any kernel release later than 2.6.22-rc1 is ok. You don't need to apply 
> > > > > acpi-driver-model-flags-and-platform_enable_wake.patch.
> > > > > 
> > > > > Try to enable the wakeup GPE for all the USB devices first.
> > > > > e.g. "#echo USB1 >/proc/acpi/wakeup" will enable GPE for USB1.
> > > > > 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
> > > > > 
> > > > > Try STR and check if it resumes immediately after suspend.
> > > > > I think the same problem will happen without this patch.
> > > > 
> > > > ok, building right now.
> > > > Anyway, I don't remember the details but ehci and uhci were already
> > > > spotted as being part of the problem. See the rest of the thread
> > > > starting here http://lkml.org/lkml/2007/5/20/223
> > 
> > Slightly off-topic, but I have a test box that resumes immediately after an STR
> > is ehci_hcd is loaded and suspends correctly otherwise (with an Intel chipset).
> > 
> Did you manually override /proc/acpi/wakeup?

No, I didn't.

> Attaching the content of /proc/acpi/wakeup may be helpful. :)

Well, there's nothing interesting in there, AFAICS:

Device	S-state	  Status   Sysfs node
P0P4	  S4	 disabled  pci:0000:00:1e.0
BNIC	  S4	 disabled  pci:0000:02:05.0
USB1	  S4	 disabled  pci:0000:00:1d.0
USB2	  S4	 disabled  pci:0000:00:1d.1
USB3	  S4	 disabled  pci:0000:00:1d.2
EUSB	  S4	 disabled  pci:0000:00:1d.7
PS2K	  S4	 disabled  pnp:00:0b
PS2M	  S4	 disabled  pnp:00:0c

(this is from after a successful hibernation if that matters).

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

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

[Mattia Dongili]

On Wed, Jun 20, 2007 at 12:33:04PM -0400, Alan Stern wrote:
> On Wed, 20 Jun 2007, Mattia Dongili wrote:
> 
> > > Just as with Raphael, I suggest you build a kernel with 
> > > CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
> > > debugging messages during the suspend and immediate resume.  To reduce 
> > > the amount of clutter you might want to rmmod uhci-hcd before starting 
> > > the test.
> > 
> > here we go:
> > http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log
> > 
> > and by the way:
> > 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)
> > 
> > with ehci only:
> > Bus 005 Device 007: ID 054c:0281 Sony Corp. 
> > Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd 
> > Bus 005 Device 001: ID 0000:0000  
> 
> The log shows suspicious behavior on the part of the Sony UMH-U09
> device, the first one in your ehci-only list above.  When it was
> suspended it apparently disconnected itself from the USB bus, thereby
> triggering a wakeup signal.  If at all possible, try unplugging the USB
> cable to that device and then see what happens when you suspend.

wow, spotted!

This device is an express card (SD/MMC reader). Do you have any
suggestion to make suspend work without any workarounds?

I mean, all of this started by enabling wakeup on the ehci controller
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	 enabled   pci:0000:00:1d.7

and this was triggered when trying to understand if enabling wakeup by
default on PCI devices was good or not (and the patch itself was
responsible or not for problems).
So, from my POV it's either not good or there has to be some way of
dealing with disconnecting devices on suspend.

Just to simplify, in this situation, if I had an usb mouse attached to
this usb controller and removed the mouse while suspended, would the
laptop wakeup?
If so that's not what I most probably want. :)

> You also ought to be able to prevent this immediate resume by disabling
> wakeup on the EHCI controller.  For example:
> 
> 	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
> 	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup

that doesn't seem to work very well (on -rc5 at least):
$ echo disable > /sys/bus/usb/devices/usb2/power/wakeup
echo: write error: invalid argument

The only value that seems to be accepted is 0 but reading the value
gives always "enabled".

Thanks
-- 
mattia
:wq!

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

[Zhang Rui]

On Thu, 2007-06-21 at 15:42 +0900, Mattia Dongili wrote:
> On Wed, Jun 20, 2007 at 12:33:04PM -0400, Alan Stern wrote:
> > On Wed, 20 Jun 2007, Mattia Dongili wrote:
> > 
> > > > Just as with Raphael, I suggest you build a kernel with 
> > > > CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
> > > > debugging messages during the suspend and immediate resume.  To reduce 
> > > > the amount of clutter you might want to rmmod uhci-hcd before starting 
> > > > the test.
> > > 
> > > here we go:
> > > http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log
> > > 
> > > and by the way:
> > > 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)
> > > 
> > > with ehci only:
> > > Bus 005 Device 007: ID 054c:0281 Sony Corp. 
> > > Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd 
> > > Bus 005 Device 001: ID 0000:0000  
> > 
> > The log shows suspicious behavior on the part of the Sony UMH-U09
> > device, the first one in your ehci-only list above.  When it was
> > suspended it apparently disconnected itself from the USB bus, thereby
> > triggering a wakeup signal.  If at all possible, try unplugging the USB
> > cable to that device and then see what happens when you suspend.
> 
> wow, spotted!
> 
> This device is an express card (SD/MMC reader). Do you have any
> suggestion to make suspend work without any workarounds?
> 
> I mean, all of this started by enabling wakeup on the ehci controller
> 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	 enabled   pci:0000:00:1d.7
> 
> and this was triggered when trying to understand if enabling wakeup by
> default on PCI devices was good or not (and the patch itself was
> responsible or not for problems).
> So, from my POV it's either not good or there has to be some way of
> dealing with disconnecting devices on suspend.
> 
Without this patch, users need to manually override /proc/acpi/wakeup
to enable the wakeup ability of a given device.
With this patch applied, /sys/.../power/wakeup is used to enable/disable
device's wakeup ability, while they are all enabled by default.

The change log of this patch is quite clear about this:
http://marc.info/?l=linux-acpi&m=117580342513025&w=2

> Just to simplify, in this situation, if I had an usb mouse attached to
> this usb controller and removed the mouse while suspended, would the
> laptop wakeup?
> If so that's not what I most probably want. :)
> 
> > You also ought to be able to prevent this immediate resume by disabling
> > wakeup on the EHCI controller.  For example:
> > 
> > 	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
> > 	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup
> that doesn't seem to work very well (on -rc5 at least):
> $ echo disable > /sys/bus/usb/devices/usb2/power/wakeup
> echo: write error: invalid argument
> 
"$ echo disabled > /sys/bus/usb/devices/usb2/power/wakeup"
should work. :)

Thanks,
Rui
 
> The only value that seems to be accepted is 0 but reading the value
> gives always "enabled".
> 
> Thanks

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

[Mattia Dongili]

On Thu, Jun 21, 2007 at 03:28:46PM +0800, Zhang Rui wrote:
> On Thu, 2007-06-21 at 15:42 +0900, Mattia Dongili wrote:
> > On Wed, Jun 20, 2007 at 12:33:04PM -0400, Alan Stern wrote:
> > > On Wed, 20 Jun 2007, Mattia Dongili wrote:
> > > 
> > > > > Just as with Raphael, I suggest you build a kernel with 
> > > > > CONFIG_USB_DEBUG turned on and then post the dmesg log showing the USB 
> > > > > debugging messages during the suspend and immediate resume.  To reduce 
> > > > > the amount of clutter you might want to rmmod uhci-hcd before starting 
> > > > > the test.
> > > > 
> > > > here we go:
> > > > http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log
> > > > 
> > > > and by the way:
> > > > 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)
> > > > 
> > > > with ehci only:
> > > > Bus 005 Device 007: ID 054c:0281 Sony Corp. 
> > > > Bus 005 Device 004: ID 05ca:1830 Ricoh Co., Ltd 
> > > > Bus 005 Device 001: ID 0000:0000  
> > > 
> > > The log shows suspicious behavior on the part of the Sony UMH-U09
> > > device, the first one in your ehci-only list above.  When it was
> > > suspended it apparently disconnected itself from the USB bus, thereby
> > > triggering a wakeup signal.  If at all possible, try unplugging the USB
> > > cable to that device and then see what happens when you suspend.
> > 
> > wow, spotted!
> > 
> > This device is an express card (SD/MMC reader). Do you have any
> > suggestion to make suspend work without any workarounds?
> > 
> > I mean, all of this started by enabling wakeup on the ehci controller
> > 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	 enabled   pci:0000:00:1d.7
> > 
> > and this was triggered when trying to understand if enabling wakeup by
> > default on PCI devices was good or not (and the patch itself was
> > responsible or not for problems).
> > So, from my POV it's either not good or there has to be some way of
> > dealing with disconnecting devices on suspend.
> > 
> Without this patch, users need to manually override /proc/acpi/wakeup
> to enable the wakeup ability of a given device.
> With this patch applied, /sys/.../power/wakeup is used to enable/disable
> device's wakeup ability, while they are all enabled by default.
> 
> The change log of this patch is quite clear about this:
> http://marc.info/?l=linux-acpi&m=117580342513025&w=2

So is this the case of the "broken hardware of drivers" as stated in the
chagelog? also, which of the two, hw or driver?

> > Just to simplify, in this situation, if I had an usb mouse attached to
> > this usb controller and removed the mouse while suspended, would the
> > laptop wakeup?
> > If so that's not what I most probably want. :)
> > 
> > > You also ought to be able to prevent this immediate resume by disabling
> > > wakeup on the EHCI controller.  For example:
> > > 
> > > 	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
> > > 	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup
> > that doesn't seem to work very well (on -rc5 at least):
> > $ echo disable > /sys/bus/usb/devices/usb2/power/wakeup
> > echo: write error: invalid argument
> > 
> "$ echo disabled > /sys/bus/usb/devices/usb2/power/wakeup"
> should work. :)

oops, thanks that is working indeed :)

-- 
mattia
:wq!

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

[Alan Stern]

On Thu, 21 Jun 2007, Mattia Dongili wrote:

> > The log shows suspicious behavior on the part of the Sony UMH-U09
> > device, the first one in your ehci-only list above.  When it was
> > suspended it apparently disconnected itself from the USB bus, thereby
> > triggering a wakeup signal.  If at all possible, try unplugging the USB
> > cable to that device and then see what happens when you suspend.
> 
> wow, spotted!
> 
> This device is an express card (SD/MMC reader). Do you have any
> suggestion to make suspend work without any workarounds?

You mean, do I have any suggestion about how to make the card reader 
behave properly?  No.  That needs more than a software change...  :-)

> I mean, all of this started by enabling wakeup on the ehci controller
> 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	 enabled   pci:0000:00:1d.7
> 
> and this was triggered when trying to understand if enabling wakeup by
> default on PCI devices was good or not (and the patch itself was
> responsible or not for problems).
> So, from my POV it's either not good or there has to be some way of
> dealing with disconnecting devices on suspend.

There _is_ a way: Disable wakeup on that USB controller.

> Just to simplify, in this situation, if I had an usb mouse attached to
> this usb controller and removed the mouse while suspended, would the
> laptop wakeup?

If the USB controller was enabled for wakeup and was working correctly,
it would wake up the laptop.  USB wakeup events are defined as: new
connection, disconnection, overcurrent, plus any wakeup requests
received from devices on the USB bus.

> If so that's not what I most probably want. :)

Maybe we should change the kernel so that the default wakeup setting 
for USB controllers is disabled.  Then people would have to enable 
wakeup explicitly if they wanted to be able to start up their system by 
typing on a USB keyboard, for instance.

> > You also ought to be able to prevent this immediate resume by disabling
> > wakeup on the EHCI controller.  For example:
> > 
> > 	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
> > 	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup
> 
> that doesn't seem to work very well (on -rc5 at least):
> $ echo disable > /sys/bus/usb/devices/usb2/power/wakeup
> echo: write error: invalid argument
> 
> The only value that seems to be accepted is 0 but reading the value
> gives always "enabled".

Whoops, yes, it should be "disabled" instead of "disable".  And of 
course you have to use the correct USB bus number in the path -- I 
wrote usb5 because that was the bus number of the EHCI controller in 
your log.

Alan Stern

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

[Mattia Dongili]

On Thu, Jun 21, 2007 at 11:45:36AM -0400, Alan Stern wrote:
> On Thu, 21 Jun 2007, Mattia Dongili wrote:
> 
> > > The log shows suspicious behavior on the part of the Sony UMH-U09
> > > device, the first one in your ehci-only list above.  When it was
> > > suspended it apparently disconnected itself from the USB bus, thereby
> > > triggering a wakeup signal.  If at all possible, try unplugging the USB
> > > cable to that device and then see what happens when you suspend.
> > 
> > wow, spotted!
> > 
> > This device is an express card (SD/MMC reader). Do you have any
> > suggestion to make suspend work without any workarounds?
> 
> You mean, do I have any suggestion about how to make the card reader 
> behave properly?  No.  That needs more than a software change...  :-)

ok than we are on the broken HW case...

> > I mean, all of this started by enabling wakeup on the ehci controller
> > 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	 enabled   pci:0000:00:1d.7
> > 
> > and this was triggered when trying to understand if enabling wakeup by
> > default on PCI devices was good or not (and the patch itself was
> > responsible or not for problems).
> > So, from my POV it's either not good or there has to be some way of
> > dealing with disconnecting devices on suspend.
> 
> There _is_ a way: Disable wakeup on that USB controller.
> 
> > Just to simplify, in this situation, if I had an usb mouse attached to
> > this usb controller and removed the mouse while suspended, would the
> > laptop wakeup?
> 
> If the USB controller was enabled for wakeup and was working correctly,
> it would wake up the laptop.  USB wakeup events are defined as: new
> connection, disconnection, overcurrent, plus any wakeup requests
> received from devices on the USB bus.
> 
> > If so that's not what I most probably want. :)
> 
> Maybe we should change the kernel so that the default wakeup setting 
> for USB controllers is disabled.  Then people would have to enable 
> wakeup explicitly if they wanted to be able to start up their system by 
> typing on a USB keyboard, for instance.

Don't know, I guess this could be easy automated in userspace actually.
But if connect/disconnect are wakeup events my vote goes to default to
disabled for usb controllers and manage selective enable with some nice
userspace tool. Not that my opinion counts that much :)

> > > You also ought to be able to prevent this immediate resume by disabling
> > > wakeup on the EHCI controller.  For example:
> > > 
> > > 	echo disable >/sys/bus/usb/devices/usb5/power/wakeup
> > > 	echo disable >/sys/bus/usb/devices/usb5/../power/wakeup
> > 
> > that doesn't seem to work very well (on -rc5 at least):
> > $ echo disable > /sys/bus/usb/devices/usb2/power/wakeup
> > echo: write error: invalid argument
> > 
> > The only value that seems to be accepted is 0 but reading the value
> > gives always "enabled".
> 
> Whoops, yes, it should be "disabled" instead of "disable".  And of 
> course you have to use the correct USB bus number in the path -- I 
> wrote usb5 because that was the bus number of the EHCI controller in 
> your log.

yes, sorry. That device is usb2 with uhci and becomes usb5 with ehci
loaded.

-- 
mattia
:wq!

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

[David Brownell]

> > > Just to simplify, in this situation, if I had an usb mouse attached to
> > > this usb controller and removed the mouse while suspended, would the
> > > laptop wakeup?
> > 
> > If the USB controller was enabled for wakeup and was working correctly,
> > it would wake up the laptop.  USB wakeup events are defined as: new
> > connection, disconnection, overcurrent, plus any wakeup requests
> > received from devices on the USB bus.
> > 
> > > If so that's not what I most probably want. :)

You have a workaround in hand to achieve what you want.


> > Maybe we should change the kernel so that the default wakeup setting 
> > for USB controllers is disabled. 

I'd rather not go that route.  It may well be that there's
something odd in the current handling of wakeup events with
EHCI.  I've not personally touched that particular code in
several years now, and a lot of code round it has changed
since then.  Plus of course, problems that don't reproduce
on my hardware can't get much attention from me ... there's
something like a factor of ten or more in terms of effort
to do that sort of remote debugging.


> > Then people would have to enable  
> > wakeup explicitly if they wanted to be able to start up their system by 
> > typing on a USB keyboard, for instance.
> 
> Don't know, I guess this could be easy automated in userspace actually.
> But if connect/disconnect are wakeup events my vote goes to default to
> disabled for usb controllers and manage selective enable with some nice
> userspace tool. Not that my opinion counts that much :)

A userspace tool would certainly be doable.  That's part of why
the sysfs wakeup attributes exist:  to cope with hardware oddities
the kernel doesn't know about, or to cope with user preferences.

- Dave

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

[David Brownell]

On Wednesday 20 June 2007, Mattia Dongili wrote:

> http://www.linux.it/~malattia/logs/dmesg-suspend-ehci-debug-log

which includes

> [18014387.734703] psmouse serio1: resuming
> [18014388.257990] usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2
> [18014388.257994] usb_endpoint usbdev5.1_ep81: PM: resume from 0, parent 5-0:1.0 still 2
> [18014388.258004] usb_endpoint usbdev5.2_ep00: PM: resume from 0, parent 5-4 still 2
> [18014388.258007] usb_endpoint usbdev5.4_ep00: PM: resume from 0, parent 5-6 still 2
> [18014388.258011] usb_endpoint usbdev5.4_ep81: PM: resume from 0, parent 5-6:1.0 still 2
> [18014388.258014] usb_endpoint usbdev5.4_ep86: PM: resume from 0, parent 5-6:1.0 still 2
> [18014388.258019] sony-laptop sony-laptop: resuming 
> [18014388.258022] platform bluetooth: resuming
> [18014388.258034] usb_endpoint usbdev5.2_ep02: PM: resume from 0, parent 5-4:1.0 still 2
> [18014388.258037] usb_endpoint usbdev5.2_ep82: PM: resume from 0, parent 5-4:1.0 still 2
> [18014388.310276] Restarting tasks ... <7>usb usb5: usb resume
> [18014388.310514] usb usb5: finish resume
> [18014388.310524] ehci_hcd 0000:00:1d.7: resume root hub
> [18014388.312058] done.
> [18014388.437263] hub 5-0:1.0: hub_resume
> [18014388.437314] hub 5-0:1.0: state 7 ports 8 chg 0000 evt 0000

That looks pretty darn goofy.  Resumes out of order:  endpoints for child
devices, then the downstream root hub, then finally the PCI dev.  Which
is completely the reverse of the correct direction.

Or am I missing something?

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

[David Brownell]

On Wednesday 20 June 2007, Rafael J. Wysocki wrote:

> Well, there's nothing interesting in there, AFAICS:
> 
> Device	S-state	  Status   Sysfs node
> P0P4	  S4	 disabled  pci:0000:00:1e.0
> BNIC	  S4	 disabled  pci:0000:02:05.0
> USB1	  S4	 disabled  pci:0000:00:1d.0
> USB2	  S4	 disabled  pci:0000:00:1d.1
> USB3	  S4	 disabled  pci:0000:00:1d.2
> EUSB	  S4	 disabled  pci:0000:00:1d.7
> PS2K	  S4	 disabled  pnp:00:0b
> PS2M	  S4	 disabled  pnp:00:0c

The interesting thing there is that all those devices are
able to wake from S4 state ... including USB controllers.

That's not very common for USB.  EHCI ("EUSB" above) at
least has a spec for how that should work ... it relies on
the PCI Vaux power well to maintain power sessions, though
I don't know that the EHCI code has been tested against
that part of the spec.  UHCI likely relies on black magic
to achieve that effect.

- Dave