Created attachment 72808 [details] dmesg output without workaround Inserting a sd card into the internal card reader is not recognized by the system. Same problem occurs with older ubuntu versions (driver missing?). Upstream kernel tests done with kernels: - Daily built 3.3.0-999 from 30 March 2012 and - Kernel 3.4.0-999-generic_3.4.0-999.201204030410 Upstream kernel tests showed no improvement. However there is a workaround that might lead to a solution of this problem. Workaround a) Booting the system with the SD card in the SD card reader will lead to a mounted device Workaround b) Insert the SD card Enter as root: echo 1 > /sys/bus/pci/rescan This will lead to a mounted device (SD card) I have attached dmesg and lspci as text files without the workaround. Plus: Find attached dmesg and lspci after the workarount is in place (e. g. dmesg_wa.txt)
Created attachment 72809 [details] dmesg output with workaround in place
Created attachment 72810 [details] lspci output without workaround
Created attachment 72811 [details] lspci output with workaround in place
Possible duplicate filed https://bugzilla.kernel.org/show_bug.cgi?id=44021 as per conversation here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/995743
Hello! I have the similar bug on kernel 2.6.33 (it is the last we support now). Flash card is visible only if it was inserted into internal flash card reader before boot. I found out that we can make flash card visible again. We should guess letter and mount it: "mount /dev/sdb1 /mnt". After that "fdisk -l" finds flash card. Also we can make flash card visible again by making "cat /dev/sdb1". But this works not always from the first time. May be this information will be helpful to resolve this bug.
Reassigning to PCI because this looks like a pciehp/acpiphp issue.
v3.12-rc1 contains many acpiphp updates, as well as fixes to the code that decides whether to use acpiphp or pciehp. Can you please retest with v3.12-rc1 or later, attach the complete dmesg log, and note whether this issue is resolved?
I would be happy to do a retest for you. But I do not understand what exactly you mean by v3.12-rc1. Could you please explain?
Thomas Born, information here on how to install custom kernels [1], and v3.12-rc1 is here [2]. [1] https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelMainlineBuilds [2] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc1-saucy/
Sparhawk, I have tested the kernel v3.12-rc1 with the following results: - good: SD card is mounted when inserting - bad: after unmounting the SD card, it is not recognized when inserted for a second time At least there is an improvement. We only have to sort out while this is only working one time in a session. Good luck! Thomas
Thomas, can you attach the complete dmesg log showing both the good and bad results?
Created attachment 110281 [details] dmesg "good" output of dmesg with identified and mounted SD card = "good"
Created attachment 110291 [details] dmesg "bad" output of dmesg after unmounting the SD card and inserting it again = "bad" - no recognition
Hi Thomas, thanks for the logs. The original report was that "inserting a sd card into the internal card reader is not recognized by the system." In attachment 72808 [details] (original dmesg without "rescan" workaround), there is no mention of sdhci or any devices on PCI bus 0000:07. If I understand correctly, the logs in comment #12 and comment #13 are from a single boot. The "good" log shows shows a hot-add of 0000:07:00.0 (as well as functions 2, 3, and 4), and successful detection of a new card by sdhci: [ 232.325280] pci 0000:07:00.0: [197b:2392] type 00 class 0x088000 [ 232.325310] pci 0000:07:00.0: reg 0x10: [mem 0x00000000-0x000000ff] [ 232.408372] sdhci-pci 0000:07:00.0: SDHCI controller found [197b:2392] [ 232.888783] mmc0: new SD card at address 75bf I assume the "bad" log was collected after a removal and reinsertion. I see the removal here: [ 303.613181] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 306.179935] mmc0: card 75bf removed There's no PCI hot-remove event, and there's no re-insertion event from sdhci. I don't know what the expected behavior of the sdhci device is after removal. Perhaps it remains active as a PCI device. I expect that an "lspci" before inserting the card will not show the 07:00.0 sdhci device. Does an "lspci" after removing the card still show the 07:00.0 device? Can you change config space values, e.g., the PCI_COMMAND register? If 07:00.0 still exists after removal, I would guess the reinsertion problem is in sdhci, not in the PCI core. I notice you have a ton of soft lockup complaints that seem to be related to the nouveau driver. Can you resolve those or get rid of that driver temporarily to make sure they aren't contributing to the sdhci problem?
Thomas, can you collect the lspci info requested?
Björn, I do not have that Ubuntu OS running, I have changed to Manjaro that has of course the same issue. What can we do? I think I should send new information as I am using a totally different kernel and Linux system. Best regards, Thomas (In reply to Bjorn Helgaas from comment #15) > Thomas, can you collect the lspci info requested?
It's probably a different kernel, but we should still be able make some progress. Let's try this: 1) Boot with the card reader empty 2) Collect output of "lspci -vvxxx" 3) Insert card in reader (I expect this works) 4) Collect output of "lspci -vvxxx" again 5) Eject card via software interface 6) Physically remove card from reader 7) Collect output of "lspci -vvxxx" again 8) Insert card in reader again (I expect this fails) 9) Collect complete dmesg log I'm looking for PCI hotplug events. It sounds like there's a PCI hot-add when the card is inserted. I don't know whether there's a corresponding PCI remove when the card is removed.