Billionton Cardbus to USB 2.0 PC Card adapter

[Warner Losh]

On Oct 27, 2011, at 10:22 PM, Ian Smith wrote:

> On Thu, 27 Oct 2011, Warner Losh wrote:
>> Power to the USB device?  CardBus cards don't get much power from the 
>> system, and often are underprovisioned to give power to the devices.  
>> Many of the require additional external adapters to power just about 
>> anything.  Try a self-powered device instead.  I've had several 
>> experiences where I had non-working devices that worked when I 
>> plugged in an external adapter.
>> 
>> Warner
> 
> Thanks Warner.  I'm off for a couple of days but will try it through a 
> powered hub when I get back.  Funny, it has a small socket between the 
> ports on the card for a 2.5mm? plug saying 5V (with usual polarity) and 
> I assumed that was a 5V power output - but maybe it's asking for 5V 
> input?  No plug or cord with it, so I'll hunt one up and test it.

That's exactly what that's for.  To provide power to external devices.

> Getting hard to find good Cardbus gear these days ..

Yea..  Ebay is even drying up.

Warner

> cheers, Ian
> 
>> On Oct 27, 2011, at 9:17 PM, Ian Smith wrote:
>> 
>>> Finding no clues to something known to work on FreeBSD, I'm trying 
>>> $subject card, wanting to add 2 x USB 2.0 ports to my Thinkpad T23 
>>> running 8.2-RELEASE, and soon 9.0-RC1
>>> 
>>> The T23 has 2 x USB 1.0 UHCI ports.  They work fine but 12 minutes to 
>>> write an 9.0-RC1 image is not much fun, forget external USB HDs etc.
>>> 
>>> Plugging in the card looks promising enough:
>>> 
>>> Oct 27 18:28:54 t23 kernel: ohci0: <NEC uPD 9210 USB controller> mem 0x88000000-0x88000fff irq 11 at device 0.0 on cardbus0
>>> Oct 27 18:28:54 t23 kernel: ohci0: [ITHREAD]
>>> Oct 27 18:28:54 t23 kernel: usbus3: <NEC uPD 9210 USB controller> on ohci0
>>> Oct 27 18:28:54 t23 kernel: usbus3: 12Mbps Full Speed USB v1.0
>>> Oct 27 18:28:54 t23 kernel: ohci1: <NEC uPD 9210 USB controller> mem 0x88001000-0x88001fff irq 11 at device 0.1 on cardbus0
>>> Oct 27 18:28:54 t23 kernel: ohci1: [ITHREAD]
>>> Oct 27 18:28:54 t23 kernel: ugen3.1: <NEC> at usbus3
>>> Oct 27 18:28:54 t23 kernel: uhub3: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
>>> Oct 27 18:28:54 t23 kernel: usbus4: <NEC uPD 9210 USB controller> on ohci1
>>> Oct 27 18:28:54 t23 kernel: usbus4: 12Mbps Full Speed USB v1.0
>>> Oct 27 18:28:54 t23 kernel: ehci0: <NEC uPD 720100 USB 2.0 controller> mem 0x88002000-0x880020ff irq 11 at device 0.2 on cardbus0
>>> Oct 27 18:28:54 t23 kernel: ehci0: [ITHREAD]
>>> Oct 27 18:28:54 t23 kernel: usbus5: EHCI version 0.95
>>> Oct 27 18:28:54 t23 kernel: ugen4.1: <NEC> at usbus4
>>> Oct 27 18:28:54 t23 kernel: uhub4: <NEC OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
>>> Oct 27 18:28:54 t23 kernel: usbus5: <NEC uPD 720100 USB 2.0 controller> on ehci0
>>> Oct 27 18:28:54 t23 kernel: usbus5: 480Mbps High Speed USB v2.0
>>> Oct 27 18:28:54 t23 kernel: ugen5.1: <NEC> at usbus5
>>> Oct 27 18:28:54 t23 kernel: uhub5: <NEC EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus5
>>> Oct 27 18:28:56 t23 kernel: uhub4: 2 ports with 2 removable, self powered
>>> Oct 27 18:28:56 t23 kernel: uhub3: 3 ports with 3 removable, self powered
>>> Oct 27 18:28:57 t23 kernel: uhub5: 5 ports with 5 removable, self powered
>>> 
>>> But plugging in either of my (working on the UHCI USB1 ports) USB memory 
>>> sticks fails, and in quite inconsistent ways on subsequent insertion and 
>>> removal.  More successful, in that /dev/da0 appears but is inaccessible:
>>> 
>>> Oct 28 01:26:52 t23 root: Unknown USB device: vendor 0x0951 product 0x1624 bus uhub5
>>> Oct 28 01:26:52 t23 kernel: ugen5.2: <Kingston> at usbus5
>>> Oct 28 01:26:52 t23 kernel: umass0: <Kingston DataTraveler G2, class 0/0, rev 2.00/1.00, addr 2> on usbus5
>>> Oct 28 01:26:52 t23 kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0000
>>> Oct 28 01:26:53 t23 kernel: umass0:2:0:-1: Attached to scbus2
>>> Oct 28 01:26:55 t23 kernel: (probe0:umass-sim0:0:0:0): AutoSense failed
>>> Oct 28 01:26:55 t23 kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
>>> Oct 28 01:26:55 t23 kernel: da0: <Kingston DataTraveler G2 PMAP> Removable Direct Access SCSI-0 device
>>> Oct 28 01:26:55 t23 kernel: da0: 40.000MB/s transfers
>>> Oct 28 01:26:55 t23 kernel: da0: 7640MB (15646720 512 byte sectors: 255H 63S/T 973C)
>>> Oct 28 01:27:00 t23 kernel: (da0:umass-sim0:0:0:0): AutoSense failed
>>> Oct 28 01:27:32 t23 last message repeated 3 times
>>> Oct 28 01:29:36 t23 last message repeated 12 times
>>> Oct 28 01:33:12 t23 last message repeated 4 times
>>> 
>>> .. during which time I was trying things like below, before even trying 
>>> to mount it.  Throughout that time the LED on the stick flashes about 4 
>>> times per second, steady, like it's repeatedly trying to connect.
>>> 
>>> smithi on t23% ll /dev/da*
>>> crw-r-----  1 root  operator    0, 157 Oct 28 01:26 /dev/da0
>>> smithi on t23% id -p
>>> uid     smithi
>>> groups  smithi wheel operator staff dialer network vboxusers
>>> smithi on t23% dd if=/dev/da0 count=1 | hd
>>> dd: /dev/da0: Input/output error
>>> 0+0 records in
>>> 0+0 records out
>>> 0 bytes transferred in 0.193469 secs (0 bytes/sec)
>>> smithi on t23% ll /dev/da*
>>> crw-r-----  1 root  operator    0, 157 Oct 28 01:26 /dev/da0
>>> smithi on t23% fdisk /dev/da0
>>> fdisk: unable to get correct path for /dev/da0: Input/output error
>>> smithi on t23% date
>>> Fri Oct 28 01:37:21 EST 2011
>>> smithi on t23% ll /dev/da*
>>> crw-r-----  1 root  operator    0, 157 Oct 28 01:26 /dev/da0
>>> 
>>> I've done all that as root other times, it's not a permissions thing.  
>>> Here it seems to disconnect cleanly on removal, not so at other times:
>>> 
>>> Oct 28 01:40:36 t23 kernel: ugen5.2: <Kingston> at usbus5 (disconnected)
>>> Oct 28 01:40:36 t23 kernel: umass0: at uhub5, port 2, addr 2 (disconnected)
>>> Oct 28 01:40:36 t23 kernel: (da0:umass-sim0:0:0:0): lost device
>>> Oct 28 01:40:36 t23 kernel: (da0:umass-sim0:0:0:0): removing device entry
>>> 
>>> Another less successful attempt, with juicy error messages.  To an old 
>>> systems hacker such inconsistency smells of timing issues, but my sense 
>>> of smell isn't what it used to be :)
>>> 
>>> Oct 27 18:32:57 t23 root: Unknown USB device: vendor 0x090c product 0x1000 bus uhub5
>>> Oct 27 18:32:57 t23 kernel: ugen5.2: <USB 2.0> at usbus5
>>> Oct 27 18:32:57 t23 kernel: umass0: <USB 2.0 product 0x1000, class 0/0, rev 2.00/11.00, addr 2> on usbus5
>>> Oct 27 18:32:57 t23 kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0000
>>> Oct 27 18:32:58 t23 kernel: umass0:2:0:-1: Attached to scbus2
>>> Oct 27 18:32:58 t23 kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
>>> Oct 27 18:32:58 t23 kernel: (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
>>> Oct 27 18:32:58 t23 kernel: (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
>>> Oct 27 18:32:58 t23 kernel: (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed)
>>> Oct 27 18:32:58 t23 kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
>>> Oct 27 18:32:58 t23 kernel: da0: <USB 2.0 Flash Disk 1100> Removable Direct Access SCSI-0 device
>>> Oct 27 18:32:58 t23 kernel: da0: 40.000MB/s transfers
>>> Oct 27 18:32:58 t23 kernel: da0: 967MB (1981440 512 byte sectors: 64H 32S/T 967C)
>>> Oct 27 18:33:07 t23 kernel: ugen5.2: <USB 2.0> at usbus5 (disconnected)
>>> Oct 27 18:33:07 t23 kernel: umass0: at uhub5, port 1, addr 2 (disconnected)
>>> Oct 27 18:33:07 t23 kernel: (da0:umass-sim0:0:0:0): AutoSense failed
>>> Oct 27 18:33:07 t23 kernel: (da0:umass-sim0:0:0:0): lost device
>>> Oct 27 18:33:07 t23 kernel: (da0:umass-sim0:0:0:0): Invalidating pack
>>> Oct 27 18:33:07 t23 kernel: (da0:umass-sim0:0:0:0): removing device entry
>>> 
>>> The apparent connection and then soon disconnection occurs without any 
>>> attempts at access by me.  This 1GB Shintaro stick also works on the 
>>> UHCI ports, and I'd expect the Kingston stick to be reasonable quality.
>>> 
>>> Inserting the card with a USB stick already in place fared no better.
>>> 
>>> Any advice on things to try welcome.
>>> 
>>> cheers, Ian
> 
>