Re: USB SD-card reader recognized, but not working, on 6.1
2009/4/10 per...@pluto.rain.com: Polytropon free...@edvax.de wrote: On Thu, 09 Apr 2009 12:47:23 -0700, per...@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. My experience is exactly the reverse. I've never before seen a removable-media device (floppy, Zip-drive, JAZ drive) that *did* have a DOS partition table aka BSD slice table. Surely you would not expect a USB floppy to show up as /dev/da0s1? AFAIK the reason for creating slices is to identify sections of the device for use by different OS -- something often needed for multi-boot from a hard drive but seldom on removable media. I sure wasn't planning to use part of this SD card for my camera to store pictures on, and the rest for FreeBSD backups :) Aha, careful. A flash drive/card is more like a removable hard drive. Since it's so much bigger than a floppy etc (typically) it makes sense to have a proper slice (partition) structure. If you want to boot off a floppy, it's a different operation from booting off a HDD for precisely this reason. Whereas a floppy isn't a proper, 'fixed' type disk; it's a tiny thing, suitable for max ~10 files. There's no need to have the overhead of a partition table, MBR etc. Same with CDs, booting off them involves several strange fudges (El Torito). Since a flash card would be a sensible thing to boot off, the designers want it to look more like a hard drive; as well as having the flexibility. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB SD-card reader recognized, but not working, on 6.1
On Thu, Apr 09, 2009 at 10:12:58AM -0700, per...@pluto.rain.com wrote: Trying here, after no answer on usb@ When I plug in the reader, I get (on the console): umass0: SDMMC M121 USB 2.0 SD/MMC READER, rev 2.00/2.01, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB 2.0 SD/MMC Reader \001\000\000? Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 1962MB (4019200 512 byte sectors: 255H 63S/T 250C) So far, so good, and it appears -- based on this excerpt from the mtoolstest output -- that mtools is configured to read /dev/da0 as b: drive B: #fn=1 mode=0 defined in /usr/local/etc/mtools.conf file=/dev/da0 fat_bits=0 tracks=0 heads=0 sectors=0 hidden=0 offset=0x0 partition=0 However, when I try to read it with mtools: $ mdir -a b: init B: non DOS media Cannot initialize 'B:' Are you sure that the drive isn't partitioned? In other words, if you plug in the drive, and you give the command 'ls /dev/da0*', do you only get /dev/da0 or perhaps also /dev/da0s1? If it is partitioned, try /dev/da0s? instead. Second, does the user running mtools have read and write access to the device? Have you tried just mounting the card reader? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpLbZvqNH2Zv.pgp Description: PGP signature
Re: USB SD-card reader recognized, but not working, on 6.1
Roland Smith rsm...@xs4all.nl wrote: Are you sure that the drive isn't partitioned? In other words, if you plug in the drive, and you give the command 'ls /dev/da0*', do you only get /dev/da0 or perhaps also /dev/da0s1? If it is partitioned, try /dev/da0s? instead. 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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 245 Feb 14 15:09 /dev/da0s1 Second, does the user running mtools have read and write access to the device? Read-only, which should be sufficient for mdir. The card is, deliberately, write-protected. After reconfiguring mtools to read from /dev/da0s1, I started getting those umass0: BBB bulk-in clear stall failed, TIMEOUT messages again, 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.) 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB SD-card reader recognized, but not working, on 6.1
On Thu, Apr 09, 2009 at 12:47:23PM -0700, per...@pluto.rain.com wrote: Roland Smith rsm...@xs4all.nl wrote: Are you sure that the drive isn't partitioned? In other words, if you plug in the drive, and you give the command 'ls /dev/da0*', do you only get /dev/da0 or perhaps also /dev/da0s1? If it is partitioned, try /dev/da0s? instead. 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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 245 Feb 14 15:09 /dev/da0s1 That would suggest that there is a filesystem on there, doesn't it? Second, does the user running mtools have read and write access to the device? Read-only, which should be sufficient for mdir. The card is, deliberately, write-protected. After reconfiguring mtools to read from /dev/da0s1, I started getting those umass0: BBB bulk-in clear stall failed, TIMEOUT messages again, but I can read it a sector at a time using dd: Try running unplugging the device, run 'camcontrol rescan all' and plug it in again. Then wait until the devices show up. $ 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. Reading one byte at a time is bound to be slow. It could be that this USB chipset needs some quirks to work correctly. There are some really crappy USB chipsets out there. E.g. I've had trouble with prolific controllers, especially on older (single core) machines. If you are in a position to do so, you could try the new USB stack in 8-CURRENT. 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. I can't recall mount_msdosfs ever panicing the kernel on me in that case. It usually just fails. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp3Yy0a0mNdt.pgp Description: PGP signature
Re: USB SD-card reader recognized, but not working, on 6.1
On Thu, 09 Apr 2009 12:47:23 -0700, per...@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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 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, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB SD-card reader recognized, but not working, on 6.1
Roland Smith rsm...@xs4all.nl wrote: On Thu, Apr 09, 2009 at 12:47:23PM -0700, per...@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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 245 Feb 14 15:09 /dev/da0s1 That would suggest that there is a filesystem on there, doesn't it? It would certainly suggest there is a DOS partition table aka BSD slice table. I don't think it says anything about what the slice contains, however. $ 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. Reading one byte at a time is bound to be slow. dd bs=1b is one block (512 bytes), not one byte. At least it seems to be working. I *would* anticipate problems if trying to read a umass device in units not a multiple of its native blocksize. It could be that this USB chipset needs some quirks to work correctly. like Don't attempt to read more than 32768 bytes at a time -- subsequent testing shows it to be OK up to bs=64b, but bs=126b fails -- or is there maybe a way to set that sort of limit in mtools? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB SD-card reader recognized, but not working, on 6.1
Polytropon free...@edvax.de wrote: On Thu, 09 Apr 2009 12:47:23 -0700, per...@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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 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. My experience is exactly the reverse. I've never before seen a removable-media device (floppy, Zip-drive, JAZ drive) that *did* have a DOS partition table aka BSD slice table. Surely you would not expect a USB floppy to show up as /dev/da0s1? AFAIK the reason for creating slices is to identify sections of the device for use by different OS -- something often needed for multi-boot from a hard drive but seldom on removable media. I sure wasn't planning to use part of this SD card for my camera to store pictures on, and the rest for FreeBSD backups :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: USB SD-card reader recognized, but not working, on 6.1
On Thu, Apr 09, 2009 at 08:01:29PM -0700, per...@pluto.rain.com wrote: Roland Smith rsm...@xs4all.nl wrote: On Thu, Apr 09, 2009 at 12:47:23PM -0700, per...@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 operator0, 244 Feb 14 15:09 /dev/da0 crw-r- 1 root operator0, 245 Feb 14 15:09 /dev/da0s1 That would suggest that there is a filesystem on there, doesn't it? It would certainly suggest there is a DOS partition table aka BSD slice table. I don't think it says anything about what the slice contains, however. Well, why bother making slices if you're not going to put a filesystem on it? snip It could be that this USB chipset needs some quirks to work correctly. like Don't attempt to read more than 32768 bytes at a time -- subsequent testing shows it to be OK up to bs=64b, but bs=126b fails -- or is there maybe a way to set that sort of limit in mtools? I don't know. The quirks I was talking about are built into the USB drivers. See /usr/src/sys/dev/usb/umass.c Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpTRftHYyWdr.pgp Description: PGP signature
