I'm the original poster of the (5 yo) Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/258446, quoting: "My Acer Aspire 5930G has an internal 5-in-1 card reader. Testing with an SD card (no alternative media available), the reader is only listed by lspci if the SD card is present in the reader at boot time." Reading https://bugzilla.kernel.org/show_bug.cgi?id=16119 , I was hoping that kernel 3.12-rc1 and later would fix this issue for me, but unfortunately, it persists with Ubuntu 14.04 (uname -a: Linux razor 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux)
Thanks for reporting this again, Bernhard. I'm embarrassed that nothing has happened in over 5 years. Tasos mentioned (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/258446/comments/89) that doing "echo 1 > /sys/bus/pci/rescan" after the card was inserted caused it to be recognized. Does that make any difference on your system? I know the launchpad report has similar logs, but I think they're from older kernels and we've made significant changes since then, so would you mind doing the following? - Boot with SD card in slot - Collect complete "lspci -vv" and dmesg output and attach here and - Boot with empty SD card slot - Insert SD card - Try "echo 1 > /sys/bus/pci/rescan" - Collect complete "lspci -vv" and dmesg output and attach here
Created attachment 134891 [details] dmesg output with SD card inserted at boot time
Created attachment 134901 [details] lspci -vv output with SD card inserted at boot time
Created attachment 134911 [details] dmesg output with *no* SD card inserted at boot time, after forced PCI rescan
Created attachment 134921 [details] lspci -vv output with *no* SD card inserted at boot time, after forced PCI rescan
Björn, no need to be embarrassed. I guess I just should've reported this bug upstream earlier instead of waiting for Ubuntu devs to do something about it. Anyway, forcing rescan via "echo 1 | sudo tee /sys/bus/pci/rescan" unfortunately didn't result in the SD card becoming available -- logs attached. (Just doing echo 1 > /sys/bus/pci/rescan gives "Permission denied", as does sudo'ing that command). I also tried sudo sh -c "echo 1 > /sys/bus/pci/rescan" -- doesn't make the SD card available, either. With SD inserted at boot time, the card is available. Logs attached. I used a SanDisk 64 GB SDXC card for testing (exFAT formatted, with required drivers installed via exfat-fuse and exfat-utils Ubuntu packages).
Amazingly, updating by BIOS from V1.15 (06/13/2008) to V1.23 (10/28/2008) (as suggested by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/258446/comments/111) did indeed fix this issue for me. Sorry for the noise! (I guess I'm part of a small group of PC owners whose system was shipped with that BIOS version before it was fixed a couple of months later, and who never updated. The strange thing is that the SD card had been properly recognized under Windows before, i.e. using the old BIOS.) I'm setting this to RESOLVED OBSOLETE, hope that's okay.
Closing this is fine. It would be better if we could fix this without requiring a BIOS update, since it *does* work with Windows even with the old BIOS. But I don't know how much value there is in doing that. With the new BIOS, is the SD card reader (05:00.0) present all the time, whether a card is inserted or not? Would you mind collecting a new "lspci -vv" output as root? The ones you collected don't show the PCIe capability details. Also, if you could attach an acpidump (see https://01.org/linux-acpi/utilities), that would be great. Based on the dmesg, it looks like we're using acpiphp (not pciehp) for the SD card reader. I don't see any hotplug events in the dmesg log, but I don't know whether acpiphp logs anything by default. I added Rafael in case he has any interest in this.
I might've started the party too early. Today, the SD isn't working. Maybe last time I hadn't really shut down but rebooted from a state in which I had the SD inserted before, and that lead to a false positive. Now I'm the one who's embarrassed. Anyway, attaching acpidump and sudo lscpci -vv output as requested.
Created attachment 135241 [details] sudo lspci -vv output
Created attachment 135251 [details] sudo acpidump output
Created attachment 135261 [details] disassembled acpidump (DSDT, all SSDT*)
I now tested with 3.15-rc8; unfortunately, the issue's still present. uname -a Linux razor 3.15.0-031500rc8-generic #201406012235 SMP Mon Jun 2 02:36:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux What I doe see in dmesg after inserting an SDXC card is: [ 2847.188289] ACPI: \_SB_.PCI0.RP04: ACPI_NOTIFY_BUS_CHECK event [ 2847.188349] ACPI: \_SB_.PCI0.RP04: Bus check in hotplug_event()
I wonder if this is related to bug #76901. Mika, any thoughts on this?
Since BUS_CHECK notifications are targeted to the root port (RP04) instead of the host bridge, I think it's not the same issue. Bernhard, can you retry with the 3.15-rc8 (or 3.15) kernel so that you have CONFIG_DYNAMIC_DEBUG=y and "acpiphp.dyndbg=+p" and attach the resulting dmesg here?
Sorry for not getting back to this earlier. The reason is that this is only erratically reproducible. I've had a couple of successful tries, but with 3.15-rc8 and 3.15, with the relevant dmesg part being [ 134.436478] ACPI: \_SB_.PCI0.RP04: ACPI_NOTIFY_BUS_CHECK event [ 134.436501] ACPI: \_SB_.PCI0.RP04: Bus check in hotplug_event() [ 134.436589] pci 0000:05:00.0: [197b:2382] type 00 class 0x088000 [ 134.436609] pci 0000:05:00.0: reg 0x10: [mem 0x00000000-0x000000ff] [ 134.436880] pci 0000:05:00.2: [197b:2381] type 00 class 0x080501 [ 134.436897] pci 0000:05:00.2: reg 0x10: [mem 0x00000000-0x000000ff] [ 134.437100] pci 0000:05:00.3: [197b:2383] type 00 class 0x088000 [ 134.437116] pci 0000:05:00.3: reg 0x10: [mem 0x00000000-0x000000ff] [ 134.437316] pci 0000:05:00.4: [197b:2384] type 00 class 0x088000 [ 134.437334] pci 0000:05:00.4: reg 0x10: [mem 0x00000000-0x000000ff] [ 134.444053] pci 0000:05:00.0: BAR 0: assigned [mem 0xf4000000-0xf40000ff] [ 134.444061] pci 0000:05:00.2: BAR 0: assigned [mem 0xf4000100-0xf40001ff] [ 134.444068] pci 0000:05:00.3: BAR 0: assigned [mem 0xf4000200-0xf40002ff] [ 134.444073] pci 0000:05:00.4: BAR 0: assigned [mem 0xf4000300-0xf40003ff] [ 134.444101] pci 0000:05:00.0: no hotplug settings from platform [ 134.444116] pci 0000:05:00.2: no hotplug settings from platform [ 134.444130] pci 0000:05:00.3: no hotplug settings from platform [ 134.444144] pci 0000:05:00.4: no hotplug settings from platform [ 134.501114] jmb38x_ms 0000:05:00.3: enabling device (0000 -> 0002) [ 134.536601] sdhci: Secure Digital Host Controller Interface driver [ 134.536604] sdhci: Copyright(c) Pierre Ossman [ 134.551997] sdhci-pci 0000:05:00.0: SDHCI controller found [197b:2382] (rev 0) [ 134.552026] sdhci-pci 0000:05:00.0: enabling device (0000 -> 0002) [ 134.552121] mmc0: no vqmmc regulator found [ 134.552122] mmc0: no vmmc regulator found [ 134.552209] mmc0: SDHCI controller on PCI [0000:05:00.0] using ADMA [ 134.552229] sdhci-pci 0000:05:00.2: SDHCI controller found [197b:2381] (rev 0) [ 134.552239] sdhci-pci 0000:05:00.2: enabling device (0000 -> 0002) [ 134.552273] sdhci-pci 0000:05:00.2: Refusing to bind to secondary interface. [ 134.841018] mmc0: new SDXC card at address aaaa [ 134.857378] mmcblk0: mmc0:aaaa SU64G 59.4 GiB [ 134.858587] mmcblk0: p1 Just now, I'm running on 3.15-rc8 (and haven't unfortunately set acpiphp.dyndbg=+p upon booting), and the SD card isn't shown upon insertion; dmesg, again, is only [ 134.436478] ACPI: \_SB_.PCI0.RP04: ACPI_NOTIFY_BUS_CHECK event [ 134.436501] ACPI: \_SB_.PCI0.RP04: Bus check in hotplug_event() I believe that it't rather likely to work if I try it shortly after bootup, and rather unlikely after a longer uptime. One thing I'll try to track down is if it's related to this laptop's hardware bluetooth button (whose state isn't stored when shutting down, so I usually turn it off intuitively shortly after bootup. Just turning it on again right now didn't cause the SD to be recognized, however.) I should probably permanently add acpiphp.dyndbg=+p to my kernel boot arguments...
Created attachment 139931 [details] acpiphp debug patch Can you try with the attached patch (and acpiphp.dyndbg=+p)? It adds more debug to the acpiphp driver which could shed some light into this. Please attach the complete dmesg. (the patch applies on top of v3.15).
Created attachment 233031 [details] Output logs from dmsg, lspci and acpidump commands
Hi. This problem stills happening today. I'm using a Debian Sid (unstable) fully updated and I got the same behaviour: It reads the card if I boot it with, but can't find it if there wasn't any sd card in the boot time. In windows it works normal, and the sdcard chipset is also Jmicron. ``` $ uname -a Linux bunsen 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) x86_64 GNU/Linux ``` With `CONFIG_DYNAMIC_DEBUG=y and acpiphp.dyndbg=+p` appended to kernel boot, I did the following commands and saved the output: ``` dmesg >> card.dmesg.out dmesg -k >> card.dmesg-k.out sudo lspci -vv >> card.lspci-vv.out sudo acpidump > card.acpidump.out ``` The first run `card.*` I did after a boot with a card at boot time. The `nocard.*` logs I did after boot the system without any card. Then I inserted a card, and save the logs as `postcard.*`. Then after the `echo 1 > /sys/bus/pci/rescan` command, I saved it as `postcard-rescan.*`. I attached the jmicron.tar.xz to this thread with all this files. The acpidump command if from Debian sid package `acpica-tools`. I did not tryied the patch in this list yet.