Created attachment 39902 [details] lspci -vv Hello, My PCMCIA card works fine, but when I resume my laptop from suspend (with card ejected) and then try to insert the card, it is not found by the kernel. I tried to play with pccardctl eject and insert and I get a kernel trace code attached bellow: WARNING: at drivers/mtd/nand/r852.c:776 r852_irq+0x268/0x2e0 [r852]() Hardware name: 7443C1G Modules linked in: yenta_socket i2c_i801 sdhci_pci sdhci fuse cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 nf_conntrack_netbios_ns ext2 uinput snd_hda_codec_conexant snd_hda_intel usb_storage snd_hda_codec arc4 ecb snd_hwdep snd_seq snd_seq_device iwlagn snd_pcm iwlcore mac80211 r852 sm_common nand thinkpad_acpi nand_ids nand_ecc cfg80211 snd_timer mtd snd xhci_hcd e1000e soundcore snd_page_alloc rfkill pcspkr joydev ext4 mbcache jbd2 cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt firewire_ohci mmc_core firewire_core crc_itu_t [last unloaded: yenta_socket] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.36-zen2 #11 Call Trace: <IRQ> [<ffffffff8103dd8f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff8103ddea>] warn_slowpath_null+0x1a/0x20 [<ffffffffa02b4ea8>] r852_irq+0x268/0x2e0 [r852] [<ffffffff810a5ea9>] handle_IRQ_event+0x79/0x1d0 [<ffffffff81064edb>] ? sched_clock_tick+0x5b/0x90 [<ffffffff810a8661>] handle_fasteoi_irq+0x81/0x100 [<ffffffff810058f2>] handle_irq+0x22/0x40 [<ffffffff814fcc3c>] do_IRQ+0x6c/0xf0 [<ffffffff814f62d3>] ret_from_intr+0x0/0xa <EOI> [<ffffffff812aee70>] ? acpi_idle_enter_bm+0x21c/0x250 [<ffffffff812aee6b>] ? acpi_idle_enter_bm+0x217/0x250 [<ffffffff813f7612>] cpuidle_idle_call+0x92/0x140 [<ffffffff810012bc>] cpu_idle+0xac/0x160 [<ffffffff814eefba>] start_secondary+0x1ed/0x1f4 My lspci -vv is added as attachment.
What's the output of "lspcmcia -vvv" before suspend, with the card inserted?
(In reply to comment #1) > What's the output of "lspcmcia -vvv" before suspend, with the card inserted? $ lspcmcia -vvv Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:15:00.0) Configuration: state: on ready: unknown --none-- --none-- This is strange, because the card is inserted and running well. Pccardctl shows no card. $ pccardctl status Socket 0: no card I can still propertly eject and insert the card and it will work ok. It will fail just after the resume from suspend. Here is the lspci -vvv output for the card itself: 05:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30) Subsystem: NEC Corporation uPD720200 USB 3.0 Host Controller Physical Slot: 3 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: xhci_hcd Kernel modules: xhci-hcd
Then it seems to be a cardbus 32-bit card, and not a PCMCIA 16-bit card. Could you try to enable dynamic debug in the kernel configuration, and then setting $ echo "module pcmcia_core +p" > /sys/kernel/debug/dynamic_debug/control and capture the "dmesg" output if you insert a card (a) before the 1st suspend, (b) after the suspend/resume cycle? Oh, and why is your kernel tainted?
(In reply to comment #3) > Then it seems to be a cardbus 32-bit card, and not a PCMCIA 16-bit card. > Could > you try to enable dynamic debug in the kernel configuration, and then setting > > $ echo "module pcmcia_core +p" > /sys/kernel/debug/dynamic_debug/control > > and capture the "dmesg" output if you insert a card (a) before the 1st > suspend, > (b) after the suspend/resume cycle? > > Oh, and why is your kernel tainted? Ah seems you are right and I use cardbus 32-bit card and not a 16-bit PCMCIA one. If so, this probably isn't right section for this bug, so please move it to the right one. Well, I don't know exactly what tainted kernel means :-/ But I think it isn't anything good :-) I use latest stable zen-kernel. I will try the dynamic debug then.
Ok I have compiled my kernel with dynamic_debug and pcmcia as module. When I boot my system without card inserted, in won't find it anymore - same behavior like after resume. The debug for pcmcia_core gives me only this when I try to pccardctl insert: pcmcia_socket pcmcia_socket0: parse_uevents: events 00000002 pcmcia_socket pcmcia_socket0: insert pcmcia_socket pcmcia_socket0: setup pcmcia_socket pcmcia_socket0: shutdown Output from yenta_socket, same command (really can't understand this Matrix code): yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 001e 00 yenta_cardbus 0000:15:00.0: 0016 00 yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 000c 00004000 yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 0010 00000400 yenta_cardbus 0000:15:00.0: 0010 00000000 yenta_cardbus 0000:15:00.0: 003e 0580 yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 0003 40 yenta_cardbus 0000:15:00.0: 0003 40 yenta_cardbus 0000:15:00.0: 0002 40 yenta_cardbus 0000:15:00.0: 0002 40 yenta_cardbus 0000:15:00.0: 0005 08 yenta_cardbus 0000:15:00.0: 0005 08 yenta_cardbus 0000:15:00.0: 0004 00 yenta_cardbus 0000:15:00.0: 003e 0580 yenta_cardbus 0000:15:00.0: 0000 ffffffff yenta_cardbus 0000:15:00.0: 0004 00000006 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0008 0000 yenta_cardbus 0000:15:00.0: 000a 0001 yenta_cardbus 0000:15:00.0: 0007 00 yenta_cardbus 0000:15:00.0: 0007 00 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 000c 0000 yenta_cardbus 0000:15:00.0: 000e 0001 yenta_cardbus 0000:15:00.0: 0007 00 yenta_cardbus 0000:15:00.0: 0007 00 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0040 00 yenta_cardbus 0000:15:00.0: 0010 0000 yenta_cardbus 0000:15:00.0: 0012 0000 yenta_cardbus 0000:15:00.0: 0014 0000 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0041 00 yenta_cardbus 0000:15:00.0: 0018 0000 yenta_cardbus 0000:15:00.0: 001a 0000 yenta_cardbus 0000:15:00.0: 001c 0000 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0042 00 yenta_cardbus 0000:15:00.0: 0020 0000 yenta_cardbus 0000:15:00.0: 0022 0000 yenta_cardbus 0000:15:00.0: 0024 0000 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0043 00 yenta_cardbus 0000:15:00.0: 0028 0000 yenta_cardbus 0000:15:00.0: 002a 0000 yenta_cardbus 0000:15:00.0: 002c 0000 yenta_cardbus 0000:15:00.0: 0006 00 yenta_cardbus 0000:15:00.0: 0044 00 yenta_cardbus 0000:15:00.0: 0030 0000 yenta_cardbus 0000:15:00.0: 0032 0000 yenta_cardbus 0000:15:00.0: 0034 0000 yenta_cardbus 0000:15:00.0: 0004 00000006 yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 0010 00000400 yenta_cardbus 0000:15:00.0: 0010 00000000 yenta_cardbus 0000:15:00.0: 003e 0580 yenta_cardbus 0000:15:00.0: 0008 30000006 yenta_cardbus 0000:15:00.0: 0003 40 yenta_cardbus 0000:15:00.0: 0003 40 yenta_cardbus 0000:15:00.0: 0002 40 yenta_cardbus 0000:15:00.0: 0002 40 yenta_cardbus 0000:15:00.0: 0005 08 yenta_cardbus 0000:15:00.0: 0005 08 yenta_cardbus 0000:15:00.0: 0004 00 yenta_cardbus 0000:15:00.0: 003e 0580 yenta_cardbus 0000:15:00.0: 0000 ffffffff yenta_cardbus 0000:15:00.0: 0004 00000006 yenta_cardbus 0000:15:00.0: 0008 30000006 And nothing more :-/ Card doesn't work when I don't boot up with it inserted.
On my system, it usually takes an insert, remove, insert sequence before the card works. From bootup, it always works. It sounds as if your system is the same.
I've finally found the solution. The problem is in pciehp module, which get confused with the suspend. Unloading the module and loading it again will solve the problem - it will find the card then. Playing with pccardctl won't make any effect.
Filip, Larry, can you check whether this is still a problem with a recent, e.g., 3.5, kernel? If it is, can you do a cold boot, suspend, resume, insert card sequence and attach the complete dmesg log to this bug?
Ping, can we make any progress on this, e.g., by collecting the info requested in comment #8?
We merged a change in this area: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=87683e22c646e563061a91f4a0106e6913acebf8 Can anyone who saw this problem test a kernel that includes that change, e.g., current Linus kernel or v3.7-rc1 when it comes out in a week or so? Unfortunately the changelog doesn't mention any bug reports, but it seems like it could be related to this one.
I'm closing this for lack of testing information. If somebody can still reproduce the problem on a recent (v3.11) kernel, please reopen this bug and attach complete dmesg and "lspci -vv" logs.