Bug 760882

Summary: kernel 3.2 suspend-resume problem
Product: [Fedora] Fedora Reporter: Jacek Pawlyta <cunio>
Component: kernelAssignee: Matthew Garrett <mjg59>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda, szoke.karcsi
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 17:49:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
output of lspci
none
output of dmesg none

Description Jacek Pawlyta 2011-12-07 09:28:44 UTC
Description of problem:

[ 1492.283624] PM: resume of devices complete after 10722.202 msecs
[ 1492.286339] PM: resume devices took 10.725 seconds
[ 1492.286342] ------------[ cut here ]------------
[ 1492.286350] WARNING: at kernel/power/suspend_test.c:53 suspend_test_finish+0x86/0x90()
[ 1492.286352] Hardware name: 20023               
[ 1492.286354] Component: resume devices, time: 10725
[ 1492.286356] Modules linked in: ppdev parport_pc lp parport fuse hidp lockd tpm_infineon rfcomm bnep nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_state nf_conntrack ip6_tables coretemp snd_hda_codec_conexant snd_hda_intel snd_hda_codec uvcvideo btusb snd_hwdep bluetooth videodev media v4l2_compat_ioctl32 arc4 snd_seq b43(O) mac80211(O) snd_seq_device cfg80211(O) bcma(O) snd_pcm snd_timer snd microcode ssb(O) mmc_core ideapad_laptop sparse_keymap i2c_i801 iTCO_wdt iTCO_vendor_support tg3 soundcore snd_page_alloc rfkill uinput sunrpc binfmt_misc i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
[ 1492.286408] Pid: 4039, comm: pm-suspend Tainted: G           O 3.2.0-0.rc4.git4.2.fc17.x86_64 #1
[ 1492.286410] Call Trace:
[ 1492.286416]  [<ffffffff8107cecf>] warn_slowpath_common+0x7f/0xc0
[ 1492.286419]  [<ffffffff8107cfc6>] warn_slowpath_fmt+0x46/0x50
[ 1492.286422]  [<ffffffff810d1636>] suspend_test_finish+0x86/0x90
[ 1492.286426]  [<ffffffff810d105e>] suspend_devices_and_enter+0x15e/0x4a0
[ 1492.286429]  [<ffffffff810d1507>] enter_state+0x167/0x190
[ 1492.286432]  [<ffffffff810cfc57>] state_store+0xb7/0x130
[ 1492.286437]  [<ffffffff81305e4f>] kobj_attr_store+0xf/0x30
[ 1492.286440]  [<ffffffff8122749c>] sysfs_write_file+0xec/0x170
[ 1492.286446]  [<ffffffff811ac926>] vfs_write+0xb6/0x180
[ 1492.286450]  [<ffffffff811acc4d>] sys_write+0x4d/0x90
[ 1492.286454]  [<ffffffff81682082>] system_call_fastpath+0x16/0x1b
[ 1492.286456] ---[ end trace 7ce48a95837451b9 ]---


Version-Release number of selected component (if applicable):
kenrel  3.2.0-0.rc4.git4.2.fc17.x86_64

How reproducible:
Always

Steps to Reproduce:
1. suspend to RAM
2. resume

Comment 1 Dave Jones 2011-12-07 16:37:28 UTC
This trace comes from this..

        /* Warning on suspend means the RTC alarm period needs to be
         * larger -- the system was sooo slooowwww to suspend that the
         * alarm (should have) fired before the system went to sleep!
         *
         * Warning on either suspend or resume also means the system
         * has some performance issues.  The stack dump of a WARN_ON
         * is more likely to get the right attention than a printk...
         */
        WARN(msec > (TEST_SUSPEND_SECONDS * 1000),
             "Component: %s, time: %u\n", label, msec);

did this only just start happening with rc4-git4 ?
I enabled a debug option that really hurts performance, which could explain this. I'll be turning it off again for tomorrows build.

Comment 2 Jacek Pawlyta 2011-12-07 21:21:19 UTC
The same problem was with kernel-3.2.0-0.rc4.git2.1.fc17.x86_64

Comment 3 Jacek Pawlyta 2011-12-08 12:22:08 UTC
kernel 3.2.0-0.rc4.git5.1.fc17.x86_64 - the same problem

Comment 4 Jacek Pawlyta 2011-12-11 18:05:47 UTC
[ 1909.639099] usb 8-1: reset full-speed USB device number 2 using uhci_hcd
[ 1909.777562] btusb 8-1:1.0: no reset_resume for driver btusb?
[ 1909.777565] btusb 8-1:1.1: no reset_resume for driver btusb?

What I found is that blutooth-usb dongle didn't go to sleep together with the laptop, bt activity diode blinks all the time regardless the fact that laptop is suspended (??)

Comment 5 Jacek Pawlyta 2011-12-13 23:19:39 UTC
kernel 3.2.0-0.rc5.git1.1.fc17.x86_64 
the problem is still here

Comment 6 Jacek Pawlyta 2011-12-18 11:45:07 UTC
kernel 3.2.0-0.rc6.git0.1.fc17.x86_64 - the same problem

Comment 7 Fedora End Of Life 2013-04-03 16:21:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 8 Justin M. Forbes 2013-04-05 18:39:14 UTC
Is this still an issue with the 3.9 kernels in F19?

Comment 9 Szőke Károly 2013-04-06 20:02:51 UTC
Created attachment 732195 [details]
output of lspci

It was last working with kernel 3.1.10, from 3.2 doesn't work.

Comment 10 Szőke Károly 2013-04-06 20:06:39 UTC
Created attachment 732196 [details]
output of dmesg

My laptop is MSI VR610X with ATI RADEON X1200 video card.

Comment 11 Justin M. Forbes 2013-04-08 14:40:32 UTC
And you have tested with 3.9?

Comment 12 Szőke Károly 2013-04-08 17:04:51 UTC
How can i test?

Comment 13 Justin M. Forbes 2013-04-08 17:20:57 UTC
you can test with Fedora 19, or you can install the kernel from  rawhide nodebug.  http://lists.fedoraproject.org/pipermail/devel/2012-November/173756.html 
What was the last version you tested with? 3.1 is very old

Comment 14 Jacek Pawlyta 2013-04-08 17:34:38 UTC
I have tested kernel 3.8.6 on f18 and hibernation/resume works OK

Comment 15 Szőke Károly 2013-04-09 06:58:33 UTC
(In reply to comment #13)
> you can test with Fedora 19, or you can install the kernel from  rawhide
> nodebug. 
> http://lists.fedoraproject.org/pipermail/devel/2012-November/173756.html 
> What was the last version you tested with? 3.1 is very old

My current kernel version:
3.8.5-201.fc18.x86_64
I test all new kernel, when it comes, and this doesn't work since 3.1. Yes, 3.1 is very old, and since i don't suspend and hibernate my laptop, because it doesn't stand up (blank screen), There are several bug reports about this problem:
https://bugzilla.redhat.com/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&content=suspend%20resume%20blank%20screen&list_id=1260967

I think, my old ATI X1200 video card doesn't support suspend-resume feature. What things were changed when kernel gone up from 3.1 to 3.2?

Comment 16 Szőke Károly 2013-04-09 08:09:58 UTC
(In reply to comment #14)
> I have tested kernel 3.8.6 on f18 and hibernation/resume works OK

I have tested with kernel 3.9.0, and it doesn't work.