Bug 55911 - PCMCIA and Firewire PCI config broken after suspend-to-RAM
PCMCIA and Firewire PCI config broken after suspend-to-RAM
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: PCI
All Linux
: P1 normal
Assigned To: drivers_pci@kernel-bugs.osdl.org
:
Depends on:
Blocks: 56331
  Show dependency treegraph
 
Reported: 2013-03-29 07:01 UTC by Martin Demlon
Modified: 2013-05-06 21:10 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.8.3
Tree: Mainline
Regression: Yes


Attachments
dmesg through suspend/resume (3.50 KB, text/plain)
2013-03-29 09:13 UTC, Martin Demlon
Details
acpidump (after an s2ram) (122.28 KB, text/plain)
2013-03-29 09:14 UTC, Martin Demlon
Details

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.

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