Bug 13225

Do you mean hibernation or suspend to RAM?

Yes, exactly.

(In Fedora 10 it's called `pm-suspend`).

I meant "suspend to RAM". :)

Created attachment 21194 [details]
dmesg after resume

My initial report wasn't completely right. The system indeed resumes but the screen remains black. I cannot reboot normally but SysRq+B works as well as I can change LEDs' state.

I've enabled PM_TRACE in kernel configuration and now I'm attaching dmesg after resume with and without ivtv modules (which can be a culprit).

Created attachment 21384 [details]
dmesg before and after resume; kernel 2.6.30-rc5

I should change the wording of the bug report again:

After software suspend (suspend2ram) I have the following problems:

1) The awaking process takes up to 30 seconds, during this time the system is absolutely unusable, e.g. keyboard is not working.

2) After the PC has resumed - I get no video signal at all. I can change the state of keyboard leds by pressing Num lock, but I cannot login in any of virtual text terminals - probably because after resume my system log contains (that doesn't happen with 2.6.28.10):

May 17 15:12:36 localhost kernel: Restarting tasks ... done.
May 17 15:12:36 localhost firmware.sh[2632]: udev firmware loader misses sysfs directory
May 17 15:13:38 localhost init: tty4 main process (2314) killed by TERM signal
May 17 15:13:38 localhost init: tty5 main process (2315) killed by TERM signal
May 17 15:13:38 localhost init: tty3 main process (2317) killed by TERM signal
May 17 15:13:38 localhost init: tty1 main process (2318) killed by TERM signal
May 17 15:13:38 localhost init: tty6 main process (2319) killed by TERM signal

Also this sequence doesn't work: "dmesg > ~/dmesg; pm-suspend; dmesg > ~/dmesg2; sleep 15; dmesg > ~/dmesg3; X & sleep 15; killall X; sleep 30; reboot"

I see dmesg dmesg2 and dmesg3 files, but the system is unable to reboot automatically. However I could reboot it using SysRq + B command.

Created attachment 21385 [details]
Xorg.0.log

BTW, X server seems to have started but I didn't notice that since the monitor remained black (and the monitor LED state remained in the yellow "sleeping state" vs. the normal running green state).

So as a part of awakening/resume process the monitor didn't return to a normal state - it remained a sleeping state.

(In reply to comment #5)
> Created an attachment (id=21384) [details]
> dmesg before and after resume; kernel 2.6.30-rc5
> 
> I should change the wording of the bug report again:
> 
> After software suspend (suspend2ram) I have the following problems:
> 
> 1) The awaking process takes up to 30 seconds, during this time the system is
> absolutely unusable, e.g. keyboard is not working.
> 
can you please add the boot option "printk.time=1", and re-attach the dmesg output after system resumes from S3?

Created attachment 21414 [details]
printk for dmesg before and after resume; kernel 2.6.30-rc5

[    5.040212] PM: Adding info for No Bus:controlC1
[    5.040232] PM: Adding info for No Bus:mixer1
[   59.602943] EXT3 FS on sda2, internal journal
[   59.711408] fuse init (API version 7.11)

there is also a long delay during the boot process, right?
can you speed up the resume/boot process by pressing any keys, or even power button?

[  155.667514] ata1.00: configured for UDMA/133
[  205.083332] PM: Removing info for No Bus:0000:01:08.0

01:08.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 10)

what if you remove the ethernet card driver before suspend?
please attach the dmesg output after resume in this case.

Kernel loads instantly (in less than three seconds) - I cannot quite understand why is this boot delay visible - it is not happening in a real life.

I will post the results with e100 driver removed later.

Created attachment 21430 [details]
printk for dmesg before and after resume; kernel 2.6.30-rc5; e100 removed

I have also attached pm-suspend.log, which upon resume says:

Tue May 19 21:11:23 YEKST 2009: Running hooks for resume
/usr/lib/pm-utils/sleep.d/99video resume suspend: Function not supported
kernel.acpi_video_flags = 0
success.

Could that be a problem?

> The awaking process takes up to 30 seconds,

does the problem still exist if you remove e100 driver before suspend?
it seems that it takes a little bit more than 10s to resume.

[  157.330849] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  157.337597] ata4.00: ACPI cmd ef/03:46:00:00:00:a0 filtered out
[  157.350936] ata4.00: configured for UDMA/66
[  162.344160] ata1: link is slow to respond, please be patient (ready=0)
[  167.197493] ata1: SRST failed (errno=-16)
[  167.350845] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  167.357589] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 filtered out
[  167.440860] ata1.00: configured for UDMA/133

this seems like a SATA problem.

(In reply to comment #12)
> > The awaking process takes up to 30 seconds,
> 
> does the problem still exist if you remove e100 driver before suspend?
> it seems that it takes a little bit more than 10s to resume.
> 
> [  157.330849] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [  157.337597] ata4.00: ACPI cmd ef/03:46:00:00:00:a0 filtered out
> [  157.350936] ata4.00: configured for UDMA/66
> [  162.344160] ata1: link is slow to respond, please be patient (ready=0)
> [  167.197493] ata1: SRST failed (errno=-16)
> [  167.350845] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [  167.357589] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 filtered out
> [  167.440860] ata1.00: configured for UDMA/133
> 
> this seems like a SATA problem.

I think not, slow SATA initialization is pretty common.

And last log is taken *without* loaded e100 kernel module - I rmmod'ed e100 before suspending.

> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.28 and 2.6.29.

> The following bug entry is on the current list of known regressions
> introduced between 2.6.28 and 2.6.29. Please verify if it still should
> be listed and let me know (either way).

Either way :)

BTW, I cannot change this bug status from NEEDINFO to NEW :(

I have the exact same problem. I am using open source ATI radeon drivers on Ubuntu 9.04. dell inspiron 9200 pentium i386 laptop

This bug is still valid. And I would be glad if someone changed it status to NEW.

From the dmesg attached, there is a huge difference w/ or w/o e100 driver,
i.e. the resume time reduces from about 60s to 10s, is that true?

[  157.350936] ata4.00: configured for UDMA/66
[  162.344160] ata1: link is slow to respond, please be patient (ready=0)
[  167.197493] ata1: SRST failed (errno=-16)
[  167.350845] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

The SATA software reset failed after resume from S3.
I don't know if this is common, but it seems that the 10s S3 resume latency is brought by this failure.
cc Tejun.

(In reply to comment #5)
> May 17 15:12:36 localhost firmware.sh[2632]: udev firmware loader misses
> sysfs
directory
> May 17 15:13:38 localhost init: tty4 main process (2314) killed by TERM
> signal

I didn't see this in the log you attached, please attach the full log.

The controller is nv which seems to have a lot of problems with reset protocol, so the delay isn't too unexpected.  I think the right thing to do would be to make resume asynchronous so that the rest can proceed without waiting, which I'm planning to do in time but till then I don't think there is much I can do about it.  Oh... right, one thing to try.  I have a patch which changes nv reset protocol.  It might make some difference.  I'll attach it.

Created attachment 21681 [details]
nv-hardreset-only-on-probing.patch

Please test the attached patch and post kernel log.  Thanks.

Created attachment 21713 [details]
dmesg for kernel 2.6.30-rc7 with nv-hardreset-only-on-probing.patch

The patch didn't help at all. Upon resume the screen remains black.

There's one thing I'd like to mention.

In my rc.local file I have this initialization string:

echo 70 > /sys/devices/platform/it87.656/pwm2

this command slows down the system fan so that it's not very noisy.

When I resume my PC with kernel 2.6.28 (where everything works) the system fan remains at the same speed as before suspend. In both 29 and 30 kernel the system resumes with this fan literally roaring - it looks like some kernel subsystem doesn't restore pre-suspend values.

Now, when I have a possibility to connect via SSH from a laptop brought here, here's a new information.

After resume, the computer is almost functioning (as always with display suspended - so no text consoles - only SSH).

Problems:

* Ethernet interface connected to e100 NIC is dead. No traffic goes in or out. It looks like I have to file a new bug report. If I `rmmod e100`, the computer almost hangs but I can still ping it (a different NIC, of course). SSH session after `rmmod e100` is dead, ssh daemon answers new connections but doesn't allow to establish connection or authorize user. So, essentially the system is dead but network stack is up.

* X server doesn't start with nv and vesa modules. However, remotely I managed to install the latest NVIDIA drivers and X server *with* nvidia module started successfully. But! if I switch to text console (chvt 1) the screen immediately blackens and the monitor goes into suspend mode. So, after resume something is seriously screwed up.

nv errors:
(EE) NV(0): Couldn't find the DDC routing table.  Mode setting will probably fail!
(EE) Screen(s) found, but none have a usable configuration.

vesa errors:
(EE) VESA(0): No matching modes
(EE) Screen(s) found, but none have a usable configuration.

Before suspend X org starts with both nv and vesa modules successfully.

Also it's quite amusing that after starting X server with NVIDIA driver the system fan returned to its previous normal RPM value. It seems like NVIDIA driver made the kernel restore some of its subsystems/settings:

[  100.181221] Restarting tasks ... done.
[  100.606305] PM: Removing info for No Bus:vcs63
[  100.606390] PM: Removing info for No Bus:vcsa63
[  186.523751] PM: Adding info for No Bus:vcs8
[  186.523799] PM: Adding info for No Bus:vcsa8
[  469.265349] Linux agpgart interface v0.103
[  469.303456] nvidia: module license 'NVIDIA' taints kernel.
[  469.303461] Disabling lock debugging due to kernel taint
[  469.560065] nvidia 0000:02:00.0: setting latency timer to 64
[  469.560251] NVRM: loading NVIDIA UNIX x86 Kernel Module  185.18.14  Wed May 27 02:23:13 PDT 2009
[  512.816938] nvidia 0000:02:00.0: setting latency timer to 64
[  512.817428] NVRM: loading NVIDIA UNIX x86 Kernel Module  185.18.14  Wed May 27 02:23:13 PDT 2009
[  513.903036] PM: Adding info for No Bus:i2c-2
[  513.903458] PM: Adding info for No Bus:i2c-2
[  513.903608] PM: Adding info for No Bus:i2c-3
[  513.903800] PM: Adding info for No Bus:i2c-3
[  513.904209] PM: Adding info for No Bus:i2c-4
[  513.907282] PM: Adding info for No Bus:i2c-4
[  593.772999] PM: Removing info for No Bus:vcs7
[  593.773084] PM: Removing info for No Bus:vcsa7
[  593.794048] PM: Adding info for No Bus:vcs7
[  593.794099] PM: Adding info for No Bus:vcsa7

* All text consoles are dead like I've already mentioned.

Created attachment 21715 [details]
dmesg/dmesg without e100/Xorg logs/.config

The archive is compressed using p7zip.

Run

$ 7z x log.7z

to extract/uncompress the files.

Hmmm... the timeout didn't go away.  Can you please post dmesg after resuming from 2.6.28.x?  Let's see if the ATA part is actually a regression.  Thanks.

Created attachment 21730 [details]
kernel 2.6.28.10 dmesg

It looks like slow SATA wakeup was here before 2.6.28, probably I have to test older kernels.

[  303.033779] sd 0:0:0:0: legacy resume
[  303.033781] sd 0:0:0:0: [sda] Starting disk
[  307.989978] ata1: link is slow to respond, please be patient (ready=0)
[  312.843311] ata1: SRST failed (errno=-16)
[  312.996662] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  313.003407] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 filtered out
[  313.087527] ata1.00: configured for UDMA/133

However I don't really care about 10 seconds boot delay as with 2.6.29/30 I cannot get the system resumed properly - that's what really annoys me.

Thanks.  Being a libata problem, I wanted to rule out libata induced regression. :-)

Although the initial reset failure after resume isn't optimal, it's known to happen on certain configurations especially on desktops as 3.5' drives usually take longer to spin up and depending on the controller reset protocol is known to fail under such circumstances.  libata tries to be robust for such cases and retry appropriately - the initial 10s retry interval is chosen to give most drives enough time to spin up while not inducing unreasonable amount of delay.  In the long run, the goal is to make libata wakeup async so that this type of delay can be made less visible.

Rafael, Zhang, please go on with the rest of the bug.

Thanks.

Aieee... crap, why is LFLAG_DISABLED being ignored?  I'm missing something.  I'll prep another patch soon.  Please standby a bit.  Thanks.

Please ignore comment#26.  It was for different bug. :-(

This bug status is again NEW. Why can't I make it so? I'm the owner of this bug!

Kernel bugzilla's is annoying :-(

> Please verify if it still should be listed and let me know (either way).

I do.

Suspend-to-ram (suspend-to-disk works perfectly) ceased resuming (blank screen, no input reaction, no backlight, no nothing) after upgrading to 2.6.29. With 2.6.28 (both gentoo-sources) it used to work great. Today, looking for ways to track the problem I enabled CONFIG_PM_DEBUG and guess what? I works again like it used to. I cannot understand why this is (specially because I don't use /sys/power/pm_test, it's set to 'none') but fact is that the mentioned setting allows me to resume from pm-suspend on my X31... with and without X running. I hope this helps,

as this is a regression from 2.6.28, can you run git-bisect to see which commit introduces this bug please?

You'll have to wait then. I don't think I will spot a bad commit easily taking into consideration up to fifty possible reboots and suspends.

I am able to resume fine after installing latest stable kernel 2.6.30 today

good news.
can you verify which commit introduces this bug please?
Anyway, this bug has been fixed in the latest stable kernel. Close it.

Created attachment 21907 [details]
config, lspci, dmidecode, dmesg before and after resume

still no luck for my sony vaio vgn-sr19vrn: no screen and frozen keyboard after resuming from suspend to ram

I've attached some information from my system

Actually, my problem isn't solved too but I've discovered that even with kernel 2.6.28.10 which I thought to be working, my system cannot resume if I run only a vesa console.

So, with X server and NVIDIA proprietary driver the system resumes normally in 2.6.28.x, but without X I get a black screen, i.e. the monitor is turned off.

With 2.6.30 the situation isn't any better - with vesa console the system resumes with a black screen, with X/NVIDIA I've got some garbage on the screen but X server is dead and doesn't respond to any key buttons combinations. SysRq keys also don't work.

With 2.6.30 and X/nv/vesa driver, the system resumes with a black screen and dead X server. Attempts to remotely start X server with this drivers fail.

I have changed this bug description to reflect my problem.

Also a dependency on 2.6.28 regressions tracking bug has been removed.

2.6.30.1 - still no luck,
any activity on this?
any info we can provide?

I suspect there can be several issues involved.

First of all my PC contains embedded GeForce 6150 GPU board and even though it is disabled when my PC detects a PCI-X GPU, I still suspect the BIOS can somehow mess up with the memory/IRQ/ACPI/etc resources upon resume.

The second possible concern which I am to check out soon is that probably it's a VESA console mode that conflicts with ... NVIDIA GPU (hardware allocations).

The third possible concern is that with the same kernel boot string I cannot boot into kernel 2.6.16.62 because as soon as kernel switches to VESA mode, my monitor switches off (that doesn't happen with newer kernel releases but they do not work correctly).

It seems like none of the kernel ACPI/suspend hackers possesses http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2434 this (or comparable) motherboard.

So, this bug needs more attention from the reporter (i.e. from me). However without the help from the kernel hackers I have no idea how I can help resolve this bug.

And other people who subscribed to this bug probably have different problems.

>And other people who subscribed to this bug probably have different problems.

actually, I have -=completely=- different hardware, but the same problem (I mean I can't resume)

may be I should leave this bug and report separate report to not confuse devs

(In reply to comment #39)
> >And other people who subscribed to this bug probably have different
> problems.
> 
> actually, I have -=completely=- different hardware, but the same problem (I
> mean I can't resume)
> 
> may be I should leave this bug and report separate report to not confuse devs

My problem is that my PC actually resumes but display doesn't switch on. Anyway I believe you should file a new bug report adding necessary information like lspci output, etc. (you can post the same files and information as in my attachment http://bugzilla.kernel.org/attachment.cgi?id=21191).

I did it already in this report, here is an attach - http://bugzilla.kernel.org/attachment.cgi?id=21907

ok, I've discovered the solution of my problem, It's CONFIG_SONY_LAPTOP module, disabling it solving suspend/resume

Should I open new bug and you (maintainers) assign it to a sony module maintainer or just forget about this module (I can live without it, but since then it's impossible to change brightness of display)?

please re-open this bug if it's not a duplicate of bug #13148.

*** This bug has been marked as a duplicate of bug 13148 ***

I have a usual PC not a Sony laptop. :(

*** This bug has been marked as a duplicate of bug 14041 ***

Artem,
I have bumped into very similar issue with e100 driver since 2.6.29 kernel.
Take a look of my report at http://sourceforge.net/tracker/?atid=447449&group_id=42302&func=browse

The workaround is to embed the e100 firmware into the kernel, as user-land firmware loader cannot run while userland is frozen.

Ivan, thanks for the information, however as I mentioned earlier my BIOS is likely to be broken since Windows XP SP3 cannot resume on this PC.

I will try to test everything after I downgrade my BIOS.