Bug 6935 - Problem with suspend/hibernate in Mageia 2
Summary: Problem with suspend/hibernate in Mageia 2
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-02 18:02 CEST by Tolhildan Karker
Modified: 2013-11-23 16:15 CET (History)
5 users (show)

See Also:
Source RPM: kernel
CVE:
Status comment:


Attachments
syslog of Mageia 2 x86_64 (246.68 KB, application/octet-stream)
2012-08-06 16:20 CEST, Wim Edelman
Details
syslog of suspending and hibernating with Cauldron (431.87 KB, application/octet-stream)
2012-08-12 22:16 CEST, Wim Edelman
Details

Description Tolhildan Karker 2012-08-02 18:02:58 CEST
I have difficulties with suspend and hibernate under Mageia 2. I have tested all kernels for mga2 both core update and core update testing. For both kernel-desktop and kernel-linus. Same goes for cauldron (right now mga3). 

When using nouveau driver following things happens:
With nouveau driver it goes to sleep when running suspend. It takes a really long time. More then it should do. Wake up gives black screen. 

When using nvidia driver following things happens: 
Like for nouveau going to sleep with suspend takes a long time, but with nvidia drivers wake up works correctly. 

I have also tried suspend in Mageia 2 liveusb and there suspend does not work. Neither wake up or sleep. Kubuntu 12.04 running from liveusb with kernel 3.2.* suspend works correctly. 

Summering this up:
Sleep (Suspend): Works. But takes to much time to go to sleep.
Wake up (Suspend): Works with nvidia drivers and fails with nouveau. 

I remember when only using wired connection I could get suspend to work when I removed wired connection cable and unplug the battery-charger from my laptop. Before going to sleep, after wake up I connected wired connection and pluged battery-charger. After that suspend worked smoothly, but I needed to do that after every reboot or boot up. 

Now I am at my parents place and I can only use wireless. So I cannot test if the above about procedure will work or not. Same procedure does not work for the wireless. 

Hardware info:
http://paste.kde.org/524414/
Comment 1 Shlomi Fish 2012-08-02 18:18:18 CEST
Here is the hardware info from the link, in case the paste is removed:

    System:    Host: localhost.localdomain Kernel: 3.5.0-desktop586-1.mga3 i686 (32 bit)
               Desktop: KDE 4.8.4 Distro: "Mageia" 2 thornicroft
    Machine:   System: FUJITSU SIEMENS product: AMILO Pa 1538 version: REFERENCE
               Mobo: FUJITSU SIEMENS model: PTB50 version: 0.6 Bios: Phoenix version: 1.1Q-5821-8A20 date: 10/24/08
    CPU:       Dual core AMD Turion 64 X2 Mobile TL-50 (-MCP-) clocked at 800.00 MHz
    Graphics:  Card: nVidia G72M [GeForce Go 7400] X.Org: 1.11.4 drivers: nvidia,v4l Resolution: 1280x800@60.0hz
               GLX Renderer: GeForce Go 7400/PCIe/SSE2/3DNOW! GLX Version: 2.1.2 NVIDIA 295.59
    Network:   Card-1: Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) driver: ath5k
               Card-2: nVidia MCP51 Ethernet Controller driver: forcedeth
    Drives:    HDD Total Size: 160.0GB (50.2% used)

CC: (none) => shlomif

Comment 2 Tolhildan Karker 2012-08-03 13:25:58 CEST
Thanks Shlomi!

More info:
I have now also tried Fedora 17 liveusb with kernel 3.3.4 and same issue also there. In fedora from liveusb at least sleep (suspend) worked, but did take a long time. Also in fedora wake up (suspend) gives black screen. Of course I tried with the nouveau drivers that Fedora 17 comes with default. So I think the kernels 3.3.* and newer seems to dislike my laptop when it comes to suspend/hibernate. Is it possible to request kernel 3.2.* and also blob drivers for it? It feels that is the only solution for me if I wanted to run Mageia 2 with working suspend/hibernate. 

Thanks!
Comment 3 Tolhildan Karker 2012-08-03 14:21:08 CEST
The kernel developers have also added a "suspend to both" feature that makes hybrid standby possible. This feature allows memory contents to be buffered in RAM and on a system's storage device while the system is sleeping. Normally, the computer will then use the data in memory and resume just like it normally would from Suspend to RAM; in case of a power cut, however, the system will retrieve the previous RAM contents from the drive as it would do when resuming from Suspend to Disk. This allows users to always find their working environment as it was before the system went to sleep รข even if, for instance, the notebook battery had lost all of its power in the interim.

Source:
http://www.h-online.com/open/features/Kernel-Log-Development-of-Linux-3-6-under-way-1657742.html

git-source:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=62c552ccc3eda1198632a4f344aa32623d226bab

Can this also be possible solution? Maybe nothing to do with my problem.
Comment 4 Shlomi Fish 2012-08-03 15:04:52 CEST
Hi Tolhildan,

(In reply to comment #2)
> Thanks Shlomi!
> 
> More info:
> I have now also tried Fedora 17 liveusb with kernel 3.3.4 and same issue also
> there. In fedora from liveusb at least sleep (suspend) worked, but did take a
> long time. Also in fedora wake up (suspend) gives black screen. Of course I
> tried with the nouveau drivers that Fedora 17 comes with default. So I think
> the kernels 3.3.* and newer seems to dislike my laptop when it comes to
> suspend/hibernate. Is it possible to request kernel 3.2.* and also blob drivers
> for it? It feels that is the only solution for me if I wanted to run Mageia 2
> with working suspend/hibernate. 
> 

Downgrading the distribution kernel will likely cause many problems for many people, and will not be an easy "upgrade" without Epoch: games, which should really be avoided.

One option for you would be to build 3.2.x kernel from sources and use that instead of the distribution kernel. I can provide some assistance and guidance for doing that.

Regards,

-- Shlomi Fish
Comment 5 Tolhildan Karker 2012-08-04 14:18:37 CEST
I have installed kernel-linus from mandriva for version 3.2.18 and suspend/hibernate works perfect. I know it is not the best solution, but right now I needed solution if I still wanted to run Mageia. Much easier then compiling kernel. So if tmb could create kernel-linus with the latest 3.2 that is Mageia specific I would be glad. If not, I will keep on using mandrivas kernel-linus. 

Thanks!
Comment 6 Franz Holzinger 2012-08-04 15:30:58 CEST
I cannot change into 'hibernate' mode im Mageia 2. It simply does nothing. This has worked fine in Mageia 1.

CC: (none) => flink

Comment 7 Wim Edelman 2012-08-06 16:20:18 CEST
Created attachment 2613 [details]
syslog of Mageia 2 x86_64

Syslog of some cycles of starting and suspending (if possible).
Comment 8 Wim Edelman 2012-08-06 16:21:42 CEST
I experience problems with suspending and hibernation with Mageia 2 too.

Booting starts with the message: MP-BIOS bug: 8254: Timer not connected too IO-APIC.
Most times supending succeeds, but takes about 1 minute before pc goes down. Awakening succeeds sometimes, but sometimes not.

I tried the the Cauldron-kernel kernel-desktop-3.5.0-1.mga3-1-1.mga3.x86_64 too, but with similar bad results.

Hibernation does not succeed.
I added a syslog file with some cycles of starting the pc and going in supension and awakening (if possible).

My system consists of:
motherboard: Gigabyte M55S-S3 rev.1.0
videochipset Nvidia G73 [GeForce 7300 GT] (I use the nouveau driver).

CC: (none) => w.f.edelman
Hardware: i586 => x86_64

Tolhildan Karker 2012-08-06 16:24:51 CEST

Hardware: x86_64 => All

Comment 9 Franz Holzinger 2012-08-06 16:41:23 CEST
I have found out, that the move into the Hibernate/Suspend mode works in GNOME and it does not work in KDE.
At the moment I cannot go back to KDE any more. In the Mandriva Control Center KDE is set as the boot desktop, however this is ignored.
Comment 10 Tolhildan Karker 2012-08-09 17:13:15 CEST
tmb or other people in our team, do you guys have contact with kernel developers upstream? It would be good if you guys could contact them about this issue. 

Thanks!
Comment 11 Shlomi Fish 2012-08-10 11:22:51 CEST
Hi Tolhildan,

(In reply to comment #10)
> tmb or other people in our team, do you guys have contact with kernel
> developers upstream? It would be good if you guys could contact them about this
> issue. 
> 
> Thanks!

please read this entire message before proceeding.

You can file a bug against the kernel here:

https://bugzilla.kernel.org/

And you can send a message to the Linux Kernel Mailing List by following this:

http://www.tux.org/lkml/#s3-13

However, note that:

1. They will not support you if you have a "tainted" kernel (i.e: a kernel with proprietary, non-open-source, drivers).

2. They may expect you to try to reproduce the problem with an up-to-date version of the kernel that is compiled from source on your system, to see if the problem is still present there.

3. They can be somewhat hostile and ban you if you're annoying them too much (it happened to me), so be careful.

Regards,

-- Shlomi Fish
Comment 12 Tolhildan Karker 2012-08-10 22:36:13 CEST
Hi Shlomi I hava answered you in the channel. I have created account and even with correct username/password I fail to log in. You also know now my laptop is not in shape for compiling my own kernel. 

Regards
Ezim/Berxwedan
Comment 13 Tolhildan Karker 2012-08-11 11:19:33 CEST
I have just tested kernel-linus-3.5.1. The latest stable 3.5.1 kernel and the result is:

Sleep (Suspend): Works. But takes to much time to go to sleep.
Wake up (Suspend): Works with nvidia drivers and fails with nouveau.

Nothing have changed with newer kernel. :(
Comment 14 Wim Edelman 2012-08-12 22:16:19 CEST
Created attachment 2639 [details]
syslog of suspending and hibernating with Cauldron
Comment 15 Wim Edelman 2012-08-12 22:18:01 CEST
Comment on attachment 2639 [details]
syslog of suspending and hibernating with Cauldron

I tried Cauldron today with the latest updates (kernel 3.5.0-desktop-1.mga3).
Booting still starts with the message: MP-BIOS bug: 8254 Timer not connected
too
IO-APIC.
Suspending to RAM seems to work well now. I succeeded 3 cycles of going down
and awakening without the need to restart the pc. But going down still takes a
lot of time (much more than with mageia 1).
Hibernating does still not work.
I added a syslog. It shows starting the pc, the 3 cycles of suspending to RAM,
stopping the pc, restarting the pc and the trial to hibernate.
Comment 16 Tolhildan Karker 2012-08-20 18:45:51 CEST
Still same issue with kernel 3.5.2. I cannot figure out what the kernel devs have made wrong. It seems that I will be stucked with kernel 3.2.* for a long time. :(
Comment 17 Wim Edelman 2012-08-22 11:53:26 CEST
In the last weeks I experimented with a number of distributions (Mageia 1, 2 and Cauldron, Mandriva 2011, ROSA Marathon, Suse 12.1 and 12.2RC2), a lot of kernels and different kernel-options.
My findings are:

Suspending to RAM (Sleeping):
Up to kernel 3.2 suspending to RAM and awakening works with the nouveau and NVIDIA video drivers. It did not work with the nv-driver.
With kernels 3.3 and later I had to pass the kernel options "nolapic" and "irqpoll". Passing these options Mageia 2 suspended to Ram and awakened reliable and fast with kernel 3.3.6-2 and 3.5.2-1 as well. Cauldron with kernel 3.5.2-1 gives with these options the same result.

Suspending to disk (Hibernating)
Passing the kernel options "nolapic"and "irqpoll" with kernels 3.3 and later resulted in awakening where it did not without these options. At least awakening went much faster. The first was the matter with Cauldron.
In all cases hibernating worked only when the following conditions were fullfilled:
- The booting system around the kernel may not have bugs. It seems to me that Mageia 2 does not fullfill this condition.
- With a multiboot system, then the Grub of the system that must hibernate must point to the MBR.

I discovered that the message "MP-BIOS bug 8254: Timer not connected to IO-APIC" is not relevant.
Comment 18 Wim Edelman 2012-08-30 21:11:53 CEST
After the kernel-updating to kernel 3.3.8-2 suspending to RAM (sleeping) and suspending to disk (hibernation) are working on my system, provided that at booting the kernel options "nolapic" and "irqpoll" have been passed.
Hibernating seems going better if there have no kernel options like "splash=silent" and "quiet" been passed.
Comment 19 Tolhildan Karker 2012-08-30 21:39:32 CEST
Wim Edelman will test to add nolapic and irqpoll to the kernel option. Is there any stability issue when adding "nolapic" and "irqpoll" for you?

Only usefull information about both of them I find:
https://help.ubuntu.com/community/BootOptions
Comment 20 Tolhildan Karker 2012-08-30 22:25:59 CEST
Wim Edelman putting kernel option "nolapic" and "irqpoll" makes suspend respons like it should do. Like have with kernel 3.2.18. I am on kernel 3.5.2 (mga3 kernel) and with does two option suspend seems working like it should. I wonder why does two kernel option is needed for suspend to work? Great progress but it would be better if it would be fixed upstream.

I cannot get hibernate working. Even after removing "splash" and "quite". Did not make any difference. With kernel 3.2.18 hibernate works like it should do. I have tested a lot of kernel from 3.3.* and newer with same result. But thanks to your tips with "nolapic" and "irqpoll" at least suspend respons the way it should (fast).
Comment 21 Tolhildan Karker 2012-09-13 09:04:36 CEST
For me adding "irqpoll" is enough to get suspend working. Because adding "nolapic" kills one of my CPU, so only one is using. Not optimal. But hibernate is still not working. So Wim Edelman have you tried only adding "irqpoll" for suspend?
Comment 22 Wim Edelman 2012-09-19 17:54:31 CEST
(In reply to comment #21)
> For me adding "irqpoll" is enough to get suspend working. Because adding
> "nolapic" kills one of my CPU, so only one is using. Not optimal. But hibernate
> is still not working. So Wim Edelman have you tried only adding "irqpoll" for
> suspend?

I found that with me nolapic is also killing one of my CPU's. With only having added irqpoll, suspending to RAM does not succeed (screen becomes black but power is not going down). Suspending to disk succeeds, but in the end you also need to power down manually. But that having done awakening from suspending to disk succeeds.
Comment 23 Tolhildan Karker 2012-09-19 18:55:13 CEST
(In reply to comment #22)
> (In reply to comment #21)
> > For me adding "irqpoll" is enough to get suspend working. Because adding
> > "nolapic" kills one of my CPU, so only one is using. Not optimal. But hibernate
> > is still not working. So Wim Edelman have you tried only adding "irqpoll" for
> > suspend?
> 
> I found that with me nolapic is also killing one of my CPU's. With only having
> added irqpoll, suspending to RAM does not succeed (screen becomes black but
> power is not going down). Suspending to disk succeeds, but in the end you also
> need to power down manually. But that having done awakening from suspending to
> disk succeeds.

I understand. It is like that for me if I use nouveau driver instead of nvidia. Adding "irqpoll" suspend to ram works, but wake up gives black screen. Using nvidia driver and "irqpoll" does not give me black screen when waking up from suspend. So you can always try the blob drivers. If that gives you better luck. Suspend to disk (hibernate) still does not work for me.
Comment 24 Stew Benedict 2012-11-08 12:36:16 CET
No joy with suspend here either after upgrading to mga2. Neither nolapic or irqpoll does anything for me.

[stew@acer ~]$ uname -r
3.3.8-desktop-2.mga2
[stew@acer ~]$ lspcidrake | grep VGA
Card:Intel 810 and later: Intel Corporation|Mobile 945GME Express Integrated Graphics Controller [DISPLAY_VGA] (rev: 03)

Machine is an Acer Aspire One, which everything worked flawlessly running mga1.

CC: (none) => stewbintn

Samuel Verschelde 2013-09-06 19:09:43 CEST

CC: (none) => stormi
Source RPM: (none) => kernel

Comment 25 Manuel Hiebel 2013-10-22 12:19:23 CEST
This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad
Comment 26 Manuel Hiebel 2013-11-23 16:15:55 CET
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD


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