Hi,
> our research group is involved in building a large sensor node testbed, and
> we need to control the power supply of a number of USB devices by turning
> on/off the supply of the ports on the hub they are connected to. The hubs
> that we are using are DUB-H4, a self-powered 4-port USB 2.0 hu
Hi Fran,
> I have found on Kernel"s 2.4.27 (debian) 2.4.29 (mepis) and 2.6.10
> (mepis), when I try to transfer a large volume of files, with total size
> about 1G, the usb harddrive, gets reset, and goes off line.
just see this thread:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=1108935
Hi Alan & Dave,
> Just found out that we have a Adaptec-brand controller using a EHCI 1.0 NEC
> chip in one of the servers at work:
I've now bought an Adaptec AUA-3100. It uses a NEC D720101 which is EHCI 1.0
compliant. It looks much more solid than the cheap ALI and VIA cards I
previously trie
> Given that sort of issue, switching cables could matter too. Not
> all "old" cables are evidently capable of handling high speed
> signals.
That as actually one of the first things I tried when I encountered the
problems. I tried 5 diffent cables, all marked with "USB 2.0 compatible". 4
of th
Hi Alan,
> That could be another hardware problem. Are you using the ALI controller
> connected through an external hub? A number of other people have found
> they needed to that in order to fix a clock jitter problem in the ALI
> hardware.
I tried it with hub and without. Both times lots of re
Hi Alan,
> > But the disconnect looked different than without the patch
> > - without the device automatically reconnects with a
> > different id but it stayed disconnected this time. I don't
> > know if that is related to the patch or just luck - but I
> > have never seen a disconnect like this
Hi,
> > > Unclear. Did you say you'd tried this with a non-VIA controller?
> > > The VIA EHCI 0.95 has always been problematic.
> >
> > No, I do have 2 controllers here but both are VIA. If you say they are
> > problematic I'm now going to buy one that is not VIA and look if it is
> > working bet
Hi Alan,
> The tech support guy at Cypress wants to know which USB-IDE interface
> controller you are using. I told him the USB ID numbers, but he may need
> more information. Perhaps you can find a part number on the Cypress
> controller chip.
To get a view on the chip itself I have to dissect
Hi Dave,
> Smells to me like a non-EHCI bug; especially in that case.
where do you think the bug is - if not in ehci?
> But if you want to try a lower level patch, [1] might be
> of interest. The issue it's trying to address could kick
> in through usb-storage on systems with gobs of idle memor
Hi Samuel,
> When issuing a command which I knew produced the errors, I got the surprise
> to see that no usb reset happened when the transfers were made through the
> hub. I tested it several times, enough so that in the previous
> configuration it would have made at least an error, and nothing.
On Friday 04 March 2005 01:27, you wrote:
> On Thursday 03 March 2005 1:42 pm, Gerd v. Egidy wrote:
> > Hi Dave,
> >
> > > Smells to me like a non-EHCI bug; especially in that case.
> >
> > where do you think the bug is - if not in ehci?
>
> Unclear. D
Hi Alan,
> In your most recent tests, have you run across any more examples where the
> device got disconnected? Or did the hub driver patch fix that particular
> problem?
The backup ran a bit more than an hour until I got this:
usb-storage: *** thread awakened.
usb-storage: Command READ_10 (10
> > So in case of an error there are always 1011 bytes missing in the
> > transfer.
>
> In other words, two 512-byte blocks are missing and the 13-byte CSW is
> sent instead. Clearly this isn't directly related to the transfer length.
> And I don't see how it could possibly be caused by a problem
Hi,
> There's a description of max_sectors in the FAQ at www.linux-usb.org.
> Can you verify that it is still set to 240? Maybe something we're not
> aware of has changed it.
[EMAIL PROTECTED] cat /sys/block/sda/device/max_sectors
256
direct after plugging in. don't know where that comes from.
Hi,
I'm back from hardware-hell. I changed every part of the system (cpu, ram,
board, case/power-supply, pci-cards, disk, usb-frame,...), one at a time, and
the problem still persists. In the first email I reported that it ran on a
different system. I tried that again and now it is failing too
> I take back what I said earlier -- seeing why the port resets sometimes
> failed might indeed be useful. Can you duplicate the failure, but this
> time with CONFIG_USB_DEBUG set?
See my other mail.
> Also, I do have a patch that's been sitting around for a while, intended
> to fix a problem th
> > I'm going to play around with the hardware (case, power supply, cables,
> > other pci-cards, different processor,...) tomorrow.
sorry, didn't have time for that yet.
> > But for now I tried it with your patches (on top of 2.6.11-rc5).
> > I had to fiddle around a bit with them to make them ap
Hi,
> USB pen is not always detected. The device is found 1-3 times for 10 tries
> of connecting device to computer.
>
> The device is quite new, so I have not yet searched backwards for a kernel
> detecting it always, if there is any.
I got similar-looking problems with connecting my memory stic
Hi Alan,
> > Can anyone help making my backup reliable?
>
> This feels like a signal-quality issue. Maybe there's just more
> electromagnetic noise near the motherboard with the PIII processor, or a
> bad cable connection... Or maybe I'm totally wrong and the problem is
> something else entirely
Hi,
I use a usb-ide enclosure for backup. The enclosure has a cypress chip:
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=04b4 ProdID=6830 Rev= 0.01
S: Manufacturer=Cypress Semiconductor
S: Product=USB2.
Hi Alan,
> > I've got a usb pen drive and got problems getting it to work.
[...]
> You can try using this patch.
Thanks a lot, this patch did it.
Is this patch expected to be found in mainline in the near future?
Kind regards,
Gerd
---
SF
Hi,
I've got a usb pen drive and got problems getting it to work.
With Windows and 2.4 the drive works flawless but with 2.6.11-rc3 (vanilla)
I get the attached output (usb debuggin on).
The drive is a newer one from Sharkoon (if that helps).
It doesn't change anything if I try it on another po
> > Cool! I'll have to take a look soon. (And at the hub autosuspend
> > patch too...) It's bigger than I'd have expected. Care to sketch
> > what those three patches do?
>
> It's a little bigger than it needs to be, because I took the opportunity
> to reorder the #include lines in bunch of sou
> > You could try increasing the length of the delay that the patch adds to
> > transport.c. Make it 200us instead of 100us and see what happens.
>
> Ok, at first glance it looks like it's working with delay >= 350us
> (I tried 200, 600, 400, 300, 350).
> I can mount and have transferred some gigs
Hi Alan,
> > I still got problems with my Genesys USB-IDE converter after applying
> > Alans latest patch (max_sectors=64, 100us delay).
>
> I rather suspected it was too much to hope that the patch would fix things
> for everybody.
Thanks for still trying to come up with possible solutions...
>
Hi,
I still got problems with my Genesys USB-IDE converter after applying Alans
latest patch (max_sectors=64, 100us delay).
Sometimes it works and I can transfer 50G but sometimes it already fails on
mounting the 200G reiserfs partition.
If I use it not directly, but through devicemapper and d
26 matches
Mail list logo
