I could find a couple references to "Error: No open pipes". This is one
of them.
http://www.usb.org/phpbb/viewtopic.php?t=12633
Pipes and endpoints are shown in this figure.
http://upload.wikimedia.org/wikipedia/commons/1/1b/USB_pipes_and_endpoints_(en).svg
USB protocol is polled, and pipes are the unidirectional virtual links established
for communication purposes. These pipes allow sending messages and getting
responses, from subtending devices. If you add external USB hubs for example,
then the host controller can talk to the USB hub itself as a target, or the host
controller can also talk to things on the other side of the USB hub. Each target
has a separate logical pipe, for communications.
To me, all this means, is initial communications with the device, failed
to work properly. You've already reports, that unplugging and replugging
a USB hard drive, got it to be detected. So there is something wrong
with the initial communications.
Since I don't know the failure mechanism, it would be hard to guarantee
a fix with some added or changed hardware. Some older desktop motherboards
(DIY constructed computers) have a jumper that selects between +5V and
+5VSB feeding the USB ports. For systems that have trouble waking up
properly and doing the right thing, a limited number of them get
relief by using +5VSB. But the Dell is not likely to make this an
option, because prebuilt computers are not a good place
to be using jumpers.
Installing a separate USB2 PCI card, is another experiment that a
person could carry out. But those don't necessarily offer options
for determining how the bus is powered, and the initialization procedures
really shouldn't be any different (or better). That is because, the
same Microsoft driver will control the timings, the number of bus
resets delivered and when, and so on.
Using an external USB hub can also sometimes make a difference for the
better (or for the worse). Some have their own power supply, and the
idea there would be that the connection between the external hub and
the errant device, remains powered all the time. Again, that might
affect the initialization process, but only in the sense that there
is no delay waiting for the peripheral's interface to get powered.
So you can mess around with how the device gets connected, but as
we aren't using a USB protocol analyser here, there really isn't a
way to determine how communications is failing.
I had to laugh, when I booted my system with my Knoppix Linux CD,
and I had my USB ZIP250 connected (and the ZIP250 has its own power supply),
Linux said "allowing extra time for USB devices" or some such.
So somehow, it decided I was using USB devices (it probably figured
that out pretty quickly), and rather than rush things, allowed a bit more
time, before probing all USB ports again. So someone was
hedging their bets. Really silly in a way, because the protocols
used should really be bulletproof. (I.e. You should *eventually*
be able to establish communications with a USB device, and a driver
that isn't greedy in that regard, is really a poor candidate as
a solution you can rely on. Only taking one shot at it, and falling
over dead, is not much of a solution.)
Paul
