Hide Forgot
After the system is booted SD card reader works as expected. I can insert and remove card as many times as I want to. But after some time of not using the SD slot, a card will not be mounted when inserted. Once I thought it has something to do with suspend, because it always happened after wake-up. But I discovered, it's rather a matter of time between first and subsequent use, as suspend is not needed to reproduce the situation. After reboot card reader is working fine, but after random time everything repeats. Version-Release number of selected component (if applicable): kernel-3.1.0-7.fc16.x86_64 How reproducible: sooner or later, but always Steps to Reproduce: 1. Insert an SD card Actual results: Nothing happens. Expected results: SD card should be mounted and available to use. Additional info: $ lspci -vvk 14:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: sdhci-pci Kernel modules: sdhci-pci dmesg after modprobe sdhci-pci [41565.430935] sdhci: Secure Digital Host Controller Interface driver [41565.430938] sdhci: Copyright(c) Pierre Ossman [41565.432099] sdhci-pci 0000:14:00.0: SDHCI controller found [1180:e822] (rev 1) [41565.432105] sdhci-pci 0000:14:00.0: Invalid first BAR. Aborting. After wake-up there are tens of following sequences of messages in dmesg: [36301.441518] mmc0: Controller never released inhibit bit(s). [36301.441524] sdhci: =========== REGISTER DUMP (mmc0)=========== [36301.441530] sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff [36301.441534] sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff [36301.441539] sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff [36301.441544] sdhci: Present: 0xffffffff | Host ctl: 0x000000ff [36301.441549] sdhci: Power: 0x000000ff | Blk gap: 0x000000ff [36301.441559] sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff [36301.441563] sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff [36301.441568] sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff [36301.441573] sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff [36301.441578] sdhci: Caps: 0xffffffff | Caps_1: 0xffffffff [36301.441583] sdhci: Cmd: 0x0000ffff | Max curr: 0xffffffff [36301.441586] sdhci: Host ctl2: 0x0000ffff [36301.441588] sdhci: =========================================== [36301.541561] mmc0: Reset 0x2 never completed. [36301.541565] sdhci: =========== REGISTER DUMP (mmc0)=========== [36301.541570] sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff [36301.541573] sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff [36301.541577] sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff [36301.541581] sdhci: Present: 0xffffffff | Host ctl: 0x000000ff [36301.541584] sdhci: Power: 0x000000ff | Blk gap: 0x000000ff [36301.541588] sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff [36301.541592] sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff [36301.541595] sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff [36301.541598] sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff [36301.541601] sdhci: Caps: 0xffffffff | Caps_1: 0xffffffff [36301.541605] sdhci: Cmd: 0x0000ffff | Max curr: 0xffffffff [36301.541607] sdhci: Host ctl2: 0x0000ffff [36301.541609] sdhci: =========================================== [36301.641557] mmc0: Reset 0x4 never completed. [36301.641562] sdhci: =========== REGISTER DUMP (mmc0)=========== [36301.641566] sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff [36301.641571] sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff [36301.641574] sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff [36301.641578] sdhci: Present: 0xffffffff | Host ctl: 0x000000ff [36301.641582] sdhci: Power: 0x000000ff | Blk gap: 0x000000ff [36301.641586] sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff [36301.641590] sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff [36301.641593] sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff [36301.641597] sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff [36301.641601] sdhci: Caps: 0xffffffff | Caps_1: 0xffffffff [36301.641606] sdhci: Cmd: 0x0000ffff | Max curr: 0xffffffff [36301.641608] sdhci: Host ctl2: 0x0000ffff [36301.641610] sdhci: =========================================== [36301.741802] mmc0: Reset 0x1 never completed. [36301.741806] sdhci: =========== REGISTER DUMP (mmc0)=========== [36301.741810] sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff [36301.741814] sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff [36301.741817] sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff [36301.741821] sdhci: Present: 0xffffffff | Host ctl: 0x000000ff [36301.741825] sdhci: Power: 0x000000ff | Blk gap: 0x000000ff [36301.741828] sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff [36301.741832] sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff [36301.741836] sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff [36301.741840] sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff [36301.741843] sdhci: Caps: 0xffffffff | Caps_1: 0xffffffff [36301.741847] sdhci: Cmd: 0x0000ffff | Max curr: 0xffffffff [36301.741849] sdhci: Host ctl2: 0x0000ffff [36301.741850] sdhci: ===========================================
Do you still have this issue with the 3.2.7 or newer kernels?
I'm currently running 3.2.7-1.fc16.x86_64 and the problem still persists.
(In reply to comment #2) > I'm currently running 3.2.7-1.fc16.x86_64 and the problem still persists. Could you try booting that kernel with "pcie_aspm=off" on the kernel command line? It seems as if there is some kind of odd pci interaction going on here.
The problem haven't occurred for about 24 hours now, so I'd say booting with "pcie_aspm=off" helped. I'll test it for next few days and keep the bug updated if anything happens. Everything indicates that this is indeed related to ASPM handling, and if it is a but, will it be fixed? It would be better to have ASPM enabled on laptop.
(In reply to comment #4) > The problem haven't occurred for about 24 hours now, so I'd say booting with > "pcie_aspm=off" helped. Interesting. Thank you. > I'll test it for next few days and keep the bug updated if anything happens. > > Everything indicates that this is indeed related to ASPM handling, and if it is > a but, will it be fixed? It would be better to have ASPM enabled on laptop. There is some work going on upstream to handle ASPM a bit better, yes. I'm not sure when exactly it will land though. Could you attach the dmesg output from a boot with and without pcie_aspm=off?
Also, please attach the output of (as root) lspci -vvv for three cases: stock kernel pcie_aspm=off pcie_aspm,policy=default
Created attachment 567252 [details] dmesg output without pcie_aspm option
Created attachment 567254 [details] dmesg output with pcie_aspm=off option
Created attachment 567255 [details] lspci -vvv output without pcie_aspm option
Created attachment 567256 [details] lspci -vvv output with pcie_aspm=off option
(In reply to comment #6) > Also, please attach the output of (as root) > > lspci -vvv > > for three cases: > > stock kernel > pcie_aspm=off > pcie_aspm,policy=default I couldn't boot with the last option (pcie_aspm,policy=default). After a second or two of booting process, kernel caught signal and debug console showed (dracut).
Ok, it's almost 10 days of uptime and several dozen of suspend/wake cycles and the problem haven't occurred. It's rather obvious that ASPM is broken in 3.2.7-1.fc16.x86_64 and older and pcie_aspm=off helps.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
It's not any better. Booting 3.3.0-8.fc16.x86_64 without pcie_aspm=off makes the problem to occur.
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
I've been running 3.6.3-1.fc17.x86_64 without "pcie_aspm=off" for more than a week now and the problem didn't occur.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.