FreeBSD bemused by USB card reader
I was playing with a USB card reader and FreeBSD, and I've discovered some quirks that I imagine need attention. The driver involved is umass(4). The card reader itself has four slots in which various formats of flash card can be inserted, and is a USB device. The quirks are as follows: 1. If the card reader is plugged in to the USB with no cards inserted, the result is a storm of messages, one for each of the four slots, saying in effect Medium not present; Unretryable error. Ok, kindof, but given how hard it tries (more than 80 lines of dmesg output are generated!), I think BSD is missing the point (ie, the media may come later...). 2. Device entry points da0, da1, da2 and da3 are created in /dev without any slice or partition subdevices (can somebody please point me to documentation which explains when and why I get da0s1 or da0a or da0s1a: I'd really like to know at the block device level what's going on there). 3. When I insert a card into the card reader: no messages are generated, and no new devices are generated (so I have to mount the device as da0, and can't mount any slices or partitions). Of course, there is a workaround here: plugging the card into the card reader *before* plugging it into the USB port works, but FreeBSD is underperforming here. For example, OSX has no problem in recognising a card being inserted or removed. Similarly, removing a card from the reader is also not noticed. I've tried `camcontrol rescan 0` (or all), as suggested in umass(4), but it doesn't change the devices present in /dev, so is clearly *not* recognising insertion or removal of cards. I don't know if this is an issue or not, but `usbdevs` never shows the cards, only the card reader. 4. This one is quite interesting: if I reboot with the card reader installed with a card in one slot (I was trying to boot off the card; no luck) and then remove it: it fails to remove da1, da2 and da3 from /dev. When I re-insert the card reader... I get two copies of da1! Look: # ls /dev/da1* /dev/da1 /dev/da1 Looks well dodgy to me. Ok, tried again (with the card removed), and this time I get two copies of da2 and da3 also: # ls /dev/da* /dev/da0 /dev/da1 /dev/da1 /dev/da2 /dev/da2 /dev/da3 /dev/da3 How very very strange. In case it's of interest, I've attached the output from `dmesg`. Oh: and here's `uname -a`: FreeBSD venus.araneidae.co.uk 6.1-STABLE FreeBSD 6.1-STABLE #1: Mon Aug 28 18:32:17 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386pci0: multimedia, audio at device 7.5 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0xd800-0xd8ff mem 0xe581-0xe58100ff irq 5 at device 8.0 on pci0 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:f4:b8:db:20 rl1: RealTek 8139 10/100BaseTX port 0xdc00-0xdcff mem 0xe5811000-0xe58110ff irq 10 at device 9.0 on pci0 miibus1: MII bus on rl1 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:40:f4:b8:db:1f rl2: RealTek 8139 10/100BaseTX port 0xe000-0xe0ff mem 0xe5812000-0xe58120ff irq 11 at device 11.0 on pci0 miibus2: MII bus on rl2 rlphy2: RealTek internal media interface on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: Ethernet address: 00:40:f4:b8:db:1e fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: Standard parallel printer port port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xcbfff,0xcc000-0xc,0xd-0xda7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 umass0: ICSI 2.0 Card Reader, rev 2.00/1.3a, addr 2 Timecounter TSC frequency 532640640 Hz quality 800 Timecounters tick every 1.000 msec ad2: 38204MB SAMSUNG MP0402H YQ200-04 at ata1-master UDMA100 da0 at umass-sim0 bus 0 target 0 lun 0 da0: ICSI CF Card CF 1.3A Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 122MB (250368 512 byte sectors: 64H 32S/T 122C) (da1:umass-sim0:0:0:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:1):
Re: FreeBSD bemused by USB card reader
Date: Sun, 3 Sep 2006 15:29:06 + (GMT) From: Michael Abbott [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-817021360-1157297346=:39827 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed I was playing with a USB card reader and FreeBSD, and I've discovered some quirks that I imagine need attention. The driver involved is umass(4). The card reader itself has four slots in which various formats of flash card can be inserted, and is a USB device. The quirks are as follows: 1. If the card reader is plugged in to the USB with no cards inserted, the result is a storm of messages, one for each of the four slots, saying in effect Medium not present; Unretryable error. Ok, kindof, but given how hard it tries (more than 80 lines of dmesg output are generated!), I think BSD is missing the point (ie, the media may come later...). 2. Device entry points da0, da1, da2 and da3 are created in /dev without any slice or partition subdevices (can somebody please point me to documentation which explains when and why I get da0s1 or da0a or da0s1a: I'd really like to know at the block device level what's going on there). 3. When I insert a card into the card reader: no messages are generated, and no new devices are generated (so I have to mount the device as da0, and can't mount any slices or partitions). Of course, there is a workaround here: plugging the card into the card reader *before* plugging it into the USB port works, but FreeBSD is underperforming here. For example, OSX has no problem in recognising a card being inserted or removed. Similarly, removing a card from the reader is also not noticed. I've tried `camcontrol rescan 0` (or all), as suggested in umass(4), but it doesn't change the devices present in /dev, so is clearly *not* recognising insertion or removal of cards. I don't know if this is an issue or not, but `usbdevs` never shows the cards, only the card reader. 4. This one is quite interesting: if I reboot with the card reader installed with a card in one slot (I was trying to boot off the card; no luck) and then remove it: it fails to remove da1, da2 and da3 from /dev. When I re-insert the card reader... I get two copies of da1! Look: # ls /dev/da1* /dev/da1 /dev/da1 Looks well dodgy to me. Ok, tried again (with the card removed), and this time I get two copies of da2 and da3 also: # ls /dev/da* /dev/da0 /dev/da1 /dev/da1 /dev/da2 /dev/da2 /dev/da3 /dev/da3 How very very strange. Strange, yes. Surprising, no. umass (and USB support is not in the best of shape in FreeBSD. But there is hope. A re-written USB driver set is currently in development. It's not even in -current, but the word from a limited number of testers is that it's a BIG improvement. (Giant free!) On the down side, umass is not one of the drivers that has been re-written last I checked. It is by far the most heavily utilized of the remaining drivers, but is also one of the more complex because of the huge number of different devices it must work with. I suspect that little work will be done on fixing the existing driver unless someone spots an easy bug to fix. (One or two of your problems MAY fit that category, but I am not familiar enough with the driver to really have an opinion worth listening to. I suspect that the new drivers are still a month or two from hitting -current and I don't know if they will be such that they can be merged into 6-stable or not. (If they require API or ABI changes, they can't go into V6.) If you want to follow this more closely (and maybe get some of your concerns addressed), you might try subscribing to the freebsd-usb list and sending details there and sending in a PR on what you've seen. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp6sDZXJyEwx.pgp Description: PGP signature
Re: FreeBSD bemused by USB card reader
On Sun, 3 Sep 2006, Kevin Oberman wrote: From: Michael Abbott [EMAIL PROTECTED] # ls /dev/da* /dev/da0 /dev/da1 /dev/da1 /dev/da2 /dev/da2 /dev/da3 /dev/da3 How very very strange. Strange, yes. Surprising, no. umass (and USB support) is not in the best of shape in FreeBSD. Does this phenomenon also point to a problem with devfs, or is the set of device names completely delegated to the corresponding driver (umass) by devfs? If you want to follow this more closely (and maybe get some of your concerns addressed), you might try subscribing to the freebsd-usb list and sending details there and sending in a PR on what you've seen. Sigh. I ought to. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD bemused by USB card reader
On Sun, 3 Sep 2006, Kevin Oberman wrote: From: Michael Abbott [EMAIL PROTECTED] # ls /dev/da* /dev/da0 /dev/da1 /dev/da1 /dev/da2 /dev/da2 /dev/da3 /dev/da3 How very very strange. Strange, yes. Surprising, no. umass (and USB support) is not in the best of shape in FreeBSD. Does this phenomenon also point to a problem with devfs, or is the set of device names completely delegated to the corresponding driver (umass) by devfs? Almost certainly. The creation of devfs entries is done by the driver (or at least the calls to the devfs to do so) are in the driver. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpPzbd0CaBoV.pgp Description: PGP signature
