Bug 13225 - Severe problems with software suspend
Severe problems with software suspend
Status: CLOSED DUPLICATE of bug 14041
Product: ACPI
Classification: Unclassified
Component: BIOS
i386 Linux
: P1 blocking
Assigned To: acpi_bios
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2009-05-02 21:41 UTC by Artem S. Tashkinov
Modified: 2010-12-30 02:49 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.29
Tree: Mainline
Regression: Yes


Attachments
Miscellaneous /proc information, dmidecode/lspci/dmesg and kernel configs (45.10 KB, application/octet-stream)
2009-05-02 21:41 UTC, Artem S. Tashkinov
Details
dmesg after resume (19.26 KB, application/octet-stream)
2009-05-03 01:33 UTC, Artem S. Tashkinov
Details
dmesg before and after resume; kernel 2.6.30-rc5 (19.13 KB, application/octet-stream)
2009-05-17 09:33 UTC, Artem S. Tashkinov
Details
Xorg.0.log (4.84 KB, application/octet-stream)
2009-05-17 09:39 UTC, Artem S. Tashkinov
Details
printk for dmesg before and after resume; kernel 2.6.30-rc5 (18.99 KB, application/octet-stream)
2009-05-18 19:53 UTC, Artem S. Tashkinov
Details
printk for dmesg before and after resume; kernel 2.6.30-rc5; e100 removed (20.90 KB, application/octet-stream)
2009-05-19 15:28 UTC, Artem S. Tashkinov
Details
nv-hardreset-only-on-probing.patch (4.36 KB, patch)
2009-06-01 08:52 UTC, Tejun Heo
Details | Diff
dmesg for kernel 2.6.30-rc7 with nv-hardreset-only-on-probing.patch (19.20 KB, application/octet-stream)
2009-06-02 16:55 UTC, Artem S. Tashkinov
Details
dmesg/dmesg without e100/Xorg logs/.config (209.21 KB, application/octet-stream)
2009-06-02 19:08 UTC, Artem S. Tashkinov
Details
kernel 2.6.28.10 dmesg (21.11 KB, application/octet-stream)
2009-06-03 15:17 UTC, Artem S. Tashkinov
Details
config, lspci, dmidecode, dmesg before and after resume (27.51 KB, application/octet-stream)
2009-06-14 07:05 UTC, Ilya Hegai
Details

Description Artem S. Tashkinov 2009-05-02 21:41:48 UTC
Created attachment 21191 [details]
Miscellaneous /proc information, dmidecode/lspci/dmesg and kernel configs

Last kernel known to work: 2.6.28.x
Failing kernels: 2.6.29, 2.6.30 (rc4 as for now)

Hardware configuration:
CPU: Athlon 64 X2 5200
MB: Gigabyte M61P-S3
RAM: 4GB
GPU: NVIDIA 8800GT (with or *without* proprietary drivers)
TV card: GotView PCI DVD Lite (with or *without* ivtv drivers loaded)
Arch: i386 [kernel compiled for amd-k8 cpu]

lspci:
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
01:08.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 10)
01:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
01:09.0 Generic system peripheral [0841]: Creative Labs SB Live! EMU10k1 (rev 07)
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
01:09.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
01:07.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a2)
02:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GT (rev a2)

Bug description:

Since kernel 2.6.29 software suspend no longer works. The computer suspends successfully but then I cannot wake it up - it powers on but the screen remains black, network interfaces are inaccessible, keyboard buttons are not working (leds cannot be changed by pressing Caps Lock/Scroll Lock/etc).
Comment 1 Rafael J. Wysocki 2009-05-03 00:10:48 UTC
Do you mean hibernation or suspend to RAM?
Comment 2 Artem S. Tashkinov 2009-05-03 00:33:57 UTC
Yes, exactly.

(In Fedora 10 it's called `pm-suspend`).
Comment 3 Artem S. Tashkinov 2009-05-03 00:35:20 UTC
I meant "suspend to RAM". :)
Comment 4 Artem S. Tashkinov 2009-05-03 01:33:25 UTC
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).
Comment 5 Artem S. Tashkinov 2009-05-17 09:33:06 UTC
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.
Comment 6 Artem S. Tashkinov 2009-05-17 09:39:50 UTC
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.
Comment 7 Zhang Rui 2009-05-18 01:36:43 UTC
(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?
Comment 8 Artem S. Tashkinov 2009-05-18 19:53:11 UTC
Created attachment 21414 [details]
printk for dmesg before and after resume; kernel 2.6.30-rc5
Comment 9 Zhang Rui 2009-05-19 00:57:28 UTC
[    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.
Comment 10 Artem S. Tashkinov 2009-05-19 04:02:33 UTC
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.
Comment 11 Artem S. Tashkinov 2009-05-19 15:28:02 UTC
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?
Comment 12 Zhang Rui 2009-05-20 01:13:07 UTC
> 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.
Comment 13 Artem S. Tashkinov 2009-05-20 05:05:02 UTC
(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.
Comment 14 Artem S. Tashkinov 2009-05-25 06:25:35 UTC
> 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 :(
Comment 15 jog 2009-05-31 03:43:59 UTC
I have the exact same problem. I am using open source ATI radeon drivers on Ubuntu 9.04. dell inspiron 9200 pentium i386 laptop
Comment 16 Artem S. Tashkinov 2009-05-31 13:04:14 UTC
This bug is still valid. And I would be glad if someone changed it status to NEW.
Comment 17 Zhang Rui 2009-06-01 08:42:12 UTC
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.
Comment 18 Tejun Heo 2009-06-01 08:52:01 UTC
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.
Comment 19 Tejun Heo 2009-06-01 08:52:35 UTC
Created attachment 21681 [details]
nv-hardreset-only-on-probing.patch

Please test the attached patch and post kernel log.  Thanks.
Comment 20 Artem S. Tashkinov 2009-06-02 16:55:26 UTC
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.
Comment 21 Artem S. Tashkinov 2009-06-02 19:02:08 UTC
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.
Comment 22 Artem S. Tashkinov 2009-06-02 19:08:16 UTC
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.
Comment 23 Tejun Heo 2009-06-03 00:45:22 UTC
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.
Comment 24 Artem S. Tashkinov 2009-06-03 15:17:26 UTC
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.
Comment 25 Tejun Heo 2009-06-04 01:32:17 UTC
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.
Comment 26 Tejun Heo 2009-06-04 01:34:51 UTC
Aieee... crap, why is LFLAG_DISABLED being ignored?  I'm missing something.  I'll prep another patch soon.  Please standby a bit.  Thanks.
Comment 27 Tejun Heo 2009-06-05 01:30:15 UTC
Please ignore comment#26.  It was for different bug. :-(
Comment 28 Artem S. Tashkinov 2009-06-06 08:41:25 UTC
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 :-(
Comment 29 Artem S. Tashkinov 2009-06-07 13:34:32 UTC
> Please verify if it still should be listed and let me know (either way).

I do.
Comment 30 Miguel Sanjurjo 2009-06-08 22:14:59 UTC
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,
Comment 31 Zhang Rui 2009-06-09 02:41:07 UTC
as this is a regression from 2.6.28, can you run git-bisect to see which commit introduces this bug please?
Comment 32 Artem S. Tashkinov 2009-06-09 04:54:43 UTC
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.
Comment 33 jog 2009-06-11 01:43:43 UTC
I am able to resume fine after installing latest stable kernel 2.6.30 today
Comment 34 Zhang Rui 2009-06-11 02:14:59 UTC
good news.
can you verify which commit introduces this bug please?
Anyway, this bug has been fixed in the latest stable kernel. Close it.
Comment 35 Ilya Hegai 2009-06-14 07:05:54 UTC
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
Comment 36 Artem S. Tashkinov 2009-06-14 09:37:18 UTC
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.
Comment 37 Ilya Hegai 2009-07-06 09:00:05 UTC
2.6.30.1 - still no luck,
any activity on this?
any info we can provide?
Comment 38 Artem S. Tashkinov 2009-07-06 09:24:49 UTC
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.
Comment 39 Ilya Hegai 2009-07-06 10:08:11 UTC
>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
Comment 40 Artem S. Tashkinov 2009-07-06 12:19:22 UTC
(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).
Comment 41 Ilya Hegai 2009-07-06 12:47:40 UTC
I did it already in this report, here is an attach - http://bugzilla.kernel.org/attachment.cgi?id=21907
Comment 42 Ilya Hegai 2009-09-14 14:10:24 UTC
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)?
Comment 43 Zhang Rui 2009-09-15 05:34:07 UTC
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 ***
Comment 44 Artem S. Tashkinov 2009-09-15 11:15:39 UTC
I have a usual PC not a Sony laptop. :(

*** This bug has been marked as a duplicate of bug 14041 ***
Comment 45 Ivan Kalvachev 2009-10-10 17:47:45 UTC
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.
Comment 46 Artem S. Tashkinov 2009-10-11 12:38:16 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.