Two problems with system sleep

Two problems with system sleep

[Alan Stern]

Rafael:

My newly-installed desktop system is experiencing a couple of problems 
with system sleep.  (Oddly enough, the old one was working fairly 
well...)

The first has to do with the serial port.  It doesn't appear to resume 
correctly.  I booted with:

	console=ttyS0,115200 console=tty0 earlyprintk=serial,ttyS0,115200
		no_console_suspend

Then I did "echo processors >pm_test ; echo mem >state".  In spite of
the no_console_suspend, data stopped going out through the serial port
after the following appeared:

[  273.664785] PM: Preparing system for mem sleep
[  273.677133] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  273.698837] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[  273.718799] PM: Entering mem sleep
[  273.794463] serial 00:05: disabled

even though things continued to appear on the VT screen.  The only
other text to show up on the serial monitor was this line:

[  279.069204] serial 00:05: activated

The normal sequence of messages showed up on the screen, but everything
was oddly slow.  Check out some sample timestamps:

[  332.120130] ehci_hcd 0000:00:1d.7: GetStatus port 8 status 001005 POWER sig=se0 PE CONNECT
[  334.592054] usb 2-8: finish resume
[  335.613747] PM: resume of devices complete after 56629.644 msecs
[  337.426230] PM: Finishing wakeup.
[  338.430797] Restarting tasks ... 
[  339.378108] usb 2-8: usb auto-suspend
[  340.554760] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
[  342.204128] done.
[  342.816603] hub 2-0:1.0: state 7 ports 8 chg 0000 evt 0000

The delay between each line and its successor is proportional to the
line's length, as though the kernel were still trying to send the 
characters out through the serial port but at 360 baud!  Is anybody in 
charge of the 8250 driver these days?

The bigger problem is that with a normal sleep ("echo none >pm_test"),
the system doesn't wake up.  Pressing a key or a mouse button does
nothing.  Pressing the power button causes the machine to start up
again, but the screen remains blank and there's no response to network
pings.

This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
applied but none of your PM patches).  The motherboard is an Intel 
ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Friday 12 February 2010, Alan Stern wrote:
> Rafael:
> 
> My newly-installed desktop system is experiencing a couple of problems 
> with system sleep.  (Oddly enough, the old one was working fairly 
> well...)
> 
> The first has to do with the serial port.  It doesn't appear to resume 
> correctly.  I booted with:
> 
> 	console=ttyS0,115200 console=tty0 earlyprintk=serial,ttyS0,115200
> 		no_console_suspend
> 
> Then I did "echo processors >pm_test ; echo mem >state".  In spite of
> the no_console_suspend, data stopped going out through the serial port
> after the following appeared:
> 
> [  273.664785] PM: Preparing system for mem sleep
> [  273.677133] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [  273.698837] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> [  273.718799] PM: Entering mem sleep
> [  273.794463] serial 00:05: disabled
> 
> even though things continued to appear on the VT screen.  The only
> other text to show up on the serial monitor was this line:
> 
> [  279.069204] serial 00:05: activated
> 
> The normal sequence of messages showed up on the screen, but everything
> was oddly slow.  Check out some sample timestamps:
> 
> [  332.120130] ehci_hcd 0000:00:1d.7: GetStatus port 8 status 001005 POWER sig=se0 PE CONNECT
> [  334.592054] usb 2-8: finish resume
> [  335.613747] PM: resume of devices complete after 56629.644 msecs
> [  337.426230] PM: Finishing wakeup.
> [  338.430797] Restarting tasks ... 
> [  339.378108] usb 2-8: usb auto-suspend
> [  340.554760] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [  342.204128] done.
> [  342.816603] hub 2-0:1.0: state 7 ports 8 chg 0000 evt 0000
> 
> The delay between each line and its successor is proportional to the
> line's length, as though the kernel were still trying to send the 
> characters out through the serial port but at 360 baud!  Is anybody in 
> charge of the 8250 driver these days?

Quite frankly I'm not sure.  Greg, do you know?

> The bigger problem is that with a normal sleep ("echo none >pm_test"),
> the system doesn't wake up.  Pressing a key or a mouse button does
> nothing.  Pressing the power button causes the machine to start up
> again, but the screen remains blank and there's no response to network
> pings.
> 
> This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
> applied but none of your PM patches).  The motherboard is an Intel 
> ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?

That depends on the graphics adapter.  Is it Intel or AMD?

Rafael

Re: Two problems with system sleep

[Greg KH]

On Sat, Feb 13, 2010 at 01:13:01AM +0100, Rafael J. Wysocki wrote:
> On Friday 12 February 2010, Alan Stern wrote:
> > Rafael:
> > 
> > My newly-installed desktop system is experiencing a couple of problems 
> > with system sleep.  (Oddly enough, the old one was working fairly 
> > well...)
> > 
> > The first has to do with the serial port.  It doesn't appear to resume 
> > correctly.  I booted with:
> > 
> > 	console=ttyS0,115200 console=tty0 earlyprintk=serial,ttyS0,115200
> > 		no_console_suspend
> > 
> > Then I did "echo processors >pm_test ; echo mem >state".  In spite of
> > the no_console_suspend, data stopped going out through the serial port
> > after the following appeared:
> > 
> > [  273.664785] PM: Preparing system for mem sleep
> > [  273.677133] Freezing user space processes ... (elapsed 0.01 seconds) done.
> > [  273.698837] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > [  273.718799] PM: Entering mem sleep
> > [  273.794463] serial 00:05: disabled
> > 
> > even though things continued to appear on the VT screen.  The only
> > other text to show up on the serial monitor was this line:
> > 
> > [  279.069204] serial 00:05: activated
> > 
> > The normal sequence of messages showed up on the screen, but everything
> > was oddly slow.  Check out some sample timestamps:
> > 
> > [  332.120130] ehci_hcd 0000:00:1d.7: GetStatus port 8 status 001005 POWER sig=se0 PE CONNECT
> > [  334.592054] usb 2-8: finish resume
> > [  335.613747] PM: resume of devices complete after 56629.644 msecs
> > [  337.426230] PM: Finishing wakeup.
> > [  338.430797] Restarting tasks ... 
> > [  339.378108] usb 2-8: usb auto-suspend
> > [  340.554760] hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
> > [  342.204128] done.
> > [  342.816603] hub 2-0:1.0: state 7 ports 8 chg 0000 evt 0000
> > 
> > The delay between each line and its successor is proportional to the
> > line's length, as though the kernel were still trying to send the 
> > characters out through the serial port but at 360 baud!  Is anybody in 
> > charge of the 8250 driver these days?
> 
> Quite frankly I'm not sure.  Greg, do you know?

Well, Alan Cox has been looking after it, with me handling patch queues.

That's a pretty slow print speed, very wierd.

Alan Cox, any ideas?

thanks,

greg k-h

Re: Two problems with system sleep

[Alan Stern]

On Sat, 13 Feb 2010, Rafael J. Wysocki wrote:

> > The bigger problem is that with a normal sleep ("echo none >pm_test"),
> > the system doesn't wake up.  Pressing a key or a mouse button does
> > nothing.  Pressing the power button causes the machine to start up
> > again, but the screen remains blank and there's no response to network
> > pings.
> > 
> > This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
> > applied but none of your PM patches).  The motherboard is an Intel 
> > ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?
> 
> That depends on the graphics adapter.  Is it Intel or AMD?

$ lspci -s 2.0
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

Do you need any more information than that?

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Sunday 14 February 2010, Alan Stern wrote:
> On Sat, 13 Feb 2010, Rafael J. Wysocki wrote:
> 
> > > The bigger problem is that with a normal sleep ("echo none >pm_test"),
> > > the system doesn't wake up.  Pressing a key or a mouse button does
> > > nothing.  Pressing the power button causes the machine to start up
> > > again, but the screen remains blank and there's no response to network
> > > pings.
> > > 
> > > This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
> > > applied but none of your PM patches).  The motherboard is an Intel 
> > > ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?
> > 
> > That depends on the graphics adapter.  Is it Intel or AMD?
> 
> $ lspci -s 2.0
> 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

Well, that is supposed to work.  Do you have KMS turned on?

> Do you need any more information than that?

Is the problem reproducible with init=/bin/bash vga=0?

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Sun, 14 Feb 2010, Rafael J. Wysocki wrote:

> On Sunday 14 February 2010, Alan Stern wrote:
> > On Sat, 13 Feb 2010, Rafael J. Wysocki wrote:
> > 
> > > > The bigger problem is that with a normal sleep ("echo none >pm_test"),
> > > > the system doesn't wake up.  Pressing a key or a mouse button does
> > > > nothing.  Pressing the power button causes the machine to start up
> > > > again, but the screen remains blank and there's no response to network
> > > > pings.
> > > > 
> > > > This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
> > > > applied but none of your PM patches).  The motherboard is an Intel 
> > > > ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?
> > > 
> > > That depends on the graphics adapter.  Is it Intel or AMD?
> > 
> > $ lspci -s 2.0
> > 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
> 
> Well, that is supposed to work.  Do you have KMS turned on?

It's hard to tell.  CONFIG_DRM and CONFIG_DRM_HELPER were both set to M
and the i915 driver was loaded, which pulled both of them in as well.  
But lsmod showed that i915's usage count was 0 and there were no kernel
messages about the framebuffer device; the only relevant messages were:

[   41.814441] [drm] Initialized drm 1.1.0 20060810
[   41.869690] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   41.869705] pci 0000:00:02.0: setting latency timer to 64
[   41.883076] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Also, the console remained in the BIOS's original 80x25 video mode.  
Since I wasn't running X11 during the test, KMS shouldn't have made any
difference, right?

> > Do you need any more information than that?
> 
> Is the problem reproducible with init=/bin/bash vga=0?

Yes.  I tried booting with no initramfs and with "init=/bin/bash
vga=0".  Just as before the suspended machine didn't do anything when I
pressed keys on the keyboard, and pressing the power button caused it
to come back up totally unresponsive with the screen blank and the
CapsLock and ScrollLock lights blinking.

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Tuesday 16 February 2010, Alan Stern wrote:
> On Sun, 14 Feb 2010, Rafael J. Wysocki wrote:
> 
> > On Sunday 14 February 2010, Alan Stern wrote:
> > > On Sat, 13 Feb 2010, Rafael J. Wysocki wrote:
> > > 
> > > > > The bigger problem is that with a normal sleep ("echo none >pm_test"),
> > > > > the system doesn't wake up.  Pressing a key or a mouse button does
> > > > > nothing.  Pressing the power button causes the machine to start up
> > > > > again, but the screen remains blank and there's no response to network
> > > > > pings.
> > > > > 
> > > > > This was with more or less standard 2.6.33-rc6 (Greg KH's patch set was 
> > > > > applied but none of your PM patches).  The motherboard is an Intel 
> > > > > ICH5 with a 32-bit CPU.  Any ideas on ways to approach this?
> > > > 
> > > > That depends on the graphics adapter.  Is it Intel or AMD?
> > > 
> > > $ lspci -s 2.0
> > > 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)
> > 
> > Well, that is supposed to work.  Do you have KMS turned on?
> 
> It's hard to tell.  CONFIG_DRM and CONFIG_DRM_HELPER were both set to M
> and the i915 driver was loaded, which pulled both of them in as well.  
> But lsmod showed that i915's usage count was 0 and there were no kernel
> messages about the framebuffer device; the only relevant messages were:
> 
> [   41.814441] [drm] Initialized drm 1.1.0 20060810
> [   41.869690] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [   41.869705] pci 0000:00:02.0: setting latency timer to 64
> [   41.883076] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
> 
> Also, the console remained in the BIOS's original 80x25 video mode.  
> Since I wasn't running X11 during the test, KMS shouldn't have made any
> difference, right?
> 
> > > Do you need any more information than that?
> > 
> > Is the problem reproducible with init=/bin/bash vga=0?
> 
> Yes.  I tried booting with no initramfs and with "init=/bin/bash
> vga=0".  Just as before the suspended machine didn't do anything when I
> pressed keys on the keyboard, and pressing the power button caused it
> to come back up totally unresponsive with the screen blank and the
> CapsLock and ScrollLock lights blinking.

Hmm.  What about X86_CHECK_BIOS_CORRUPTION and friends?

Perhaps the BIOS steps onto the early wakeup code.

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Tue, 16 Feb 2010, Rafael J. Wysocki wrote:

> > > Is the problem reproducible with init=/bin/bash vga=0?
> > 
> > Yes.  I tried booting with no initramfs and with "init=/bin/bash
> > vga=0".  Just as before the suspended machine didn't do anything when I
> > pressed keys on the keyboard, and pressing the power button caused it
> > to come back up totally unresponsive with the screen blank and the
> > CapsLock and ScrollLock lights blinking.
> 
> Hmm.  What about X86_CHECK_BIOS_CORRUPTION and friends?

CONFIG_X86_CHECK_BIOS_CORRUPTION was not set.  I created a new kernel 
with:

CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW_64K=y

And then I booted with "memory_corruption_check=1 vga=0 init=/bin/bash" 
on the command line just to be sure.  There was a log message saying 
that low memory would be checked every 60 seconds, but no error 
messages appeared after waiting for a few minutes.

The behavior during resume was unchanged.

> Perhaps the BIOS steps onto the early wakeup code.

The difficulty is that I have no way to find out what's going on.  The
serial port isn't working (or nothing gets sent to it, or both) and the
system hangs before the video output gets enabled.

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Wednesday 17 February 2010, Alan Stern wrote:
> On Tue, 16 Feb 2010, Rafael J. Wysocki wrote:
> 
> > > > Is the problem reproducible with init=/bin/bash vga=0?
> > > 
> > > Yes.  I tried booting with no initramfs and with "init=/bin/bash
> > > vga=0".  Just as before the suspended machine didn't do anything when I
> > > pressed keys on the keyboard, and pressing the power button caused it
> > > to come back up totally unresponsive with the screen blank and the
> > > CapsLock and ScrollLock lights blinking.
> > 
> > Hmm.  What about X86_CHECK_BIOS_CORRUPTION and friends?
> 
> CONFIG_X86_CHECK_BIOS_CORRUPTION was not set.  I created a new kernel 
> with:
> 
> CONFIG_X86_CHECK_BIOS_CORRUPTION=y
> CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
> CONFIG_X86_RESERVE_LOW_64K=y
> 
> And then I booted with "memory_corruption_check=1 vga=0 init=/bin/bash" 
> on the command line just to be sure.  There was a log message saying 
> that low memory would be checked every 60 seconds, but no error 
> messages appeared after waiting for a few minutes.
> 
> The behavior during resume was unchanged.
> 
> > Perhaps the BIOS steps onto the early wakeup code.
> 
> The difficulty is that I have no way to find out what's going on.  The
> serial port isn't working (or nothing gets sent to it, or both) and the
> system hangs before the video output gets enabled.

You can try to put no_console_suspend into the kernel command line, but I doubt
it'll help with the serial resume.

Anyway, we need to check if control gets back to acpi_suspend_enter().

BTW, does anything change if you put acpi_sleep=sci_force_enable into the
kernel command line?

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Wed, 17 Feb 2010, Rafael J. Wysocki wrote:

> > The difficulty is that I have no way to find out what's going on.  The
> > serial port isn't working (or nothing gets sent to it, or both) and the
> > system hangs before the video output gets enabled.
> 
> You can try to put no_console_suspend into the kernel command line, but I doubt
> it'll help with the serial resume.

It has been there all along.

> Anyway, we need to check if control gets back to acpi_suspend_enter().
> 
> BTW, does anything change if you put acpi_sleep=sci_force_enable into the
> kernel command line?

Nothing changes.  I also added "pci=use_crs", based on a suggestion in 
the log, but that didn't make any difference either.

Alan Stern

Re: Two problems with system sleep

[Alan Stern]

On Sun, 21 Feb 2010, Rafael J. Wysocki wrote:

> > > Anyway, we need to check if control gets back to acpi_suspend_enter().

Would PM_TRACE_RTC help?  What would I have to add in order to insert
an appropriate tracepoint?


> > > BTW, does anything change if you put acpi_sleep=sci_force_enable into the
> > > kernel command line?
> > 
> > Nothing changes.  I also added "pci=use_crs", based on a suggestion in 
> > the log, but that didn't make any difference either.
> 
> The failure to resume may be graphics-related, so please try to compile i915
> statically into the kernel and set CONFIG_DRM_I915_KMS.

Odd -- when I use "make menuconfig", that part of the menu 
doesn't show up.  Navigating through "Device Drivers -> Graphics 
support" gives me this screen:

    <*> /dev/agpgart (AGP Support)  --->                             
    <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI suppor 
    -*- Lowlevel video output switch controls                        
    -*- Support for frame buffer devices  --->                       
    [ ] Backlight & LCD device support  --->                         
        Display device support  --->                                 
        Console display driver support  --->                         
    [ ] Bootup logo  --->                                            

None of the entries in drivers/gpu/drm/Kconfig show up beyond the first 
one.  I had to go in and edit .config by hand to set CONFIG_DRM, 
CONFIG_DRM_KMS_HELPER, CONFIG_DRM_I915, and CONFIG_DRM_I915_KMS all to 
"y".  Is this a bug in menuconfig?  CC'ing the mailing list...

Anyway, it didn't make any difference.  The behavior was exactly the 
same.  Pressing the power button during suspend causes an 
almost-instant hang, before the screen or anything else revives.

By concentrating on the video drivers, you may be missing part of 
the problem.  Have you considered why pressing a key on the keyboard 
doesn't wake the system up?  Nothing happens -- the power LED on the 
desktop case just keeps on blinking.

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Monday 22 February 2010, Alan Stern wrote:
> On Sun, 21 Feb 2010, Rafael J. Wysocki wrote:
> 
> > > > Anyway, we need to check if control gets back to acpi_suspend_enter().
> 
> Would PM_TRACE_RTC help?

In my opinion that's worth doing.

> What would I have to add in order to insert an appropriate tracepoint?

Please follow Documentation/power/s2ram.txt .

> > > > BTW, does anything change if you put acpi_sleep=sci_force_enable into the
> > > > kernel command line?
> > > 
> > > Nothing changes.  I also added "pci=use_crs", based on a suggestion in 
> > > the log, but that didn't make any difference either.
> > 
> > The failure to resume may be graphics-related, so please try to compile i915
> > statically into the kernel and set CONFIG_DRM_I915_KMS.
> 
> Odd -- when I use "make menuconfig", that part of the menu 
> doesn't show up.  Navigating through "Device Drivers -> Graphics 
> support" gives me this screen:
> 
>     <*> /dev/agpgart (AGP Support)  --->                             
>     <*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI suppor 
>     -*- Lowlevel video output switch controls                        
>     -*- Support for frame buffer devices  --->                       
>     [ ] Backlight & LCD device support  --->                         
>         Display device support  --->                                 
>         Console display driver support  --->                         
>     [ ] Bootup logo  --->                                            
> 
> None of the entries in drivers/gpu/drm/Kconfig show up beyond the first 
> one.  I had to go in and edit .config by hand to set CONFIG_DRM, 
> CONFIG_DRM_KMS_HELPER, CONFIG_DRM_I915, and CONFIG_DRM_I915_KMS all to 
> "y".  Is this a bug in menuconfig?  CC'ing the mailing list...
> 
> Anyway, it didn't make any difference.  The behavior was exactly the 
> same.  Pressing the power button during suspend causes an 
> almost-instant hang, before the screen or anything else revives.
> 
> By concentrating on the video drivers, you may be missing part of 
> the problem.  Have you considered why pressing a key on the keyboard 
> doesn't wake the system up?  Nothing happens -- the power LED on the 
> desktop case just keeps on blinking.

We may just not set up the keyboard as a wakeup device.  The other option is
that the BIOS has a problem with resume handling, in which case I have no
idea what to do.

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:

> On Monday 22 February 2010, Alan Stern wrote:
> > On Sun, 21 Feb 2010, Rafael J. Wysocki wrote:
> > 
> > > > > Anyway, we need to check if control gets back to acpi_suspend_enter().
> > 
> > Would PM_TRACE_RTC help?
> 
> In my opinion that's worth doing.

Here's what I got:

[    3.349334] PM: Resume from disk failed.
[    3.350060]   Magic number: 0:141:321
[    3.352583]   hash matches drivers/base/power/main.c:477
[    3.355144] tty tty46: hash matches
[    3.357742] i915 0000:00:02.0: hash matches

So it appears that the video driver is indeed the culprit.  Is there 
any way to narrow it down further?

> > By concentrating on the video drivers, you may be missing part of 
> > the problem.  Have you considered why pressing a key on the keyboard 
> > doesn't wake the system up?  Nothing happens -- the power LED on the 
> > desktop case just keeps on blinking.
> 
> We may just not set up the keyboard as a wakeup device.  The other option is
> that the BIOS has a problem with resume handling, in which case I have no
> idea what to do.

Here's my /proc/acpi/wakeup:

Device	S-state	  Status   Sysfs node
P0P4	  S4	 disabled  pci:0000:00:1e.0
MC97	  S4	 disabled  
USB1	  S4	 disabled  pci:0000:00:1d.0
USB2	  S4	 disabled  pci:0000:00:1d.1
USB3	  S4	 disabled  pci:0000:00:1d.2
USB4	  S4	 disabled  pci:0000:00:1d.3
EUSB	  S4	 disabled  pci:0000:00:1d.7
PS2K	  S4	 disabled  pnp:00:09
PS2M	  S4	 disabled  pnp:00:0a
GBEN	  S4	 disabled  

It appears that PS2K is the keyboard.  If I write "PS2K" to 
/proc/acpi/wakeup, I get:

ACPI: 'PS2M' and 'PS2K' have the same GPE, can't disable/enable one seperately

Apart from the misspelling, this doesn't bode well for making the
keyboard a wakeup device.  Furthermore, these values are not
properly tied to the values in sysfs.  For example, after

	echo enabled >/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup

the EUSB line in /proc/acpi/wakeup still says disabled.

What next?

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Monday 22 February 2010, Alan Stern wrote:
> On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> 
> > On Monday 22 February 2010, Alan Stern wrote:
> > > On Sun, 21 Feb 2010, Rafael J. Wysocki wrote:
> > > 
> > > > > > Anyway, we need to check if control gets back to acpi_suspend_enter().
> > > 
> > > Would PM_TRACE_RTC help?
> > 
> > In my opinion that's worth doing.
> 
> Here's what I got:
> 
> [    3.349334] PM: Resume from disk failed.
> [    3.350060]   Magic number: 0:141:321
> [    3.352583]   hash matches drivers/base/power/main.c:477
> [    3.355144] tty tty46: hash matches
> [    3.357742] i915 0000:00:02.0: hash matches
> 
> So it appears that the video driver is indeed the culprit.  Is there 
> any way to narrow it down further?

Not without adding some debug code to the driver.

Which version of the kernel is this?

> > > By concentrating on the video drivers, you may be missing part of 
> > > the problem.  Have you considered why pressing a key on the keyboard 
> > > doesn't wake the system up?  Nothing happens -- the power LED on the 
> > > desktop case just keeps on blinking.
> > 
> > We may just not set up the keyboard as a wakeup device.  The other option is
> > that the BIOS has a problem with resume handling, in which case I have no
> > idea what to do.
> 
> Here's my /proc/acpi/wakeup:
> 
> Device	S-state	  Status   Sysfs node
> P0P4	  S4	 disabled  pci:0000:00:1e.0
> MC97	  S4	 disabled  
> USB1	  S4	 disabled  pci:0000:00:1d.0
> USB2	  S4	 disabled  pci:0000:00:1d.1
> USB3	  S4	 disabled  pci:0000:00:1d.2
> USB4	  S4	 disabled  pci:0000:00:1d.3
> EUSB	  S4	 disabled  pci:0000:00:1d.7
> PS2K	  S4	 disabled  pnp:00:09
> PS2M	  S4	 disabled  pnp:00:0a
> GBEN	  S4	 disabled  
> 
> It appears that PS2K is the keyboard.  If I write "PS2K" to 
> /proc/acpi/wakeup, I get:
> 
> ACPI: 'PS2M' and 'PS2K' have the same GPE, can't disable/enable one seperately
> 
> Apart from the misspelling, this doesn't bode well for making the
> keyboard a wakeup device.

This only means both will be enabled at the same time.

> Furthermore, these values are not properly tied to the values in sysfs.

They are independent and the sysfs values probably don't matter for these
devices.  What are the contents of /proc/acpi/wakeup after writing PS2K to it?

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:

> > Here's what I got:
> > 
> > [    3.349334] PM: Resume from disk failed.
> > [    3.350060]   Magic number: 0:141:321
> > [    3.352583]   hash matches drivers/base/power/main.c:477
> > [    3.355144] tty tty46: hash matches
> > [    3.357742] i915 0000:00:02.0: hash matches
> > 
> > So it appears that the video driver is indeed the culprit.  Is there 
> > any way to narrow it down further?
> 
> Not without adding some debug code to the driver.
> 
> Which version of the kernel is this?

2.6.33-rc8.  The same problem occurs with earlier versions, such as
Fedora 12's 2.6.31.9 (which is what I'm running now).

> > Here's my /proc/acpi/wakeup:
> > 
> > Device	S-state	  Status   Sysfs node
> > P0P4	  S4	 disabled  pci:0000:00:1e.0
> > MC97	  S4	 disabled  
> > USB1	  S4	 disabled  pci:0000:00:1d.0
> > USB2	  S4	 disabled  pci:0000:00:1d.1
> > USB3	  S4	 disabled  pci:0000:00:1d.2
> > USB4	  S4	 disabled  pci:0000:00:1d.3
> > EUSB	  S4	 disabled  pci:0000:00:1d.7
> > PS2K	  S4	 disabled  pnp:00:09
> > PS2M	  S4	 disabled  pnp:00:0a
> > GBEN	  S4	 disabled  
> > 
> > It appears that PS2K is the keyboard.  If I write "PS2K" to 
> > /proc/acpi/wakeup, I get:
> > 
> > ACPI: 'PS2M' and 'PS2K' have the same GPE, can't disable/enable one seperately
> > 
> > Apart from the misspelling, this doesn't bode well for making the
> > keyboard a wakeup device.
> 
> This only means both will be enabled at the same time.
> 
> > Furthermore, these values are not properly tied to the values in sysfs.
> 
> They are independent and the sysfs values probably don't matter for these
> devices.  What are the contents of /proc/acpi/wakeup after writing PS2K to it?

Unchanged -- both PS2K and PS2M continue to be disabled.

Why are the values independent from the wakeup settings in sysfs?  
Aren't they supposed to mean the same thing?

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Monday 22 February 2010, you wrote:
> On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> 
> > > Here's what I got:
> > > 
> > > [    3.349334] PM: Resume from disk failed.
> > > [    3.350060]   Magic number: 0:141:321
> > > [    3.352583]   hash matches drivers/base/power/main.c:477
> > > [    3.355144] tty tty46: hash matches
> > > [    3.357742] i915 0000:00:02.0: hash matches
> > > 
> > > So it appears that the video driver is indeed the culprit.  Is there 
> > > any way to narrow it down further?
> > 
> > Not without adding some debug code to the driver.
> > 
> > Which version of the kernel is this?
> 
> 2.6.33-rc8.  The same problem occurs with earlier versions, such as
> Fedora 12's 2.6.31.9 (which is what I'm running now).

I _think_ think the i915 KMS doesn't work on your box for some reason.

Doesn the screen switch to the graphics framebuffer when booted with
vga=0?

If not, you probably need to enable framebuffer console in .config (the i915
KMS depends on that actually).

> > > Here's my /proc/acpi/wakeup:
> > > 
> > > Device	S-state	  Status   Sysfs node
> > > P0P4	  S4	 disabled  pci:0000:00:1e.0
> > > MC97	  S4	 disabled  
> > > USB1	  S4	 disabled  pci:0000:00:1d.0
> > > USB2	  S4	 disabled  pci:0000:00:1d.1
> > > USB3	  S4	 disabled  pci:0000:00:1d.2
> > > USB4	  S4	 disabled  pci:0000:00:1d.3
> > > EUSB	  S4	 disabled  pci:0000:00:1d.7
> > > PS2K	  S4	 disabled  pnp:00:09
> > > PS2M	  S4	 disabled  pnp:00:0a
> > > GBEN	  S4	 disabled  
> > > 
> > > It appears that PS2K is the keyboard.  If I write "PS2K" to 
> > > /proc/acpi/wakeup, I get:
> > > 
> > > ACPI: 'PS2M' and 'PS2K' have the same GPE, can't disable/enable one seperately
> > > 
> > > Apart from the misspelling, this doesn't bode well for making the
> > > keyboard a wakeup device.
> > 
> > This only means both will be enabled at the same time.
> > 
> > > Furthermore, these values are not properly tied to the values in sysfs.
> > 
> > They are independent and the sysfs values probably don't matter for these
> > devices.  What are the contents of /proc/acpi/wakeup after writing PS2K to it?
> 
> Unchanged -- both PS2K and PS2M continue to be disabled.

That sounds like a bug.  Please try to write 'PS2M' to it too.

> Why are the values independent from the wakeup settings in sysfs?  
> Aren't they supposed to mean the same thing?

Not really.  There are two separate flags for wakeup.  One of them is a
property of the "physical" device object (eg. PCI device structure) and that
one is set/unset via sysfs.  The other is a property of the device's ACPI
"shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
is regarded as obsolete, but it looks like some devices have not been converted
to the sysfs-based one yet).

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:

> On Monday 22 February 2010, you wrote:
> > On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> > 
> > > > Here's what I got:
> > > > 
> > > > [    3.349334] PM: Resume from disk failed.
> > > > [    3.350060]   Magic number: 0:141:321
> > > > [    3.352583]   hash matches drivers/base/power/main.c:477
> > > > [    3.355144] tty tty46: hash matches
> > > > [    3.357742] i915 0000:00:02.0: hash matches
> > > > 
> > > > So it appears that the video driver is indeed the culprit.  Is there 
> > > > any way to narrow it down further?
> > > 
> > > Not without adding some debug code to the driver.
> > > 
> > > Which version of the kernel is this?
> > 
> > 2.6.33-rc8.  The same problem occurs with earlier versions, such as
> > Fedora 12's 2.6.31.9 (which is what I'm running now).
> 
> I _think_ think the i915 KMS doesn't work on your box for some reason.
> 
> Doesn the screen switch to the graphics framebuffer when booted with
> vga=0?

Yes, it does switch.

> If not, you probably need to enable framebuffer console in .config (the i915
> KMS depends on that actually).

It's already enabled.  That is, CONFIG_FB and 
CONFIG_FRAMEBUFFER_CONSOLE are both set to 'y'.

> > > > Here's my /proc/acpi/wakeup:
> > > > 
> > > > Device	S-state	  Status   Sysfs node
> > > > P0P4	  S4	 disabled  pci:0000:00:1e.0
> > > > MC97	  S4	 disabled  
> > > > USB1	  S4	 disabled  pci:0000:00:1d.0
> > > > USB2	  S4	 disabled  pci:0000:00:1d.1
> > > > USB3	  S4	 disabled  pci:0000:00:1d.2
> > > > USB4	  S4	 disabled  pci:0000:00:1d.3
> > > > EUSB	  S4	 disabled  pci:0000:00:1d.7
> > > > PS2K	  S4	 disabled  pnp:00:09
> > > > PS2M	  S4	 disabled  pnp:00:0a
> > > > GBEN	  S4	 disabled  
> > > > 
> > > > It appears that PS2K is the keyboard.  If I write "PS2K" to 
> > > > /proc/acpi/wakeup, I get:
> > > > 
> > > > ACPI: 'PS2M' and 'PS2K' have the same GPE, can't disable/enable one seperately
> > > > 
> > > > Apart from the misspelling, this doesn't bode well for making the
> > > > keyboard a wakeup device.
> > > 
> > > This only means both will be enabled at the same time.
> > > 
> > > > Furthermore, these values are not properly tied to the values in sysfs.
> > > 
> > > They are independent and the sysfs values probably don't matter for these
> > > devices.  What are the contents of /proc/acpi/wakeup after writing PS2K to it?
> > 
> > Unchanged -- both PS2K and PS2M continue to be disabled.
> 
> That sounds like a bug.  Please try to write 'PS2M' to it too.

I was wrong (don't know why).  Writing PS2K does indeed enable both.  
And sure enough, doing that allows the system to wake up in response to
a key press.  It still hangs during the video resume, though.

> > Why are the values independent from the wakeup settings in sysfs?  
> > Aren't they supposed to mean the same thing?
> 
> Not really.  There are two separate flags for wakeup.  One of them is a
> property of the "physical" device object (eg. PCI device structure) and that
> one is set/unset via sysfs.  The other is a property of the device's ACPI
> "shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
> is regarded as obsolete, but it looks like some devices have not been converted
> to the sysfs-based one yet).

It looks like the inline routines defined in include/linux/pm_wakeup.h 
should call corresponding platform-specific routines.  Apparently _no_ 
drivers have been converted in this way -- since the conversion needs 
to be part of the core.  In fact, there isn't even a platform-specific 
hook for enabling or disabling wakeup devices; we should have a 
platform_wakeup_ops structure.

Would such a thing be acceptable?

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Tuesday 23 February 2010, Alan Stern wrote:
> On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> 
> > On Monday 22 February 2010, you wrote:
> > > On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> > > 
> > > > > Here's what I got:
> > > > > 
> > > > > [    3.349334] PM: Resume from disk failed.
> > > > > [    3.350060]   Magic number: 0:141:321
> > > > > [    3.352583]   hash matches drivers/base/power/main.c:477
> > > > > [    3.355144] tty tty46: hash matches
> > > > > [    3.357742] i915 0000:00:02.0: hash matches
> > > > > 
> > > > > So it appears that the video driver is indeed the culprit.  Is there 
> > > > > any way to narrow it down further?
> > > > 
> > > > Not without adding some debug code to the driver.
> > > > 
> > > > Which version of the kernel is this?
> > > 
> > > 2.6.33-rc8.  The same problem occurs with earlier versions, such as
> > > Fedora 12's 2.6.31.9 (which is what I'm running now).
> > 
> > I _think_ think the i915 KMS doesn't work on your box for some reason.
> > 
> > Doesn the screen switch to the graphics framebuffer when booted with
> > vga=0?
> 
> Yes, it does switch.

OK

> > If not, you probably need to enable framebuffer console in .config (the i915
> > KMS depends on that actually).
> 
> It's already enabled.  That is, CONFIG_FB and 
> CONFIG_FRAMEBUFFER_CONSOLE are both set to 'y'.

Well, so the KMS suspend-resume doesn't work on your system.

I guess that would require some detailed debugging, so it may be a good idea to
open a Bugzilla entry for this issue.

...
> I was wrong (don't know why).  Writing PS2K does indeed enable both.  
> And sure enough, doing that allows the system to wake up in response to
> a key press.  It still hangs during the video resume, though.
> 
> > > Why are the values independent from the wakeup settings in sysfs?  
> > > Aren't they supposed to mean the same thing?
> > 
> > Not really.  There are two separate flags for wakeup.  One of them is a
> > property of the "physical" device object (eg. PCI device structure) and that
> > one is set/unset via sysfs.  The other is a property of the device's ACPI
> > "shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
> > is regarded as obsolete, but it looks like some devices have not been converted
> > to the sysfs-based one yet).
> 
> It looks like the inline routines defined in include/linux/pm_wakeup.h 
> should call corresponding platform-specific routines.  Apparently _no_ 
> drivers have been converted in this way -- since the conversion needs 
> to be part of the core.  In fact, there isn't even a platform-specific 
> hook for enabling or disabling wakeup devices; we should have a 
> platform_wakeup_ops structure.

There is one for PCI devices, actually.  It's struct pci_platform_pm_ops()
defined in drivers/pci/pci.h.

For PCI devices we have pci_enable_wake() that sets up the platform to
wake up the system using given device on the basis of the device's sysfs
setting.  The ACPI flag shown by /proc/acpi/wakeup is not taken into account
in that case.

Generally, you can think of two levels one can enable wakeup at.
First, there is the device level controlled by the sysfs wakeup setting.  This
is how we would like to control wakeup.  Second, however, there is the
/proc/acpi/wakeup interface allowing you to access the _internal_ ACPI
representation of devices directly and you can use that to set up the platform
to use the device for wakeup even if the device level mechanism doesn't work
or is not implemented for it (like in your case).

IOW, the /proc/acpi/wakeup thing only tells us if the device is forced to do
the wakeup at the low level and it only takes the ACPI aspect of the wakeup
into account, which may not be sufficient.  For exmaple, network adapters
(and other PCI devices) generally need to have the PME signaling enabled
in addition to the platform setup and the chip has to be enabled to take
wakeup packets from the network.

If /proc/acpi/wakeup shows "enabled" this means "turn on the wakeup power
for this devices and enable its wakeup GPE unconditionally before suspend".
If it shows "disabled", it means "leave that to someone else" (that's analogous
to the "on" and "auto" settings for devices/.../power/control, but the names
are misleading for historical reasons).

So, it looks like we need a counterpart of pci_enable_wake() for PNP devices. 

I guess it's better to invite Dmitry into the discussion at this point.

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Tue, 23 Feb 2010, Rafael J. Wysocki wrote:

> > > I _think_ think the i915 KMS doesn't work on your box for some reason.
> > > 
> > > Doesn the screen switch to the graphics framebuffer when booted with
> > > vga=0?
> > 
> > Yes, it does switch.
> 
> OK
> 
> > > If not, you probably need to enable framebuffer console in .config (the i915
> > > KMS depends on that actually).
> > 
> > It's already enabled.  That is, CONFIG_FB and 
> > CONFIG_FRAMEBUFFER_CONSOLE are both set to 'y'.
> 
> Well, so the KMS suspend-resume doesn't work on your system.
> 
> I guess that would require some detailed debugging, so it may be a good idea to
> open a Bugzilla entry for this issue.

Okay, I'll set it up later.

> > > > Why are the values independent from the wakeup settings in sysfs?  
> > > > Aren't they supposed to mean the same thing?
> > > 
> > > Not really.  There are two separate flags for wakeup.  One of them is a
> > > property of the "physical" device object (eg. PCI device structure) and that
> > > one is set/unset via sysfs.  The other is a property of the device's ACPI
> > > "shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
> > > is regarded as obsolete, but it looks like some devices have not been converted
> > > to the sysfs-based one yet).
> > 
> > It looks like the inline routines defined in include/linux/pm_wakeup.h 
> > should call corresponding platform-specific routines.  Apparently _no_ 
> > drivers have been converted in this way -- since the conversion needs 
> > to be part of the core.  In fact, there isn't even a platform-specific 
> > hook for enabling or disabling wakeup devices; we should have a 
> > platform_wakeup_ops structure.
> 
> There is one for PCI devices, actually.  It's struct pci_platform_pm_ops()
> defined in drivers/pci/pci.h.
> 
> For PCI devices we have pci_enable_wake() that sets up the platform to
> wake up the system using given device on the basis of the device's sysfs
> setting.  The ACPI flag shown by /proc/acpi/wakeup is not taken into account
> in that case.

That's not what I meant.  Writing to /sys/devices/.../power/wakeup 
should have the same effect as writing to /proc/acpi/wakeup (if the 
device has a "shadow" ACPI counterpart, of course).  It looks like 
/proc/acpi/wakeup does nothing but set acpidev->wakeup.state.enabled 
and warn about duplicate GPE usage.

It would make sense to issue the warning when writing to the sysfs
file.  And wakeup.state.enabled shouldn't be needed at all; the ACPI
code should always use the physical device's may_wakeup flag instead
(unless there is no corresponding physical device).

If writes to the sysfs file called a platform hook, we could warn about 
duplicate GPEs when the wakeup setting is changed.

> Generally, you can think of two levels one can enable wakeup at.
> First, there is the device level controlled by the sysfs wakeup setting.  This
> is how we would like to control wakeup.  Second, however, there is the
> /proc/acpi/wakeup interface allowing you to access the _internal_ ACPI
> representation of devices directly and you can use that to set up the platform
> to use the device for wakeup even if the device level mechanism doesn't work
> or is not implemented for it (like in your case).
> 
> IOW, the /proc/acpi/wakeup thing only tells us if the device is forced to do
> the wakeup at the low level and it only takes the ACPI aspect of the wakeup
> into account, which may not be sufficient.  For exmaple, network adapters
> (and other PCI devices) generally need to have the PME signaling enabled
> in addition to the platform setup and the chip has to be enabled to take
> wakeup packets from the network.
> 
> If /proc/acpi/wakeup shows "enabled" this means "turn on the wakeup power
> for this devices and enable its wakeup GPE unconditionally before suspend".
> If it shows "disabled", it means "leave that to someone else" (that's analogous
> to the "on" and "auto" settings for devices/.../power/control, but the names
> are misleading for historical reasons).
> 
> So, it looks like we need a counterpart of pci_enable_wake() for PNP devices. 

That sounds reasonable.  ACPI could be made to work without such a 
thing, but other platforms probably would need it.

Alan Stern

Re: Two problems with system sleep

[Rafael J. Wysocki]

On Tuesday 23 February 2010, Alan Stern wrote:
> On Tue, 23 Feb 2010, Rafael J. Wysocki wrote:
> 
> > > > I _think_ think the i915 KMS doesn't work on your box for some reason.
> > > > 
> > > > Doesn the screen switch to the graphics framebuffer when booted with
> > > > vga=0?
> > > 
> > > Yes, it does switch.
> > 
> > OK
> > 
> > > > If not, you probably need to enable framebuffer console in .config (the i915
> > > > KMS depends on that actually).
> > > 
> > > It's already enabled.  That is, CONFIG_FB and 
> > > CONFIG_FRAMEBUFFER_CONSOLE are both set to 'y'.
> > 
> > Well, so the KMS suspend-resume doesn't work on your system.
> > 
> > I guess that would require some detailed debugging, so it may be a good idea to
> > open a Bugzilla entry for this issue.
> 
> Okay, I'll set it up later.
> 
> > > > > Why are the values independent from the wakeup settings in sysfs?  
> > > > > Aren't they supposed to mean the same thing?
> > > > 
> > > > Not really.  There are two separate flags for wakeup.  One of them is a
> > > > property of the "physical" device object (eg. PCI device structure) and that
> > > > one is set/unset via sysfs.  The other is a property of the device's ACPI
> > > > "shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
> > > > is regarded as obsolete, but it looks like some devices have not been converted
> > > > to the sysfs-based one yet).
> > > 
> > > It looks like the inline routines defined in include/linux/pm_wakeup.h 
> > > should call corresponding platform-specific routines.  Apparently _no_ 
> > > drivers have been converted in this way -- since the conversion needs 
> > > to be part of the core.  In fact, there isn't even a platform-specific 
> > > hook for enabling or disabling wakeup devices; we should have a 
> > > platform_wakeup_ops structure.
> > 
> > There is one for PCI devices, actually.  It's struct pci_platform_pm_ops()
> > defined in drivers/pci/pci.h.
> > 
> > For PCI devices we have pci_enable_wake() that sets up the platform to
> > wake up the system using given device on the basis of the device's sysfs
> > setting.  The ACPI flag shown by /proc/acpi/wakeup is not taken into account
> > in that case.
> 
> That's not what I meant.  Writing to /sys/devices/.../power/wakeup 
> should have the same effect as writing to /proc/acpi/wakeup (if the 
> device has a "shadow" ACPI counterpart, of course).

That really is not worth it.  The information about the sharing of a GPE is
only useful for debugging purposes and only in "really broken" cases.

> It looks like /proc/acpi/wakeup does nothing but set
> acpidev->wakeup.state.enabled and warn about duplicate GPE usage.

That's correct, although the warning itself doesn't really make sense,
because the sharing of the GPE doesn't mean we _have_ _to_ enable both devices
to wake up (the devices usually require some more preparations than just
setting the GPE).

> It would make sense to issue the warning when writing to the sysfs file.

That's not worth the added code complexity IMO.

> And wakeup.state.enabled shouldn't be needed at all;

Right, but it was there before.

> the ACPI code should always use the physical device's may_wakeup flag instead
> (unless there is no corresponding physical device).

No, it shouldn't, because it doesn't know if the device has actually been set
up for wakeup at its bus type level.

> If writes to the sysfs file called a platform hook, we could warn about 
> duplicate GPEs when the wakeup setting is changed.

As I wrote above, this is not worth it IMO.  Moreover, that doesn't really
matter, because the GPEs will be enabled as needed anyway and there's no real
need to tell the user which of them are shared except for debugging (at the
fairly low level).  Furthermore, the GPE refrence counting code we're going to
add shortly changes that quite a bit.

Generally speaking, I'd like to get rid of /proc/acpi/wakeup altogether or
maybe leave it as read-only without the "disabled/enabled" column.

However, there still are devices that don't have an alternative mechanism for
enabling wakeup, so we can't just drop it right now.

Rafael

Re: Two problems with system sleep

[Alan Stern]

On Wed, 24 Feb 2010, Rafael J. Wysocki wrote:

> > > Well, so the KMS suspend-resume doesn't work on your system.
> > > 
> > > I guess that would require some detailed debugging, so it may be a good idea to
> > > open a Bugzilla entry for this issue.
> > 
> > Okay, I'll set it up later.

Created as Bugzilla #15385.  I added you to the CC: list.  Further 
communication should be CC'ed to linux-pm and dri-devel.

Alan Stern

Re: Two problems with system sleep

[Dmitry Torokhov]

On Tue, Feb 23, 2010 at 10:02:04PM +0100, Rafael J. Wysocki wrote:
> On Tuesday 23 February 2010, Alan Stern wrote:
> > On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> > 
> > > On Monday 22 February 2010, you wrote:
> > > > On Mon, 22 Feb 2010, Rafael J. Wysocki wrote:
> > > > 
> > > > > > Here's what I got:
> > > > > > 
> > > > > > [    3.349334] PM: Resume from disk failed.
> > > > > > [    3.350060]   Magic number: 0:141:321
> > > > > > [    3.352583]   hash matches drivers/base/power/main.c:477
> > > > > > [    3.355144] tty tty46: hash matches
> > > > > > [    3.357742] i915 0000:00:02.0: hash matches
> > > > > > 
> > > > > > So it appears that the video driver is indeed the culprit.  Is there 
> > > > > > any way to narrow it down further?
> > > > > 
> > > > > Not without adding some debug code to the driver.
> > > > > 
> > > > > Which version of the kernel is this?
> > > > 
> > > > 2.6.33-rc8.  The same problem occurs with earlier versions, such as
> > > > Fedora 12's 2.6.31.9 (which is what I'm running now).
> > > 
> > > I _think_ think the i915 KMS doesn't work on your box for some reason.
> > > 
> > > Doesn the screen switch to the graphics framebuffer when booted with
> > > vga=0?
> > 
> > Yes, it does switch.
> 
> OK
> 
> > > If not, you probably need to enable framebuffer console in .config (the i915
> > > KMS depends on that actually).
> > 
> > It's already enabled.  That is, CONFIG_FB and 
> > CONFIG_FRAMEBUFFER_CONSOLE are both set to 'y'.
> 
> Well, so the KMS suspend-resume doesn't work on your system.
> 
> I guess that would require some detailed debugging, so it may be a good idea to
> open a Bugzilla entry for this issue.
> 
> ...
> > I was wrong (don't know why).  Writing PS2K does indeed enable both.  
> > And sure enough, doing that allows the system to wake up in response to
> > a key press.  It still hangs during the video resume, though.
> > 
> > > > Why are the values independent from the wakeup settings in sysfs?  
> > > > Aren't they supposed to mean the same thing?
> > > 
> > > Not really.  There are two separate flags for wakeup.  One of them is a
> > > property of the "physical" device object (eg. PCI device structure) and that
> > > one is set/unset via sysfs.  The other is a property of the device's ACPI
> > > "shadow" object and is set/unset through /proc/acpi/wakeup (this mechanism
> > > is regarded as obsolete, but it looks like some devices have not been converted
> > > to the sysfs-based one yet).
> > 
> > It looks like the inline routines defined in include/linux/pm_wakeup.h 
> > should call corresponding platform-specific routines.  Apparently _no_ 
> > drivers have been converted in this way -- since the conversion needs 
> > to be part of the core.  In fact, there isn't even a platform-specific 
> > hook for enabling or disabling wakeup devices; we should have a 
> > platform_wakeup_ops structure.
> 
> There is one for PCI devices, actually.  It's struct pci_platform_pm_ops()
> defined in drivers/pci/pci.h.
> 
> For PCI devices we have pci_enable_wake() that sets up the platform to
> wake up the system using given device on the basis of the device's sysfs
> setting.  The ACPI flag shown by /proc/acpi/wakeup is not taken into account
> in that case.
> 
> Generally, you can think of two levels one can enable wakeup at.
> First, there is the device level controlled by the sysfs wakeup setting.  This
> is how we would like to control wakeup.  Second, however, there is the
> /proc/acpi/wakeup interface allowing you to access the _internal_ ACPI
> representation of devices directly and you can use that to set up the platform
> to use the device for wakeup even if the device level mechanism doesn't work
> or is not implemented for it (like in your case).
> 
> IOW, the /proc/acpi/wakeup thing only tells us if the device is forced to do
> the wakeup at the low level and it only takes the ACPI aspect of the wakeup
> into account, which may not be sufficient.  For exmaple, network adapters
> (and other PCI devices) generally need to have the PME signaling enabled
> in addition to the platform setup and the chip has to be enabled to take
> wakeup packets from the network.
> 
> If /proc/acpi/wakeup shows "enabled" this means "turn on the wakeup power
> for this devices and enable its wakeup GPE unconditionally before suspend".
> If it shows "disabled", it means "leave that to someone else" (that's analogous
> to the "on" and "auto" settings for devices/.../power/control, but the names
> are misleading for historical reasons).
> 
> So, it looks like we need a counterpart of pci_enable_wake() for PNP devices. 
> 
> I guess it's better to invite Dmitry into the discussion at this point.
> 

Yes, I agree, we need a genric mechanism for PNP to emable wakups. It
was discussed a bit here:

	http://bugzilla.kernel.org/show_bug.cgi?id=8286

but David was too hung up on the fact that number of devices in ACPI
does not map directly onto number of serio ports when i8042 is in active
multiplexing mode that it id not go anywhere.

-- 
Dmitry

Re: Two problems with system sleep

[Alan Stern]

On Tue, 23 Feb 2010, Dmitry Torokhov wrote:

> Yes, I agree, we need a genric mechanism for PNP to emable wakups. It
> was discussed a bit here:
> 
> 	http://bugzilla.kernel.org/show_bug.cgi?id=8286
> 
> but David was too hung up on the fact that number of devices in ACPI
> does not map directly onto number of serio ports when i8042 is in active
> multiplexing mode that it id not go anywhere.

I tend to agree with your views.  Although there still is a question
about why my system has both /sys/devices/pnp0/00:09 and
/sys/devices/platform/i8042/serio0.  Since they refer to the same
keyboard device, why should there be two different sysfs nodes and two 
different drivers?

(Somewhat tangentially, why do the "i8042 aux" and "i8042 kbd"  
drivers on the pnp bus have names containing space characters?  Isn't
that likely to mess up shell scripts?)

At any rate, can the wakeup matter get fixed?  On my system I see two
issues related to the keyboard/mouse devices.  The first is that they
are not enabled for wakeup by default.  The second is that doing

	echo enabled >/sys/devices/pnp0/00:09/power/wakeup

does not actually enable the keyboard for wakeup; only writing to 
/proc/acpi/wakeup works.

Rafael's suggestion for a PNP analog of pci_enable_wake() should solve 
the second issue.  I don't know what's needed to solve the first.

Alan Stern