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!
On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[email protected]> 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.
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[email protected]> 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!
On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[email protected]> 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 <[email protected]> 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.
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Pierre Ossman <[email protected]>
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!
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!
Hi,
On 19/05/07, Mattia Dongili <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
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 <[email protected]>
> Signed-off-by: Pierre Ossman <[email protected]>
>
> 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)
On Saturday, 19 May 2007 19:17, Michal Piotrowski wrote:
> Hi,
>
> On 19/05/07, Mattia Dongili <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> 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
On 19/05/07, Rafael J. Wysocki <[email protected]> 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 <[email protected]>
> > 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)
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[email protected]> 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 <[email protected]> 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!
On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
On Sat, May 19, 2007 at 11:47:23PM -0700, Andrew Morton wrote:
> On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <[email protected]> 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 <[email protected]> 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!
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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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!
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
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!