Bug 697150
| Summary: | pm-utils struggle with suspend/hibernate on Asus K52Jc laptop and fail without extensive help | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | |
| Component: | pm-utils | Assignee: | Jaroslav Škarvada <jskarvad> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 16 | CC: | james, jskarvad, kode54, pknirsch, richard, spacewar | |
| Target Milestone: | --- | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| URL: | http://lkml.org/lkml/2011/11/30/456 | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 798628 (view as bug list) | Environment: | ||
| Last Closed: | 2012-10-24 00:46: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: | ||
| Embargoed: | ||||
| Attachments: | ||||
|
Description
Michal Jaegermann
2011-04-16 07:47:52 UTC
Created attachment 492542 [details]
an extra "hook" file which allows to suspend
Created attachment 492544 [details]
a screen image after a crash on thaw (no SUSPEND_MODULES defined yet)
Created attachment 492545 [details]
dmesg after a "boot, hibernate, thaw" sequence with "fixes" already in place
Created attachment 492546 [details]
a layout of PCI devices as shown by 'lspci -tv'
Created attachment 492547 [details]
an output of pm-utils-bugreport-info.sh (with a working suspend/hibernate)
SELinux note:
I forgot to add but selinux in an enforcing mode (selinux-policy-targeted-3.9.7-37.fc14) appears to prevent suspend/resume at all. If set "permissive" then suspend/resume triggers multiple complaints. audit2allow from these produced the following:
module local 1.0;
require {
type var_log_t;
type consoletype_t;
type user_devpts_t;
type syslogd_t;
type NetworkManager_t;
class capability sys_module;
class file { read write ioctl };
class chr_file open;
}
#============= NetworkManager_t ==============
allow NetworkManager_t self:capability sys_module;
#============= consoletype_t ==============
allow consoletype_t var_log_t:file { read write ioctl };
#============= syslogd_t ==============
#!!!! This avc can be allowed using the boolean 'allow_daemons_use_tty'
allow syslogd_t user_devpts_t:chr_file open;
This report could be closely related, or even a duplicate, of a bug 675564 for Asus K52F laptop. Thanks, closing as dupe of 694191. I prefer this to be fixed in kernel. I will give it deeper look later. *** This bug has been marked as a duplicate of bug 694191 *** Reopening, the thaw issue seems different to 694191 and I guess it is related to sdhci. I will track the sdhci thaw issue here and the ehci unbind issue in 694191. I think that the backtrace from comment 0 is there because the sdhci-pci is unable to handle the IRQ 17, because the sdhci-pci module was unloaded earlier. (In reply to comment #9) > I think that the backtrace from comment 0 is there because the sdhci-pci is > unable to handle the IRQ 17, because the sdhci-pci module was unloaded earlier. Maybe. Although IRQ 17 looks like serving a wireless interface and you can find in a backtrace from comment 0: [ 236.090158] handlers: [ 236.092139] [<ffffffffa0227da5>] (ath_isr+0x0/0x17e [ath9k]) sdhci-pci, OTOH, seems to be associated with +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller and with +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller '/proc/interrupts' look like this: CPU0 CPU1 0: 178 18 IO-APIC-edge timer 1: 258 15 IO-APIC-edge i8042 8: 0 1 IO-APIC-edge rtc0 9: 8732 1107 IO-APIC-fasteoi acpi 12: 340 70 IO-APIC-edge i8042 16: 336 44 IO-APIC-fasteoi ehci_hcd:usb1 17: 299990 12 IO-APIC-fasteoi ath9k 18: 0 0 IO-APIC-fasteoi jmb38x_ms:slot0, mmc0 23: 3194 25240 IO-APIC-fasteoi ehci_hcd:usb2 41: 0 0 PCI-MSI-edge pciehp 42: 0 0 PCI-MSI-edge pciehp 43: 0 0 PCI-MSI-edge pciehp 44: 113235 3053 PCI-MSI-edge ahci 45: 27030 4057 PCI-MSI-edge i915@pci:0000:00:02.0 46: 0 0 PCI-MSI-edge hda_intel 47: 12218 13146 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 2540931 3509573 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES: 294022 282270 Rescheduling interrupts CAL: 3818 2372 Function call interrupts TLB: 25872 15243 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 52 50 Machine check polls ERR: 9 MIS: 0 Just to keep references in one place. Complaints about IRQ 17 may look like in comment 0 or like the following: [ 7224.510578] irq 17: nobody cared (try booting with the "irqpoll" option) [ 7224.510586] Pid: 0, comm: swapper Tainted: G W 2.6.35.12-88.fc14.x86_64 #1 [ 7224.510590] Call Trace: [ 7224.510594] <IRQ> [<ffffffff81010207>] ? paravirt_read_tsc+0x9/0xd [ 7224.510614] [<ffffffff810a74d7>] __report_bad_irq.clone.1+0x3d/0x8b [ 7224.510617] [<ffffffff810a763f>] note_interrupt+0x11a/0x17f [ 7224.510620] [<ffffffff810a811f>] handle_fasteoi_irq+0xa8/0xce [ 7224.510624] [<ffffffff8100c2ea>] handle_irq+0x88/0x90 [ 7224.510629] [<ffffffff81470b44>] do_IRQ+0x5c/0xb4 [ 7224.510634] [<ffffffff8146b093>] ret_from_intr+0x0/0x11 [ 7224.510635] <EOI> [<ffffffff81265570>] ? intel_idle+0x111/0x139 [ 7224.510643] [<ffffffff8126554f>] ? intel_idle+0xf0/0x139 [ 7224.510648] [<ffffffff81394cf1>] cpuidle_idle_call+0x8b/0xe9 [ 7224.510653] [<ffffffff81008325>] cpu_idle+0xaa/0xcc [ 7224.510660] [<ffffffff814527e6>] rest_init+0x8a/0x8c [ 7224.510665] [<ffffffff81ba1c49>] start_kernel+0x40b/0x416 [ 7224.510669] [<ffffffff81ba12c6>] x86_64_start_reservations+0xb1/0xb5 [ 7224.510672] [<ffffffff81ba13c2>] x86_64_start_kernel+0xf8/0x107 [ 7224.510674] handlers: [ 7224.510675] [<ffffffffa0227da5>] (ath_isr+0x0/0x17e [ath9k]) [ 7224.510689] Disabling IRQ #17 That seem to depend on a phase of a moon (or maybe on winning or loosing some race). Be as it may but with additions in /etc/pm/ K52J at least behaves. Apologies for trickling information like that but devices tied up to sdhci seem to be here these: +-1c.5-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller | +-00.2 JMicron Technology Corp. Standard SD Host Controller | +-00.3 JMicron Technology Corp. MS Host Controller | +-00.4 JMicron Technology Corp. xD Host Controller | \-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller Although ehthernet controller is really using 'jme' for a driver. At least an SD card reader works after suspend/resumes (hibernate/thaw) cycles. Presumably other too but I do not have on hands suitable media to check. See also http://lkml.org/lkml/2011/11/30/456 and other messages in that thread. Basically the same issue with 3.x kernels so this will no go away with an upgrade. With an upgrade to Fedora 16 and with 3.1.2-1.fc16.x86_64 the situation actually got worse. I had to add "ath ath9k" to my SUSPEND_MODULES. Otherwise my wireless connection would be lost after every resume from suspend and thaw after hibernate would silently fail - somewhere. Also I would consistently see when suspending/hibernating this machine: irq 17: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 3.1.2-1.fc16.x86_64 #1 Call Trace: <IRQ> [<ffffffff810b2222>] __report_bad_irq+0x38/0xc3 [<ffffffff810b24bc>] note_interrupt+0x176/0x1fa [<ffffffff810b0a0f>] handle_irq_event_percpu+0x15d/0x1a5 [<ffffffff810b0a92>] handle_irq_event+0x3b/0x59 [<ffffffff81078268>] ? sched_clock_cpu+0x42/0xc6 [<ffffffff810b2c7c>] handle_fasteoi_irq+0x80/0xa4 [<ffffffff81010af9>] handle_irq+0x88/0x8e [<ffffffff814c040d>] do_IRQ+0x4d/0xa5 [<ffffffff814b756e>] common_interrupt+0x6e/0x6e <EOI> [<ffffffff814b71ac>] ? _raw_spin_unlock_irqrestore+0x17/0x19 [<ffffffff813a5cc3>] ? poll_idle+0x28/0x65 [<ffffffff813a5cb6>] ? poll_idle+0x1b/0x65 [<ffffffff813a5fe6>] cpuidle_idle_call+0xe8/0x182 [<ffffffff8100e2e3>] cpu_idle+0xa4/0xe8 [<ffffffff81494a8e>] rest_init+0x72/0x74 [<ffffffff81b76b7d>] start_kernel+0x3ab/0x3b6 [<ffffffff81b762c4>] x86_64_start_reservations+0xaf/0xb3 [<ffffffff81b76140>] ? early_idt_handlers+0x140/0x140 [<ffffffff81b763ca>] x86_64_start_kernel+0x102/0x111 handlers: [<ffffffffa02c0d80>] ath_isr Disabling IRQ #17 BTW - I tried what would happen with a "barebones" echo mem > /sys/power/state while running 3.1.7-1.fc16.x86_64 on my Asus K52Jc. Nothing too exciting. My machine froze immediately with a blank screen and without even seriously trying to suspend. The first reboot after a powerdown failed with ATA errors. After the second powerdown the laptop booted normally so a battery removal was not required. With pm-utils "doctored" as per earlier comments both suspend and hibernation work just fine "IRQ #17" complaints notwithstanding. I can verify this also applies to the ASUS U52F-BBL5, although the SUSPEND_MODULES setting does not appear to be necessary to thaw from hibernate, at least not without any SD memory card inserted. The 802.11n, which uses the iwlwifi module, also appears to resume from suspend and hibernate without any changes, at least most of the time. I spoke too soon, my system decided to oops in the middle of installing gcc and gcc-g++, and I wasn't able to capture a picture of the messages, as they scrolled by too quickly. It looked like some file system corruption issue, possibly related to the failed hibernate/suspend cycles I tried before installing that workaround script. Kernel 3.6.2-1.fc16 allows me to suspend and hibernate K52Jc in an "out-of-the-box" configuration. Please see bug 798628#c12 for details. If ASUS U52F-BBL5 still locks up please follow up in bug 798628. |