Help debugging card reader problem?

I’m stuck on a problem which is almost certainly hardware, but I don’t know how to track down what and where the problem is.

I have a Dell Vostro 5515 running Manjaro. I dropped it on its side, with an SD card inserted in (and sticking out from) the SD card reader. After that, the SD card reader stopped working, though everything else was fine. The card reader just ignores any card inserted in it now. I assumed the card had been pushed into the reader and broken the contacts, so I ordered a new I/O card. The I/O card includes a USB connection, ethernet, and the SD card reader, and it was only the reader that stopped working. I replaced the old I/O card with the new one - and found I still have exactly the same problem.

So if the problem isn’t on the I/O card I don’t know where it can be. Maybe it isn’t mechanical damage after all, so I’m hoping some explanation will show up in the logs, but can’t find anything and don’t really know where to look.

dmesg shows nothing when I insert a card. Nor does journalctl. Nothing appears in /dev.

Can anyone suggest how to find out what is going on?

Thanks for any advice!

Since it is a Laptop and I guess the reader is connected via usb, I would rather think it is auto suspending. Normally, if TLP is enabled, it automatically suspend, when in battery mode.

So let me explain:

  1. AC mode → I insert a sd card and it works.
  2. BT mode → still inserted, still working.
  3. Now I put it off and put it in: No reaction. It sleeps.
  4. AC mode again: Put it off, put it in, works.

In fact, when in BT mode and auto suspending is active, there will be no trace, since USB was “shutdown”.

Have a look at /etc/tlp.conf and search for

#USB_AUTOSUSPEND=1

and replace it with

USB_AUTOSUSPEND=0

Then reboot the laptop.

Thanks megavolt: I tried that, but it made no visible difference. But now understanding from your hints that this is just another device on the USB bus, I went back and looked at dmesg and found this, which I guess is the problem. Am I right that this is likely to be a faulty input port on an onboard USB decoder of some kind?

   2.164575] usb 3-3: new full-speed USB device number 3 using xhci_hcd
[    2.332411] usb 3-3: New USB device found, idVendor=0cf3, idProduct=e007, bcdDevice= 0.01
[    2.332422] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.461261] usb 3-4: new full-speed USB device number 4 using xhci_hcd
[    2.591515] usb 3-4: device descriptor read/64, error -71
......................
[    2.828226] usb 3-4: device descriptor read/64, error -71
[    3.057955] usb 3-4: new full-speed USB device number 5 using xhci_hcd
[    3.188180] usb 3-4: device descriptor read/64, error -71
[    3.424909] usb 3-4: device descriptor read/64, error -71
[    3.531725] usb usb3-port4: attempt power cycle
[    3.934618] usb 3-4: new full-speed USB device number 6 using xhci_hcd
[    3.934890] usb 3-4: Device not responding to setup address.
[    4.141566] usb 3-4: Device not responding to setup address.
[    4.347946] usb 3-4: device not accepting address 6, error -71
[    4.471288] usb 3-4: new full-speed USB device number 7 using xhci_hcd
[    4.471558] usb 3-4: Device not responding to setup address.
[    4.678201] usb 3-4: Device not responding to setup address.
[    4.884617] usb 3-4: device not accepting address 7, error -71
[    4.884991] usb usb3-port4: unable to enumerate USB device
LANG=C errno 71
EPROTO 71 Protocol error

Most likely it is A) a wrong cable with less pins, commonly used for power connection only or B) a Pin is broken and no data can be transferred because of that.

I don’t believe it is either of those: the cable is the original one, which was working; and I have replaced the IO card which has all the pins of the reader on it.

Sorry, but I can only repeat. There must be a break at some point of the connection. SD Card? Slot? Cable? USB-Hub? That is what the error -71 says here.

Are you sure 3-4 is the correct device?

lsusb -vt

Ok.

  • Not the sdcard - have tried several, and all work in other readers
  • Not the slot: I’ve replaced that (unless Dell sent me a faulty one which I guess is possible but unlikely)
  • Might be the cable. The cable also carries the signals for a USB-2 port and an ethernet port, both of which are ok, but I guess it could be possible that one wire within the cable burnt out?
  • Could be a pin on wherever the cable goes to

I don’t know if 3-4 is the correct device, but it is the only one to show an error in dmesg. It doesn’t seem to be listed by lsusb, I guess because of the fault?

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0c45:6a10 Microdia 
    |__ Port 1: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0c45:6a10 Microdia 
    |__ Port 3: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        ID 0cf3:e007 Qualcomm Atheros Communications 
    |__ Port 3: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
        ID 0cf3:e007 Qualcomm Atheros Communications 
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub

Hm… by saying “burnt” I remember another problem… “overcurrent protection”. If you have usb devices which need a lot of amperes, it will refuse like that and produce weirdo errors.

Shutdown the laptop, wait some minutes and turn it on again. Maybe it gets solved then.

Why I am thinking that? Because of that:

Good idea. I’ll leave it off overnight and see (I usually just leave it on ‘sleep’).

Back on after a long night off… and no change at all :frowning:

Just a thought, but some BIOS’es have a setting to enable “USB3.1 Charger support” maybe yours has also…

And this might maybe help also: Linux USB API@kernel.org

Thanks to both Megavolt and TriMoon for the suggestions. Megavolt was right: it is a broken connection; but it is on the cable connecting to the I/O card, not the I/O card itself as I thought. Unfortunately that cable is part of a bus that includes several of the main components (eg hard drive) and beyond my capability to replace; I’ll have to live without the SD card reader. Oh well, could have been worse. Thanks again.