Bug 508324 - SD Card inserted into integrated SD Card slot doesn't mount
Summary: SD Card inserted into integrated SD Card slot doesn't mount
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 11
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-26 15:37 UTC by Jeremy Fitzhardinge
Modified: 2010-06-30 07:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 13:18:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jeremy Fitzhardinge 2009-06-26 15:37:52 UTC
Description of problem:
When I insert an SD card into my Thinkpad X200's SD slot, it appears to be detected, but it doesn't mount.  This is a regression from F10, which worked as expected.

Version-Release number of selected component (if applicable):
kernel-2.6.29.5-191.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Insert SD card
2.
3.
  
Actual results:
Fails to mount

Expected results:
Mounted SD card

Additional info:
If I attach the camera with USB, I can read the card that way.
This worked perfectly with Fedora 10.

Dmesg shows:
usb 2-6: new high speed USB device using ehci_hcd and address 15
usb 2-6: New USB device found, idVendor=05ca, idProduct=1880
usb 2-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-6: Product: USB2.0-FLASH Media    
usb 2-6: Manufacturer: RICOH             
usb 2-6: SerialNumber: R5U880-00003
usb 2-6: configuration #1 chosen from 1 choice
scsi17 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 15
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 17:0:0:0: Direct-Access     RICOH    R5U880FlashMedia 0000 PQ: 0 ANSI: 2
sd 17:0:0:0: [sdb] Attached SCSI removable disk
sd 17:0:0:0: Attached scsi generic sg1 type 0

(sg1?!)

$ lsusb
Bus 002 Device 015: ID 05ca:1880 Ricoh Co., Ltd 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 004: ID 0a5c:2145 Broadcom Corp. 
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
$ lsusb -v -s 2:15

Bus 002 Device 015: ID 05ca:1880 Ricoh Co., Ltd 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x05ca Ricoh Co., Ltd
  idProduct          0x1880 
  bcdDevice            0.01
  iManufacturer           1 RICOH             
  iProduct                2 USB2.0-FLASH Media    
  iSerial                 3 R5U880-00003
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              300mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Comment 1 malcolm 2009-12-09 18:07:31 UTC
I've been having similar problems for the last month. Problems started after an update (unfortunately I can't remember which one). I'm running 2 64 bit FC11 systems, and both show identical problems. All current patches are applied to both systems.
 
1) Automounting of all USB drives seems flaky. I have the following drives:
    a) several HD with USB adapters, some using LUKS encryption.
    b) several USB key drives
    c) a SDHC card with usb adapter, using LUKS encryption.

All drives use the ext3 file system.

All drives attached at boot time seem to mount consistently and successfully.
The first drive attached after a reboot seems to automount successfully with a high probability.
Subsequent drives, that are attached to the system sometimes automount, but often mount read only, but ofen .
Even drives that do not automount are detected and an appropriate /dev/sdxx entry generated. I can mount the drive by hand using the /dev/sdxx entry. Most of the time the hand mounted drive works correctly, but is often mounted read-only. The read only problem is particularly pronounced with the SDHC card.
Drives mounted after boot seem to experience a larger than expected number of i/o errors, which often causes them to be automatically remounted read-only at some point.

I have a netbook running the latest version of Ubunto (fully patched) which does not have any of these problems.

Comment 2 Bug Zapper 2010-04-27 15:16:30 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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

Comment 3 Eddie Lania 2010-05-05 14:34:16 UTC
In F12, non of my SD cards are mounted also.

Comment 4 Eddie Lania 2010-06-15 18:31:00 UTC
On Fedora 13, none of my micros SD cards > 1 GB are mounted.

Comment 5 Bug Zapper 2010-06-28 13:18:43 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

Comment 6 Mikko Huhtala 2010-06-30 07:17:05 UTC
Reopened as #609387 for F13. (I'm doing this wrong, aren't I? I can't change the version to F13.)


Note You need to log in before you can comment on or make changes to this bug.