# Problem with flash reader

## Solop

This is a bit of an odd one for me.

I've got a Sandisk 8 in 1 flash reader that's working *almost* perfectly.

I'm running gentoo-dev-sources kernel 2.6.4-r1, with a mostly genkernel configuration.  I've modified it a bit to add things like NTFS, but it's pretty close to stock  I've emerged hotplug, and everything else that seems relevant -- and definitely included the usual SCSI stuff in the kernel config.

The problem: The reader is correctly recognized when plugged in, and four devices are assigned (usually /dev/sda through /dev/sdd), the actual flash cards are not recognized unless they're inserted in the device when I plug it in (or boot the computer).  That is to say, while /dev/sda is created, I only get /dev/sda1 if there's a compact flash actually in the reader when I plug the reader in.

Shouldn't there be something watching for media insertions/removals and creating/removing the /dev links?  I could swear that's what was happening with 2.6.3...

Any suggestions where to look?  I'm getting annoyed at having to unplug and replug the reader because I didn't leave a flash card in it when I booted.

----------

## Malakin

You have hotplug enabled in the kernel?

----------

## Solop

 *Malakin wrote:*   

> You have hotplug enabled in the kernel?

 

Yup:

```
CONFIG_HOTPLUG=y
```

----------

## Malakin

You probably also need "Automatic kernel module loading" enabled if you're using modules.

----------

## Solop

Keep in mind that hotplug *is* working at a gross level; if I plug in my removable hard drive, it is recognized and I can immediately mount /dev/sde5.  Similarly, if I have a compact flash card in the reader when I plug that in, the card is recognized and I can immediately mount /dev/sda1.

What's not being detected is what amounts to a media change: if I remove the compact flash card without unplugging the reader, /dev/sda1 does not go away.  Similarly, if I plug in the reader, /dev/sda is created, but inserting the flash card does not create /dev/sda1.

I'm going to try a zip drive when I get home tonight and see if the problem is unique to the flash reader, or if it affects any USB device with removable media.

----------

## Solop

Update now that I'm home and can actually *look* at the system: Yes, automatic kernel module loading is turned on.

And the USB Zip drive behaves exactly the same way.  Plug it in without a disc and I never get a partition.  Plug it in with a disc and I do get a partition (in this case /dev/sde4).

Odd.  But at least I've proved that the problem is not the flash reader.  And, since the Zip drive is USB 1.1, I've also established that it's not a problem with the USB 2.0 support or a problem with the hub.

At this point, the only thing I can think of that I haven't tried yet is rebuilding the kernel with sd_mod as a module instead of built in.  Can't imagine that would make a difference, but unless someone says "Don't bother", I'll give that a shot next.

----------

## dmoulton

Bumping this, wondering if there are any updates or solutions. I am having the same problem, but I'm using 2.6.3. I have noticed that if I try to mount  /dev/sdb, I get an error, but /dev/sdb1 shows up and I can mount it properly. I haven't rebooted to find out, but as I remember 2.4. worked fine.

----------

## Solop

 *dmoulton wrote:*   

> Bumping this, wondering if there are any updates or solutions. I am having the same problem, but I'm using 2.6.3. I have noticed that if I try to mount  /dev/sdb, I get an error, but /dev/sdb1 shows up and I can mount it properly. I haven't rebooted to find out, but as I remember 2.4. worked fine.

 

Very interesting!  I just recompiled, changing the config to make sd_mod a module.  I also emerged the latest hotplug.  No change in my previous behavior (i.e. media changes don't seem to be recognized), but I tried your trick and tried to mount the drive (in this case /dev/sdd) and got a "You must specify the filesystem type" message.  I then tried to mount /dev/sdd1 and it mounted successfully.

Here's what dmesg has to say about the first mount:

```
SCSI device sdd: 63424 512-byte hdwr sectors (32 MB)

sdd: assuming Write Enabled

sdd: assuming drive cache: write through

SCSI device sdd: 63424 512-byte hdwr sectors (32 MB)

sdd: assuming Write Enabled

sdd: assuming drive cache: write through

 /dev/scsi/host2/bus0/target0/lun3: p1

FAT: bogus number of reserved sectors

VFS: Can't find a valid FAT filesystem on dev sdd.

```

In short, it seems that attempting to access the *drive* triggers the media detection.  I wonder if using automount would clean any of this up.

    S.

----------

## hardstor

Hi Solop, 

In the same boat as you with this one exactly. No media change. 

I used to use a system without devfs... the /dev tree had ALL these nodes. As a result, I could drop in the media any time i wanted...

Based on your post here, and my toying around, I'm beginning to believe that some process needs to "bump"/poll/check/etc. the device on a frequent basis after its been plugged in order to identify that there's a new device to hang on the tree... 

Don't think its a hotplug thing, maybe a devfs thing? *shrugs*

For the record, I've got...

SCSI emulation compiled in

SCSI disk support (and some other SCSI options) compiled in

USB core as a module

USB Preliminary device support compiled

USB-UHCI as a module

USB Mass Storage as a module

Hotplugging compiled in

Have not loaded any USB modules at boot via modules.autoload, I'm relying on hotplug to do the work.

This is a very very annoying problem and I'm not sure where to take it from here besides creating a little shell script like

```
#!/bin/bash

if [ ! -e /dev/sdb1 ]; then

  mount -t auto /dev/sdb /mnt/sd 2>/dev/null

fi

mount -t auto /dev/sdb1 /mnt/sd
```

[/code]

NASTY![/code]

----------

## jetmonkey

Hi Guys,

I've been having the same trouble for days since getting a shiny new IXUS 500 camera and a flash card reader. Tried all kinds of different stuff but always the same result, can access the card once fine, but have to reboot or unplug/replug the card reader if the media changes.....pain in the arse!! But then a miracle  :Wink:  SuperMount saved me!

First I had to get rid of the remnants of my previous failed attempts with submount and various other systems which I'm sure are perfectly good but didn't work for me (probably because I didn't take the time to RTFM  :Wink: . So from a "clean" system with 2.6.5 kernel:

Enable: Supermount removable media support (SUPERMOUNT) in the kernel config. You'll find it under File Systems>>Psudo Filesytems in menuconfig.

Then add the following to /etc/fstab

none  /home/chris/cardreader supermount fs=vfat,dev=/dev/sda1,--,user,uid=1000,gid=100  0 0

See http://sourceforge.net/docman/display_doc.php?docid=16857&group_id=79609 for a description of what that's all about....

After putting the new kernel in /boot and rebooting, everything works, even better than it does in "that other OS"  :Wink:  I change the card, the file list changes, don't need to manually do anything, it just works.

----------

## Solop

hardstor: My config looks very much like yours, though I've experimented a fair amount with compiling in versus using modules.

jetmonkey: Your issue sounds very similar, but I'm not quite sure it's the same.  Your workaround is very much the same as mine, though.

For what it's worth, I've managed to reduce the problem from "Royal pain in the Rear" to "Mildly Annoying".  I've installed and set up automount; if /dev/sdx1 exist, they'll be used by automount.  So then I just leave the flash reader plugged in all the time.  Once a month or so, I have to reboot (usually because I've built a new kernel).  When the boot finishes, I just plug one of each kind of flash into the reader and try to mount /dev/sdx (not /dev/sdx1).  Those fail with an incorrect fstype message, but the appropriate partition nodes get created and after that automount works just fine until the next reboot.

At this point, the biggest annoyance is that the various slots in the reader don't always get assigned to the same device.  For example, at the moment the SD slot is /dev/sdb, but before the latest reboot it was /dev/sdc.  Fortunately, using automount, I can just go change the assignments in auto.flash and the links from /mnt to /dev/autofs are essentially remapped on the fly.  I suspect that behavior is specific to this Sandisk reader.  I may trade it in for one with fewer slots and/or one from a different manufacturer and see if that helps.  <grin>

----------

