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]
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.
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...
[ message continues ]

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

-

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

-

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
-

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 
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.
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
-

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

-

Thanks for CCing me.  I'm also adding the CC of Kristian, author and
drivers/firewire/fw-ohci.c -> fw-ohci.o -> firewire-ohci.o ->
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
A trivial post -rc1 compatible fix is coming in a minute.

--

Stefan Richter

-=====-=-=== =--= --=-=

http://arcgraph.de/sr/

-

argh.  It's not the first time that the module system's weird
neato, thanks.

-

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/
-

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

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 <stefanr@s5r6.in-berlin.de>

---
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/
-

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/

-

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

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 <stefanr@s5r6.in-berlin.de>

---

 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/
-

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/

-

See drivers/firewire/Makefile
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

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/

-

I understand.  I just meant the general trend, nothing specific

to this thread.
--

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-