USB drives still don't work correctly

[Donald Allen]

I've been away for awhile and could not work on this issue. I just looked at
the OpenBSD 4.7 sources, and there is no entry in sys/devs/usbdev.h for a
vendor with id 0x04fc, nor is there a product id 0x0c15. Considering this
and looking at their usb_quirks.c and umass_quirks.c, I don't think OpenBSD
is issuing any quirks for the devices I have, and yet these drives work
correctly with 4.7, whether plugged in at boot time or hotplugged. So I
think there's more to the hotplug problem I'm seeing with FreeBSD 8.1 than
simply missing a quirk. If I'm right about this, I'd like to work with those
of you actively developing the USB layer to understand what's going on here,
leading to a bug-fix if indeed there is a bug. Yes, I can drop this
discussion and just work around the problem, albeit inconveniently, by
plugging the drives in at boot-time, but given that the drives work with
other systems, if I'm going to use FreeBSD, I'd like to see this problem
either explained or fixed.

/Don


On Fri, Sep 24, 2010 at 11:35 AM, Bernd Walter <ticso at cicely7.cicely.de>wrote:

> On Fri, Sep 24, 2010 at 11:16:14AM -0400, Donald Allen wrote:
> > A few more things on this issue:
> >
> > 1. I installed FreeBSD on another system, just on the off-chance that
> > my problem might be caused by testing with an old machine (c. 2005).
> > This machine is a relatively new HP desktop and it exhibits exactly
> > the same symptoms w.r.t. the USB drives as I described earlier.
> >
> > 2. I booted the system with one of the drives connected and spinning,
> > so I could get the device description with usbconfig:
> >
> > ugen1.2: <USB to Serial-ATA bridge Sunplus Technology Inc.> at usbus1,
> > cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
>
> You can't ask the hanging device?
> It is bulk only so the command channel should be used for identification
> only.
>
> >   bLength = 0x0012
> >   bDescriptorType = 0x0001
> >   bcdUSB = 0x0200
> >   bDeviceClass = 0x0000
> >   bDeviceSubClass = 0x0000
> >   bDeviceProtocol = 0x0000
> >   bMaxPacketSize0 = 0x0040
> >   idVendor = 0x04fc
> >   idProduct = 0x0c15
> >   bcdDevice = 0xc683
> >   iManufacturer = 0x0002  <Sunplus Technology Inc.>
> >   iProduct = 0x0003  <USB to Serial-ATA bridge>
> >   iSerialNumber = 0x0001  <ST3320620N            5QF2ZMV8>
> >   bNumConfigurations = 0x0001
> >
> > If you dump_device_quirks, you find this entry, matching my hardware:
> >
> > VID=0x04fc PID=0x0c15 REVLO=0x0000 REVHI=0xffff
> QUIRK=UQ_MSC_NO_SYNC_CACHE
> >
> > So this device is known to the FreeBSD USB world. Unfortunately, the
> > built-in quirks in the kernel don't completely do the job. If you
> > google for 'freebsd sunplus', you turn up other people complaining
> > about the same issues I have. One guy even discovered, as I did, that
> > the drive works if it's present at boot-time.
>
> I've found others as well when searching for the error message.
>
> > 3. Plugging the drive into a self-powered USB hub and then
> > hot-plugging the hub into the computer doesn't help.
>
> This is unexpected :(
> So probably it really is the BIOS making the difference.
>
> If you stop at the loader stage, plug the device in and then start
> the kernel - will it change something?
> This way the BIOS won't see the device, but the kernel does.
>
> Will it help if you try usbconfig reset on the device?
>
> The feature to reset ports wasn't available with the old stack.
> It is just wild guessing, since I'm a bit out of ideas, but you
> could try UQ_MSC_FORCE_WIRE_BBB and UQ_MSC_FORCE_PROTO_SCSI, although
> the point that it works when already plugged in makes it unlikely.
>
> --
> B.Walter <bernd at bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>