Bug 187955

Looks like the hard disk is not fully awake, or what do you think, Holger?
Phillip, two questions:
 - suspend to disk is working without problems?
 - can you please add the last 200 lines of /var/log/messages after the resume to that bug? (I think there will be some messages concerning the harddisk)

Created attachment 91621 [details]
last 200 lines of /var/log/messages after suspend2ram

Here are the last 200 lines of /var/log/messages right after a suspend2ram. I booted into runlevel 1 and started syslog+network by hand. Then I executed s2ram -f.

The last entry in the syslog before the suspend2ram is at 12:25:01. It seems that nothing gets written into the log anymore after that, because the harddrive doesn't wake up properly (?)

I had a terminal open where I watched /var/log/messages, and there were in fact additional messages which don't show up in the file after reboot anymore. I wrote them down and try to summarize them here:
- 2x changing permissions on special file ...
- Freezing cpus
- 7x Breaking affinity for irq ...
- CPU1 is now offline
- CPU1 is down
- ata1: suspend device
- ahci: 0000:00:1f.2 suspend PCI device
- intel machine check architecture supported
- intel machine check ??<can't read my scribbles> enabled on CPU#0
- Back to C!
- ACPI: PCI Interrupt ... <several times>
- PCI: Setting latency timer of device ... <several times>
- usb usb2: root hub lowst pwer or was reset.

I also tried "powersave -u" in runlevel 5. Then I got additional messages, as follows:

ata1: enabling interrupts
ata1: resume device
ata1: SATA link up 1.5Gbps (SSatus 113)

Although this looks more promising, I had the same Input/Output errors as before

As for suspend to disk: this works fine, but only if service alsasound is disabled. Otherwise there seems to be a problem with the module "snd_hda_intel" (error message during suspend and boots into system instead of resume). However, for suspend2ram disabling alsasound does not help.

B.t.w., I reinstalled SuSE10.1 on the weekend, but I remember that with the previous installation suspend2disk worked fine even without disabling alsasound. But the suspend2ram Input/Output error was present anyhow.

Thanks for your efforts with writing this down. 

I don't think the sound problem is related to the suspend to ram failures, though. Can you open another bug for this sound/suspend to disk problem? Please assign it to tiwai@suse.de and take me into CC.

All the other messages are not critical IMO. So it looks indeed like those SATA problems we already encountered on other machines before.

Taking Hannes into NEEDINFO because I'm not sure to whom to assign this then...

Thanks, Holger. But I have to revise my statement. Suspend to DISK works fine, even with alsasound loaded. 

Initially I would say that the Intel HDA sound chip is to blame.
Please unload / stop alsasound prior to suspend to RAM.

If it still doesn't work it looks like a bug in the AHCI driver.
Otherwise it's the sound chip; we had some problems with it due to buggy hw implementations already.

This resume issue sounds related to a resume issue I have experienced on an Intel D915GAV motherboard with the latest bios and a SATA hd (smp verison of kernel).  Simply put, suspend works fine and resume appears ok initially.  However, any action that requires write access to the hd generates an I/O error. As a result, don't bother asking for logs because nothing is written to them after resume.  The system cannot even shut down as a result and requires a power reset.  This system suspended and resumed fine with opensuse 10.0 and the resume issue didn't surface until after a opensuse 10.1 upgrade or clean install. 

Feedback from the suspend-develop list implied it wasn't a s2ram problem but a driver problem but nothing beyond that was offered.

I decided I should mention this because I just tried out the new opensuse-factory package management/kernel 2.6.16.21 update on an Intel D865GBF mb/SATA hd system and the upgrade creates the exact same resume I/O error issue.  In other words, after the kernel upgrade, nothing can be written to the hard drive after it resumes.  It pretty much disables any application that requires write acess so the system is mostly unusable until it gets rebooted. Suspend/resume on this D865GBF system works with 2.6.16.20-2-smp kernels and earlier using the "s2ram -f -a2" combination.  No combination works with the D915GAV system above.

Whatever is causing the problem somehow prevents write access to the hd after resume but that is the only info I can offer.  Both systems use SATA hard drives.

(In reply to comment #8)
> Initially I would say that the Intel HDA sound chip is to blame.
> Please unload / stop alsasound prior to suspend to RAM.
> 
> If it still doesn't work it looks like a bug in the AHCI driver.
> Otherwise it's the sound chip; we had some problems with it due to buggy hw
> implementations already.

sorry for the long delay, I was away for two weeks.

Stopping alsasound (which unloads all snd* modules) doesn't help. Same effect. However I found something out else, see my next comment.

The bios has an option to disable native sata. I disabled this an created a new initrd with "ata_piix" instead of "piix" and "ahci", so that I could boot without sata. Now a suspend to ram + resume worked partially, at least the Input/Output error was gone. So this seems to be in fact a sata-bug. 

However, now the inernal keyboard hanged after resume (my external USB keyboard still worked). So first I recompiled the kernel in order to have atkbd as a module. Removing this module before a suspend and reinserting it after a resume fixed this problem. But now there was the Input/Output problem again!

This Input/Output problem was finally fixed by stopping alsasound before a suspend. And in fact, it seems that the keyboard problem doesn't occur either, if alsasound is stopped before a suspend.

I haven't tested suspend thoroughly with this setup (no native sata, stopping alsasound) yet, but there seem to be some minor problems like kde-kicker crashes (due to stopping alsasound) and a black screen after restarting X (i.e. logging out from kde or windowmaker). But these are different bugs...
It seems that the module which needs to be unloaded is snd_hda_intel.

I hope this helps!

So after figuring out that alsasound seems to be the culprit (or at least one culprit), I'm reassinging this bug to Takashi.

Does restarting alsasound init script after resume work?

> Does restarting alsasound init script after resume work?

with SATA enabled: NO, resume does NOT work (Input/Output error) no matter whether alsasound was enabled or not

with IDE: partially. Sometimes resume works if alsasound is stopped. I can then restart alsasound "by hand" (the powersaved-scripts to restart the service fail to restart it after a resume). However, even with alsasound stopped I can't resume reliably (often the system crashes).

another problem with alsasound is that kicker crashes when I shut alsasound down while kde is running.

What I asked is whether you can restart alsasound init script and use the sound properly after suspend-to-ram or suspend-to-disk if you unload sound before suspend.

The problem of kicker is unavoidable.  It keeps opening the sound device, so it must be killed before unloading the driver.

Sound works properly after suspend-to-ram (IDE-mode), but not after suspend-to-disk (but I have tried suspend-to-disk in SATA mode, only). 

In IDE-mode it seems that resume from suspend-to-ram works fine as long as I resume after a short time (5 sec. or so). If the laptop is suspended too long (couple of minutes), then I get an Input/Output error after resume. I haven't tested that very thoroughly, though. If you think this might be of value, I can make more tests.

(In reply to comment #15)
> What I asked is whether you can restart alsasound init script and use the sound
> properly after suspend-to-ram or suspend-to-disk if you unload sound before
> suspend.
> 
> The problem of kicker is unavoidable.  It keeps opening the sound device, so it
> must be killed before unloading the driver.
> 

Sorry for the last post, I accidentially hit the enter button...
I just wanted to ask whether there is any additional information I can provide about that problem?

The fix is in the upstream (for 2.6.21 kernel), resolved to LATER for now.

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)

Already fixed.