Bug 55911
| Summary: | PCMCIA and Firewire PCI config broken after suspend-to-RAM | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Martin Demlon (report) |
| Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rjw, tianyu.lan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.8.3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
| Attachments: |
dmesg through suspend/resume
acpidump (after an s2ram) |
||
This seems a pci device's bug.. After s2ram, the system is ok except for these device's?
Please attach the output of dmesg after s2ram and acpidump.
Hi Rafael:
Could you have a look? This bug is pci device related.
(In reply to comment #1) > This seems a pci device's bug.. After s2ram, the system is ok except for > these > device's? Yes, I noticed no other misbehaviour in several hours of post-s2 use with this kernel. > Please attach the output of dmesg after s2ram and acpidump. See dmesg.txt (from the start of suspend until the end for resume) and acpidump-posts2.txt; the "posts2" is supposed to mean that I (perhaps foolishly) took this dump only after the machine had been suspended. Thanks, Martin Created attachment 96551 [details]
dmesg through suspend/resume
Created attachment 96561 [details]
acpidump (after an s2ram)
From the log, I find pci 0000:01:03 and 0000:01:03.1 still stay at D3 after being resumed. So reassign this bug to pci component. pci 0000:00:1f.0: power state changed by ACPI to D0 yenta_cardbus 0000:01:03.0: Refused to change power state, currently in D3 pci 0000:01:03.1: Refused to change power state, currently in D3 This problem is fixed in kernel 3.9. Thanks to whoever did it. |
This is on a JVC MP-XP731 machine, a vintage 2004 (or so) Centrino-based system with video memory mapped in main memory. The last kernel version I've tried that worked fine is 3.2.36. The first kernel version I've tried that broke this is 3.4.24, it's still broken on 3.8.3. The primary symptom: After a suspend-to-memory, PC Card inserts are no longer detected. Looking a bit closer, it turns out that suspend/resume hoses two PCI descriptors: Before suspend, lspci -v outputs: 01:03.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev b8) Subsystem: ASUSTeK Computer Inc. Device 1804 Flags: bus master, medium devsel, latency 168, IRQ 7 Memory at 30000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 34000000-37fff000 (prefetchable) Memory window 1: 38000000-3bfff000 I/O window 0: 0000c000-0000c0ff I/O window 1: 0000c400-0000c4ff 16-bit legacy interface ports at 0001 Kernel driver in use: yenta_cardbus 01:03.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C551 IEEE 1394 Controller (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 1807 Flags: bus master, medium devsel, latency 64, IRQ 7 Memory at fe8ff000 (32-bit, non-prefetchable) [size=2K] Capabilities: <access denied> After resume, this becomes: 01:03.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: yenta_cardbus 01:03.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C551 IEEE 1394 Controller (rev ff) (prog-if ff) !!! Unknown header type 7f All other descriptors remain ok. Probably a consequence of this are messages pcmcia_socket pcmcia_socket0: *** DANGER *** unable to remove socket power that occur during resume. Looking for the BIOS memory map, in the early kernel messages I discovered PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug Suspecting a resource clash anyway, I tried this. The system is now running with $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro noapic pci=use_crs This did not change the behaviour. Realizing I have no actual idea how to further debug this, I'm trying this report.