USB SD-card reader recognized, but not working, on 6.1

[Polytropon]

On Thu, 09 Apr 2009 12:47:23 -0700, perryh at pluto.rain.com wrote:
> It's an SD card, not a "drive", so I had not expected it to be
> partitioned; but yes, it is:
> 
> $ ls -l /dev/da0*
> crw-r-----  1 root  operator    0, 244 Feb 14 15:09 /dev/da0
> crw-r-----  1 root  operator    0, 245 Feb 14 15:09 /dev/da0s1

Why don't you expect this? As far as I know, if something is
msdosfs-formatted (read: any "Windows" readable file system,
FAT), it always involves a "slice device". I never found a
situation where access to /dev/da0 would work.

You can always check any partitioning with

	# fdisk da0

which prints out a partition table. In your case, the card in the
reader will have one DOS partition which is to be accessed via the
"slice device".

The same is usually true for USB sticks, digital cameras (umass+da)
and MP3 players.

As long as you don't format them with UFS, you'll always find the
situation described above. You can easily get rid of it by

	# newfs /dev/da0

but don't expect "Windows" to be able to read it afterwards. :-)



> Read-only, which should be sufficient for mdir.  The card is,
> deliberately, write-protected.

Okay, that should not interference any reading process.



> After reconfiguring mtools to read from /dev/da0s1, I started
> getting those umass0: BBB bulk-in clear stall failed, TIMEOUT
> messages again, [...]

This indicates that the card reader (and mostly not the card itself)
is using non-standard compliant chipsets. I had a crappy MP3
player which didn't work on older FreeBSD versions, but does
today. I could not access it - the same situation as you described
it.

That is no failure of FreeBSD, it's simply the fact that the
manufacturer of the card drive produced crap.



> [...]  but I can read it a sector at a time using dd:
> 
> $ dd if=/dev/da0 of=~/sd bs=1b
> 
> That's been running for something like 45 minutes now, and based on
> the size of the output file it has read about a tenth of the card.
> 
> It looks as if the problem arises only when attempting to read
> larger blocks.  (I haven't tried to find out how much larger.)

As it has been explained, it's completely normal that it is so slow.



> > Have you tried just mounting the card reader?
> 
> No, because I'd expect to panic the system if it is not in fact a
> valid (and readable) FAT filesystem.  Mtools seems much safer.

Don't worry. Especially for diagnostics it's useful first to try
the system's tools, and then third-party software (mtools).

	# mount -t msdosfs -o ro /dev/da0s1 /mnt
	# ls -R /mnt

That should work.

In any case, remember to unmount the card before ejecting it. To the
system, the situation is similar to removing a hard disk without
any warning - not good. :-)

	# umount /mnt

If problems seem to slow down or stop the CAM subsystem, you can
always use

	# camcontrol rescan all

to let the system update what's on the "SCSI bus". In most cases,
you won't see any system panics. It *may* happen when you're pulling
the card out of the drive while writing on it. Just imagine it was
a regular hard disk - does the system encourage you to do so? :-)



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...