From owner-freebsd-questions@FreeBSD.ORG Thu Apr 9 22:38:08 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00A881065673 for ; Thu, 9 Apr 2009 22:38:08 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8559C8FC0A for ; Thu, 9 Apr 2009 22:38:07 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-196-108-192.dynamic.qsc.de [92.196.108.192]) by mx02.qsc.de (Postfix) with ESMTP id AADCA16C03CF; Fri, 10 Apr 2009 00:38:05 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id n39MbxBk001394; Fri, 10 Apr 2009 00:38:00 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Fri, 10 Apr 2009 00:37:59 +0200 From: Polytropon To: perryh@pluto.rain.com Message-Id: <20090410003759.dede9c9e.freebsd@edvax.de> In-Reply-To: <49de50cb.gcYrr9F1eSmdUBu9%perryh@pluto.rain.com> References: <49de2c9a.QlCBOleCO/iBrMcf%perryh@pluto.rain.com> <20090409181009.GA38361@slackbox.xs4all.nl> <49de50cb.gcYrr9F1eSmdUBu9%perryh@pluto.rain.com> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: rsmith@xs4all.nl, freebsd-questions@freebsd.org Subject: Re: USB SD-card reader recognized, but not working, on 6.1 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 22:38:08 -0000 On Thu, 09 Apr 2009 12:47:23 -0700, perryh@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, ...