Hi.
Unfortunately, it seems that kernels later than 2.6.21 have problems
letting my powerpc iBook (G3 processor) going to sleep (suspend to
ram).
The userland that I am using is a Debian testing (lenny) and the
default kernel that comes with it is 2.6.22, with some patches applied
and pbbuttonsd (as the daemon for making the machine sleep).
With kernel 2.6.21, from Debian (and other earlier kernels), the
symptoms that I see when I press the power button is that the machine
goes to sleep and the led that indicates that the machine is sleeping
is blinking normally.
If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
kernel with just the necessary parts for my work (version 2.6.23-rc3
taken from kernel.org), then I can't make the machine sleep: when I
press the button, it acts like if I had, in sequence, pressed anything
to wake it up (say, like pressing shift).
I have already grabbed Linus's git tree and I am willing to do some
cycles of "git bisect" to discover the point where it stopped working.
I just thought that others may have seen such behaviour before or, if
not, that being informative about what I see is of use for debugging
this.
I would also appreciate any guidance on this as I wish kernel 2.6.23
to be working again on powerpc machines.
Please, if any tests are required, don't hesitate to ask me and I will
try to whatever is needed to restore the correct behaviour of sleep
with the Linux kernel.
I have copied mailing lists that I think that are relevant. If they
aren't, then please let me know. I would also appreciate if I were
kept on carbon copies as I am only subscribed to debian-powerpc at the
moment.
Regards, Rog?rio Brito.
P.S.: It unfortunately doesn't matter if I switch to a console or if I
am in X when I press the power button with recent kernels.
Hi
[Adding STR wizards to CC]
On 26/08/07, Rog?rio Brito <[email protected]> wrote:
> Hi.
>
> Unfortunately, it seems that kernels later than 2.6.21 have problems
> letting my powerpc iBook (G3 processor) going to sleep (suspend to
> ram).
>
> The userland that I am using is a Debian testing (lenny) and the
> default kernel that comes with it is 2.6.22, with some patches applied
> and pbbuttonsd (as the daemon for making the machine sleep).
>
> With kernel 2.6.21, from Debian (and other earlier kernels), the
> symptoms that I see when I press the power button is that the machine
> goes to sleep and the led that indicates that the machine is sleeping
> is blinking normally.
>
> If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> kernel with just the necessary parts for my work (version 2.6.23-rc3
> taken from kernel.org), then I can't make the machine sleep: when I
> press the button, it acts like if I had, in sequence, pressed anything
> to wake it up (say, like pressing shift).
>
> I have already grabbed Linus's git tree and I am willing to do some
> cycles of "git bisect" to discover the point where it stopped working.
>
> I just thought that others may have seen such behaviour before or, if
> not, that being informative about what I see is of use for debugging
> this.
>
> I would also appreciate any guidance on this as I wish kernel 2.6.23
> to be working again on powerpc machines.
>
> Please, if any tests are required, don't hesitate to ask me and I will
> try to whatever is needed to restore the correct behaviour of sleep
> with the Linux kernel.
>
> I have copied mailing lists that I think that are relevant. If they
> aren't, then please let me know. I would also appreciate if I were
> kept on carbon copies as I am only subscribed to debian-powerpc at the
> moment.
>
>
> Regards, Rog?rio Brito.
>
> P.S.: It unfortunately doesn't matter if I switch to a console or if I
> am in X when I press the power button with recent kernels.
> -
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Hi, Thanks, Michal.
I didn't know who to include as the wizards of the matter.
On Aug 27 2007, Michal Piotrowski wrote:
> [Adding STR wizards to CC]
>
> On 26/08/07, Rog?rio Brito <[email protected]> wrote:
> > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > taken from kernel.org), then I can't make the machine sleep: when I
> > press the button, it acts like if I had, in sequence, pressed anything
> > to wake it up (say, like pressing shift).
Things are getting now a little bit fishy.
Before, I was using gnome and all the little daemons that come with it
(even though I just prefer a plain window manager), but, as I mentioned
before, it didn't matter if I pressed the power button on X or on a
console.
I had the gnomee power-thingy sounding like an alarm (an ambulance!) on me
when I pressed the power button with Debian kernels 2.6.22, for instance. I
compiled my own (this time, from kernel.org) 2.6.23-rc3, with many modules
and subsystems removed (e.g., bluetooth, as this laptop doesn't have it)
and I got the exact same behavior.
If I booted, OTOH, with Debian's kernel 2.6.18, things were fine and the
machine would go to sleep without any problems.
I am now suspecting of some module that prevented the machine from going to
sleep and I now using just a fluxbox as my window manager. This time, even
with a 2.6.23-rc3 kernel (again, from kernel.org) the machine went to sleep
normally.
I did 13 compiles with git bisect and some of them were unsucessfuly
compiled, which I am afraid that may miss the real cause if I tag them as
being "bad" (which I did). (This was with just a bare minimum installation
of Debian).
The course of action that I am taking right now is to pull GNOME and see if
my current 23-rc3 kernel has any problems and see which modules are loaded.
If things progress well, I will incrementally include features on the
kernel that I need (I left out, for instance, the Firewire subsystem, so
that compilation wouldn't take more than an hour here, despite the fact
that I do need Firewire support on the kernel) and see the point where
things are not normal.
Again, I am willing to test anything that is useful to getting PowerPC
working as well as it should with the final 2.6.23 release.
Please, don't hesitate to ask for any further information.
Regards, Rog?rio Brito.
--
Rog?rio Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Hallo!
I also have 800MHz iBook (2.2, 2 USB) and had the same problem with the
21.6.22 kernel a while ago and reverted back to 2.6.21. I'm not a kernel
guy but I think I remember from kernel traces that it looked like (wise
chosen words ;-)) that the problems had something to do with
deactivating the firewire "subsystem".
I don't have traces at hand and due to lack of time cannot reproduce it
up to tomorrow. However this hint may speed up your analysis!
[rather long To-list, is everybody happy with this?]
--
Gru?...
Tim
On Mon, 2007-08-27 at 03:52 -0300, Rogério Brito wrote:
>
> I did 13 compiles with git bisect and some of them were unsucessfuly
> compiled, which I am afraid that may miss the real cause if I tag them as
> being "bad" (which I did).
Yes, don't mark such cases as bad or good but look for a nearby commit
that compiles.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Hi!
> I didn't know who to include as the wizards of the matter.
>
> > > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > > taken from kernel.org), then I can't make the machine sleep: when I
> > > press the button, it acts like if I had, in sequence, pressed anything
> > > to wake it up (say, like pressing shift).
>
> Things are getting now a little bit fishy.
>
> Before, I was using gnome and all the little daemons that come with it
> (even though I just prefer a plain window manager), but, as I mentioned
> before, it didn't matter if I pressed the power button on X or on a
> console.
>
> I had the gnomee power-thingy sounding like an alarm (an ambulance!) on me
> when I pressed the power button with Debian kernels 2.6.22, for instance. I
> compiled my own (this time, from kernel.org) 2.6.23-rc3, with many modules
> and subsystems removed (e.g., bluetooth, as this laptop doesn't have it)
> and I got the exact same behavior.
>
> If I booted, OTOH, with Debian's kernel 2.6.18, things were fine and the
> machine would go to sleep without any problems.
>
> I am now suspecting of some module that prevented the machine from going to
> sleep and I now using just a fluxbox as my window manager. This time, even
> with a 2.6.23-rc3 kernel (again, from kernel.org) the machine went to sleep
> normally.
>
> I did 13 compiles with git bisect and some of them were unsucessfuly
Rather than doing bisect, it might be more interesting to find out
which userspace part makes it fail to sleep, then see what is it that
makes the difference.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hello!
> I don't have traces at hand and due to lack of time cannot reproduce it
> up to tomorrow. However this hint may speed up your analysis!
Sorry for the delay, but my desktop PC had an urgent hard disk problem I
had to fix ASASP.
So here is the output from dmesg that suggested to me that firewire
might be a problem:
> usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> eth2: Airport entering sleep mode
> eth0: suspending, WakeOnLan disabled
> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> Could not suspend device 0002:20:0e.0: error -22
> eth0: resuming
> PHY ID: 4061e4, addr: 0
> eth2: Airport waking up
> eth2: New link status: Connected (0001)
> hda: Enabling Ultra DMA 2
> eth0: Link is up at 100 Mbps, full-duplex.
> eth0: Pause is disabled
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> hdb: Enabling Ultra DMA 2
> usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
> usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
> usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
> Driver sleep failed
> Sleep rejected by devices
> adb: starting probe task...
> adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
> ADB keyboard at 2, handler 1
> ADB mouse at 3, handler set to 4 (trackpad)
> adb: finished probe task...
> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> eth2: Airport entering sleep mode
> eth0: suspending, WakeOnLan disabled
> Trying to free already-free IRQ 40
> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> Could not suspend device 0002:20:0e.0: error -22
> eth0: resuming
> PHY ID: 4061e4, addr: 0
> eth2: Airport waking up
> eth2: New link status: Connected (0001)
> hda: Enabling Ultra DMA 2
> hdb: Enabling Ultra DMA 2
> eth0: Link is up at 100 Mbps, full-duplex.
> eth0: Pause is disabled
The problem wa sinitiated by closing the lid. The iBook then seems to
permanetly try to go to sleep (I can hear the cd-rom drive get
periodically initialized). So above contains more than one iteration.
The kernel is:
> Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
The relveant debian package:
> linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
I'm running a mixture of debian testing/unstable.
The firewire and the USB connector were unused, the network connector
was used.
If there are questions regarding other packages, or somebody wants me to
test a fix (I would prever a debian package), don't hesitate - I would
like to get the bug fixed :-)
--
Gru?...
Tim
> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <[email protected]> wrote:
> Hello!
>
> > I don't have traces at hand and due to lack of time cannot reproduce it
> > up to tomorrow. However this hint may speed up your analysis!
>
> Sorry for the delay, but my desktop PC had an urgent hard disk problem I
> had to fix ASASP.
>
> So here is the output from dmesg that suggested to me that firewire
> might be a problem:
Straightforward regression, two reporters, nothing happening.
> > usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
> > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > eth2: Airport entering sleep mode
> > eth0: suspending, WakeOnLan disabled
> > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > Could not suspend device 0002:20:0e.0: error -22
> > eth0: resuming
> > PHY ID: 4061e4, addr: 0
> > eth2: Airport waking up
> > eth2: New link status: Connected (0001)
> > hda: Enabling Ultra DMA 2
> > eth0: Link is up at 100 Mbps, full-duplex.
> > eth0: Pause is disabled
> > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > hdb: Enabling Ultra DMA 2
> > usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
> > usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
> > usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
> > Driver sleep failed
> > Sleep rejected by devices
> > adb: starting probe task...
> > adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
> > ADB keyboard at 2, handler 1
> > ADB mouse at 3, handler set to 4 (trackpad)
> > adb: finished probe task...
> > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > eth2: Airport entering sleep mode
> > eth0: suspending, WakeOnLan disabled
> > Trying to free already-free IRQ 40
> > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
I grepped the whole tree for firewire_ohci and came up blank. What is it?
But yes, a failed pci_set_power_state() will hurt. Perhaps this is
a result of some recently-added return-value checking fix but as I
cannot find the dang code I cannot tell.
> > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > Could not suspend device 0002:20:0e.0: error -22
> > eth0: resuming
> > PHY ID: 4061e4, addr: 0
> > eth2: Airport waking up
> > eth2: New link status: Connected (0001)
> > hda: Enabling Ultra DMA 2
> > hdb: Enabling Ultra DMA 2
> > eth0: Link is up at 100 Mbps, full-duplex.
> > eth0: Pause is disabled
>
> The problem wa sinitiated by closing the lid. The iBook then seems to
> permanetly try to go to sleep (I can hear the cd-rom drive get
> periodically initialized). So above contains more than one iteration.
>
> The kernel is:
> > Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>
> The relveant debian package:
> > linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>
> I'm running a mixture of debian testing/unstable.
>
> The firewire and the USB connector were unused, the network connector
> was used.
>
> If there are questions regarding other packages, or somebody wants me to
> test a fix (I would prever a debian package), don't hesitate - I would
> like to get the bug fixed :-)
>
On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
> > On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <[email protected]> wrote:
> > Hello!
> >
> > > I don't have traces at hand and due to lack of time cannot reproduce it
> > > up to tomorrow. However this hint may speed up your analysis!
> >
> > Sorry for the delay, but my desktop PC had an urgent hard disk problem I
> > had to fix ASASP.
> >
> > So here is the output from dmesg that suggested to me that firewire
> > might be a problem:
>
> Straightforward regression, two reporters, nothing happening.
(material for ksummit discussion, e.g.)
> > > usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
> > > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > > eth2: Airport entering sleep mode
> > > eth0: suspending, WakeOnLan disabled
> > > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> > > suspend_device(): pci_device_suspend+0x0/0x98() returns -22
> > > Could not suspend device 0002:20:0e.0: error -22
> > > eth0: resuming
> > > PHY ID: 4061e4, addr: 0
> > > eth2: Airport waking up
> > > eth2: New link status: Connected (0001)
> > > hda: Enabling Ultra DMA 2
> > > eth0: Link is up at 100 Mbps, full-duplex.
> > > eth0: Pause is disabled
> > > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > > hdb: Enabling Ultra DMA 2
> > > usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
> > > usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
> > > usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
> > > Driver sleep failed
> > > Sleep rejected by devices
> > > adb: starting probe task...
> > > adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
> > > ADB keyboard at 2, handler 1
> > > ADB mouse at 3, handler set to 4 (trackpad)
> > > adb: finished probe task...
> > > usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
> > > hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
> > > usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
> > > eth2: Airport entering sleep mode
> > > eth0: suspending, WakeOnLan disabled
> > > Trying to free already-free IRQ 40
> > > pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> > > firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>
> I grepped the whole tree for firewire_ohci and came up blank. What is it?
See drivers/firewire/Makefile
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Randy Dunlap wrote:
> On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
>>> So here is the output from dmesg that suggested to me that firewire
>>> might be a problem:
>> Straightforward regression, two reporters, nothing happening.
>
> (material for ksummit discussion, e.g.)
It's a simple thing in this incident: I don't read all posts on LKML.
But I typically catch everything where I am in the CC list thanks to the
wonders of sieve. Andrew, thanks for putting me in the CCs.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
Andrew Morton wrote:
>> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <[email protected]> wrote:
>> Hello!
>>
>>> I don't have traces at hand and due to lack of time cannot reproduce it
>>> up to tomorrow. However this hint may speed up your analysis!
>> Sorry for the delay, but my desktop PC had an urgent hard disk problem I
>> had to fix ASASP.
>>
>> So here is the output from dmesg that suggested to me that firewire
>> might be a problem:
>
> Straightforward regression, two reporters, nothing happening.
Thanks for CCing me. I'm also adding the CC of Kristian, author and
other maintainer of the code in question.
>>> usb_endpoint usbdev2.2_ep81: PM: suspend 0->2, parent 2-1:1.0 already 2
>>> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
>>> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
>>> eth2: Airport entering sleep mode
>>> eth0: suspending, WakeOnLan disabled
>>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>>> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
>>> Could not suspend device 0002:20:0e.0: error -22
>>> eth0: resuming
>>> PHY ID: 4061e4, addr: 0
>>> eth2: Airport waking up
>>> eth2: New link status: Connected (0001)
>>> hda: Enabling Ultra DMA 2
>>> eth0: Link is up at 100 Mbps, full-duplex.
>>> eth0: Pause is disabled
>>> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> hdb: Enabling Ultra DMA 2
>>> usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
>>> usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
>>> usb_device usbdev1.1: PM: resume from 0, parent usb1 still 2
>>> Driver sleep failed
>>> Sleep rejected by devices
>>> adb: starting probe task...
>>> adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
>>> ADB keyboard at 2, handler 1
>>> ADB mouse at 3, handler set to 4 (trackpad)
>>> adb: finished probe task...
>>> usb_device usbdev1.1: PM: suspend 0->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
>>> hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
>>> usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
>>> eth2: Airport entering sleep mode
>>> eth0: suspending, WakeOnLan disabled
>>> Trying to free already-free IRQ 40
>>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
>
> I grepped the whole tree for firewire_ohci and came up blank. What is it?
drivers/firewire/fw-ohci.c -> fw-ohci.o -> firewire-ohci.o ->
firewire-ohci.ko
> But yes, a failed pci_set_power_state() will hurt. Perhaps this is
> a result of some recently-added return-value checking fix but as I
> cannot find the dang code I cannot tell.
The old ohci1394.c used to ignore pci_set_power_state's return value.
In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I
added a fail-on-error. This was toned down to a printk-on-err by pre
2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0.
This was because of Benjamin Herrenschmidt's regression report:
http://lkml.org/lkml/2006/10/24/13
So, we went into the same trap again with fw-ohci. I should have
noticed how fw-ohci treats pci_set_power_state when I signed off the
commit which added the suspend/resume methods to fw-ohci --- but somehow
I didn't.
>>> suspend_device(): pci_device_suspend+0x0/0x98() returns -22
>>> Could not suspend device 0002:20:0e.0: error -22
>>> eth0: resuming
>>> PHY ID: 4061e4, addr: 0
>>> eth2: Airport waking up
>>> eth2: New link status: Connected (0001)
>>> hda: Enabling Ultra DMA 2
>>> hdb: Enabling Ultra DMA 2
>>> eth0: Link is up at 100 Mbps, full-duplex.
>>> eth0: Pause is disabled
>> The problem wa sinitiated by closing the lid. The iBook then seems to
>> permanetly try to go to sleep (I can hear the cd-rom drive get
>> periodically initialized). So above contains more than one iteration.
>>
>> The kernel is:
>>> Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>> The relveant debian package:
>>> linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>> I'm running a mixture of debian testing/unstable.
>>
>> The firewire and the USB connector were unused, the network connector
>> was used.
>>
>> If there are questions regarding other packages, or somebody wants me to
>> test a fix (I would prever a debian package), don't hesitate - I would
>> like to get the bug fixed :-)
>>
A trivial post -rc1 compatible fix is coming in a minute.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
Stefan Richter wrote:
> Randy Dunlap wrote:
>> On Wed, 5 Sep 2007 10:07:54 -0700 Andrew Morton wrote:
>>>> So here is the output from dmesg that suggested to me that firewire
>>>> might be a problem:
>>> Straightforward regression, two reporters, nothing happening.
>> (material for ksummit discussion, e.g.)
>
> It's a simple thing in this incident: I don't read all posts on LKML.
> But I typically catch everything where I am in the CC list thanks to the
> wonders of sieve. Andrew, thanks for putting me in the CCs.
I understand. I just meant the general trend, nothing specific
to this thread.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Stefan Richter <[email protected]>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13,
we do *not* fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <[email protected]>
---
drivers/firewire/fw-ohci.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6.23-rc4/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.23-rc4.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.23-rc4/drivers/firewire/fw-ohci.c
@@ -1946,8 +1946,11 @@ static int pci_suspend(struct pci_dev *p
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
if (err) {
+ /*
+ * Some Apple onboard controllers are known to fail here.
+ * Ignore it and let the machine proceed to suspend.
+ */
fw_error("pci_set_power_state failed\n");
- return err;
}
return 0;
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
Rog?rio Brito wrote on 2007-08-27:
> If things progress well, I will incrementally include features on the
> kernel that I need (I left out, for instance, the Firewire subsystem, so
> that compilation wouldn't take more than an hour here, despite the fact
> that I do need Firewire support on the kernel) and see the point where
> things are not normal.
The trivial pci_set_power_state issue aside, resume is currently
defective with the new firewire-ohci driver:
- The version in Linus' tree doesn't restore a certain detail of
IEEE 1394 state during resume, hence some protocols like SBP-2 don't
work after resume unless you unload and reload the drivers.
- The version in -mm restores everything but panics soon after resume
on an APM notebook in combination with some SBP-2 targets. I have
yet to try netconsole or so to gather more information.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
>>> On 30 Aug 2007 22:42:46 +0200 "Tim Teulings" <[email protected]> wrote:
>>> The kernel is:
>>>> Linux kismet 2.6.22-1-powerpc #1 Sun Jul 29 13:58:06 CEST 2007 ppc GNU/Linux
>>> The relveant debian package:
>>>> linux-image-2.6.22-1-powerpc_2.6.22-3_powerpc.deb
>>> I'm running a mixture of debian testing/unstable.
At the moment, distributors should not provide the experimental
firewire-* drivers as the only or primary FireWire drivers, unless they
know exactly what the gotchas are. As a hint, CONFIG_FIREWIRE currently
depends on EXPERIMENTAL, CONFIG_IEEE1394 does not. Some basic
information can be found at http://wiki.linux1394.org/JujuMigration.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
> On Wed, 05 Sep 2007 19:47:42 +0200 Stefan Richter <[email protected]> wrote:
> Andrew Morton wrote:
> >>> Trying to free already-free IRQ 40
> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
> >
> > I grepped the whole tree for firewire_ohci and came up blank. What is it?
>
> drivers/firewire/fw-ohci.c -> fw-ohci.o -> firewire-ohci.o ->
> firewire-ohci.ko
argh. It's not the first time that the module system's weird
replace-dash-with-underscore thing has fooled me.
> > But yes, a failed pci_set_power_state() will hurt. Perhaps this is
> > a result of some recently-added return-value checking fix but as I
> > cannot find the dang code I cannot tell.
>
> The old ohci1394.c used to ignore pci_set_power_state's return value.
> In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I
> added a fail-on-error. This was toned down to a printk-on-err by pre
> 2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0.
OK.
> This was because of Benjamin Herrenschmidt's regression report:
> http://lkml.org/lkml/2006/10/24/13
It's not clear _why_ pci_set_power_state() is failing.
> A trivial post -rc1 compatible fix is coming in a minute.
neato, thanks.
On 5 Sep, Andrew Morton wrote:
>> On Wed, 05 Sep 2007 19:47:42 +0200 Stefan Richter <[email protected]> wrote:
>> >>> Trying to free already-free IRQ 40
>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
...
>> The old ohci1394.c used to ignore pci_set_power_state's return value.
>> In the pre 2.6.19-rc1 commit ea6104c22468239083857fa07425c312b1ecb424, I
>> added a fail-on-error. This was toned down to a printk-on-err by pre
>> 2.6.19-rc4 commit 346f5c7ee7fa4ebee0e4c96415a7e59716bfa1d0.
>
> OK.
>
>> This was because of Benjamin Herrenschmidt's regression report:
>> http://lkml.org/lkml/2006/10/24/13
>
> It's not clear _why_ pci_set_power_state() is failing.
The only -22 error path in pci_set_power_state is this:
/* Validate current state:
* Can enter D0 from any state, but if we can only go deeper
* to sleep if we're already in a low power state
*/
if (state != PCI_D0 && dev->current_state > state) {
printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
__FUNCTION__, pci_name(dev), state, dev->current_state);
return -EINVAL;
} [...else...]
(There seems to be one "if" too many in the comment.)
dev->current_state was PCI_UNKNOWN, and this is not properly handled by
pci_set_power_state. Some checks later, there is
switch (dev->current_state) {
case PCI_D0:
case PCI_D1:
case PCI_D2:
pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
pmcsr |= state;
break;
case PCI_UNKNOWN: /* Boot-up */
if ((pmcsr & PCI_PM_CTRL_STATE_MASK) == PCI_D3hot
&& !(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET))
need_restore = 1;
/* Fall-through: force to D0 */
default:
pmcsr = 0;
break;
}
But the PCI_UNKNOWN branch will never be reached because of the if ()
clause quoted above.
Also, this FireWire controller here surely had left the boot-up phase
already long ago when the reporter tried to suspend the machine.
--
Stefan Richter
-=====-=-=== =--= --=-=
http://arcgraph.de/sr/
On 5 Sep, Stefan Richter wrote:
> On 5 Sep, Andrew Morton wrote:
>>> >>> Trying to free already-free IRQ 40
>>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
...
>> It's not clear _why_ pci_set_power_state() is failing.
>
> The only -22 error path in pci_set_power_state is this:
>
> /* Validate current state:
> * Can enter D0 from any state, but if we can only go deeper
> * to sleep if we're already in a low power state
> */
> if (state != PCI_D0 && dev->current_state > state) {
> printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
> __FUNCTION__, pci_name(dev), state, dev->current_state);
> return -EINVAL;
> } [...else...]
From: Stefan Richter <[email protected]>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <[email protected]>
---
Update:
- omit comment which will become outdated if the underlying problem is fixed
- log the error return value
- document the actual bug in the patch description
IMO the actual bug here (operating the controller while it is in
PCI_UNKNOWN state, which is surely a fault in the PPC platform code) is
something to be fixed post 2.6.23 release.
drivers/firewire/fw-ohci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1973,10 +1973,8 @@ static int pci_suspend(struct pci_dev *p
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed\n");
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
--
Stefan Richter
-=====-=-=== =--= --==-
http://arcgraph.de/sr/