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.
On Fri, Sep 24, 2010 at 11:35 AM, Bernd Walter <ti...@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
> > 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
> > 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 <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"