Date: Fri, 24 Sep 2010 01:50:16 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Donald Allen <donaldcallen@gmail.com> Cc: ticso@cicely.de, freebsd-usb@freebsd.org Subject: Re: USB drives still don't work correctly Message-ID: <20100923235016.GH2846@cicely7.cicely.de> In-Reply-To: <AANLkTimJkfqiOM0=Vm1wB_7ADtjrsgVsG6f=QqFPitPx@mail.gmail.com> References: <AANLkTimkzMiGCvu256tUR3ZUrantNQjXGTcSCvxFX5eL@mail.gmail.com> <201009230834.12501.hselasky@c2i.net> <AANLkTinaf9bg=pGSwGtiSr08HAtguFpWriLYEqL%2BF4J=@mail.gmail.com> <20100923155948.GC2846@cicely7.cicely.de> <AANLkTim8UEQmVkC_TzE8y8gOY%2BfLq2n51bkiDAQBzqm2@mail.gmail.com> <20100923191256.GE2846@cicely7.cicely.de> <AANLkTimJkfqiOM0=Vm1wB_7ADtjrsgVsG6f=QqFPitPx@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 23, 2010 at 07:01:38PM -0400, Donald Allen wrote: > On Thu, Sep 23, 2010 at 3:12 PM, Bernd Walter <ticso@cicely7.cicely.de> wrote: > > On Thu, Sep 23, 2010 at 01:15:15PM -0400, Donald Allen wrote: > >> On Thu, Sep 23, 2010 at 11:59 AM, Bernd Walter <ticso@cicely7.cicely.de> wrote: > >> > On Thu, Sep 23, 2010 at 11:07:59AM -0400, Donald Allen wrote: > >> >> On Thu, Sep 23, 2010 at 2:34 AM, Hans Petter Selasky <hselasky@c2i.net> wrote: > >> >> > On Wednesday 22 September 2010 18:03:11 Donald Allen wrote: > >> We don't live in an ideal world and not every device implements the > >> specs correctly. Apparently there are enough devices like mine out > >> there that Linux and OpenBSD have found a way to make them work. It's > >> sometimes not a winning strategy to insist on absolute adherence to a > >> protocol -- Opera tried that with their browser and look at their > >> share of the desktop market. It can be a bit like having "I had the > >> right of way" on your tombstone. > > > > Yes - that point has something in common. > > People expect crappy webpages to work and people expect crappy hardware > > to work. > > Yes, except that "people" don't know that the stuff is crappy. For That;'s unfortunately true and that's the reason why vendors often don't care to fix that problem. > example, Opera used to explode when pointed at wsj.com. They (the > Opera apologists) claimed that wsj.com was violating whatever version > of the html protocol was current at that point. I could not have cared > less -- I just wanted to read the Wall St. Journal. So I used Firefox, > which worked fine. > > > But FreeBSD is not an OS which trades working with crappy hardware at > > the cost of not using important features with working devcies. > > Windows for example handles USB disks completely different than SATA > > just becasuse it assumes people might disconnect it at any time. > > They only do a cache flush in the device clicked for being disconnected > > and if the device hangs on that command - well - the user is about to > > disconnect it anyway. > > That's a fair point. If you have to penalize using the good devices > well in order to support the non-compliant ones, then I agree with > you. But I would think that heuristics should be possible such that if > a non-compliant device behaves oddly in response to an aggressive, but > legal, command sequence, then the system could back off and try again, > using a more conservative, lower performance approach that works, and > note that it is doing so in the system log. Sometimes it is possible, but with umass devices I've often seen that devices hang in a way where only a power cycle can get them back to business. > >> so they likely have bigger > >> > quirk tables - with OpenBSD - well either it doesn't use the broken > >> > feature at all or they are already stumbled over the problem by luck. > >> > I've never seen a Sunplus USB mass storage device so far and I've seen > >> > a lot. > >> > The FreeBSD driver likely isn't at fault, since it works with so many > >> > non-broken devices. > >> > For me it looks like the device is just hanging on a command, which > >> > would be clearly against specification. > >> > I've seen so many creative firmware bugs in USB devices that I don't > >> > easily trust any of them. > >> > Fortunately most vendors have learned their lessons, so that more > >> > recent devices are less error prune. > >> > >> Whether my hardware is "crappy" or not (and you may well be right > >> about that -- these shoeboxes are a few years old), there's still the > >> issue that the drives work correctly with FreeBSD when present at > >> boot-time, but not when hot-plugged. I would think the handshake with > >> the drive would be the same in either case, so either I'm wrong or > >> there's a bug. > > > > Yes - the handshake should be the same, but the drive state is not. > > So it is just when hot-plugging the device and not when booting connected? > > Yes. > > > Probably it just hangs if asked before the media has spun up, which is > > likely the case when it had power long time before. > > Or has the device an external power source and is already rotating before > > plugged in? > > The device has its own power supply and the disk was up to speed and > settled long before I hot-plugged it (also when I plugged it into the > system prior to booting it, so in the same state in both cases, but > very different outcomes). So your "in the process of spinning up" > theory does not apply in my case. Ok - it is not spinning up, but there is still another point. An USB device is required to follow bus power even it is self powered. The reason is that an USB device pushes current into the bus and if it is connected to a powered down host it is forbidden. A pullup resistor of 1.5k is used to notify the host about existence. Once a device sees USB power it is allowed to suck a certain low current for a short time. A self powered device usually only senses the buspower, but the chip in your device may be used for both modes, so it has to be strict on timing, although almost no host really cares about this. A device enables it's pull-up and this has to be done within a short time because it is not allowed to suck current from the bus for a long time. Once the pullup is enabled the host gets informed by the hub port that there is a new device and it can enable the hub port at any time to communicate with the device at address 0 under which - because many devices are buggy - it can only setup the final address. So the difference in timing is that in one case the device sees power, enables the interface and the host directly tries to get the device up within short time. In the other case the host takes a long time until it comes to the device. Another point is the regular framing signal a device sees. Once again the device has to settle down if framing signal is missing, which means a host is in suspend mode and the device has to go to suspend as well. Bus power can still be available for standby purpose or because the port can't disable the power at all, which is very common. I think the device won't see framing signals until the host enables the port, so this shouldn't influence any further. > >> If you think a command is hanging, can you suggest a quirk or subset > >> of the 48 to try that might cure the problems in the hotplug case? > > > > Unfortunately not. > > Maybe you have a chance to find out via cam debug which command it > > has problems with, but I'm not familar with it's use, since I never > > needed it myself. > > I probably will not bother with this on my own. Unless you guys are > willing to work with me to understand what's going on here and whether > it's fixable either on my end or in the driver, I will have to make my > decision about use of FreeBSD knowing that I can't rely on > hot-plugging these USB drives for backup. If I can reliably talk to > the drives by having them connected at boot-time, that might be good > enough. I'll have to get more experience with the rest of the system > to see if it's worth this compromise. Surely there is a way to get it working since it works with other OS and the device gets probed fine from the USB standpoint, so everything works to setup quirks - I'm just don't see anyexisting to fit my assumptions. As a test you can try to connect the device to an self powered USB hub and the last port. Then connect the whole hub to the host. In this case the device will see power before being connected as most hubs don't switch their power power output. If it doesn't work you can connect other devices to the other ports, then the host will take care about the other devices first. There is also another difference. If you boot with an USB device connected likely the BIOS already has spoken with the device. -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100923235016.GH2846>