Bug 55911

Summary: PCMCIA and Firewire PCI config broken after suspend-to-RAM
Product: Drivers Reporter: Martin Demlon (report)
Component: PCIAssignee: 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)

Description Martin Demlon 2013-03-29 07:01:11 UTC
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.
Comment 1 Lan Tianyu 2013-03-29 07:53:43 UTC
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.
Comment 2 Martin Demlon 2013-03-29 09:12:38 UTC
(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
Comment 3 Martin Demlon 2013-03-29 09:13:32 UTC
Created attachment 96551 [details]
dmesg through suspend/resume
Comment 4 Martin Demlon 2013-03-29 09:14:27 UTC
Created attachment 96561 [details]
acpidump (after an s2ram)
Comment 5 Lan Tianyu 2013-04-04 13:49:04 UTC
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
Comment 6 Martin Demlon 2013-05-06 21:10:16 UTC
This problem is fixed in kernel 3.9.  Thanks to whoever did it.