> * Is the ADS USBx-2020 supported? And if so: anyone has experience?
I contacted the manufacturer a while ago, and the reply was that there
are no plans to add Linux support. It uses a very different protocol
from the ibot2.
Both cameras are also sold in IEEE 1394 versions. If you just want to
> > Ah, OK. I used the 1.5k resistor, no external transistor. I don't know
> > what the actual cause was, but it looks like the DISCON pin never went
> > floating or didn't have sufficient impedance for a USB disconnect to
> > occur. The guys at Cypress recommended setting both DISCON and DISCOE
>
Martin,
> Hi Andreas,
(Just nitpicking, my name is Andras, as in Andr\'as (TeX syntax).)
> As you discovered it, would you mind to explain? My understanding was the
> DISCON pin would float pretty long at H (maybe due to some similar
> soft-pullup like they have on the ports) so it is require
Martin,
> Ok, here we go. Attached the EZ-USB firmware release providing own
> descriptors, EP0 standard requests and bulk sink/source support. Ready for
> AN213x and FX - but not (yet) FX2. Successfully tested with ehci-hcd
> and usbtest - as shown in the other mail it passes all current tests.
This is not a USB problem, and not linux in any case, but anyway:
> In assembler works only lighting on
>
> mov OEE,#1110b ; setting pin 7 6 5 of port E as outputs
> orl IOE,#00011000b
> anl IOE,#0111b; lighting on 3 LEDs
Your code will set IOE.7 to IOE.5 to 0. This will provide a
> In itself that timeout isn't necessarily bad, but in practice it usually
> seems to indicate a problem with EHCI. More extensive debugging
> information would help here. If it's not a host controller problem then
> we should be able to recover from the error. But without knowing what the
>
Marcelo,
First of all: what device is this? Did you build and program it
yourself? What USB chip does it use?
What other operating systems does this device work with? Did you write
the drivers yourself?
It's hard to say anything useful without these bits of information.
Andras
> It wouldn't be surprising if the file that cp hung on was the same one
> that generated those usb_bulk/control_msg timeouts in the previous set of
I did a simpler version of what you told me, and it's the file
/sys/devices/pci0/00:09.2/usb5/5-1/product
that hangs. I can still read any oth
Sorry, pressed the wrong button at the wrong time. Here is the sysfs
tarball.
Andras
===
Major Andras
e-mail: [EMAIL PROTECTED]
www:http://andras.webhop.org/
> It wouldn't be surprising if the file that cp hung on was the same one
> that generated those usb_bulk/control_msg timeouts in the previous set of
I'll try to reproduce that behaviour in a moment, but first I have
some more news: I borrowed an NEC-based USB 2.0 PCI card today, and
the USB HDD
> > The sd_mod module is loaded automatically on boot. I find that when
> > sd_mod is loaded at the time the USB drive is plugged in, the kernel
> > doesn't find the partition table (fdisk claims it's blank), and any
> > attempt to unload sd_mod segfaults. I had to unload the module before
> > plu
> [ 2.5.70 + ehci-0613 patch, log output sent, "Subject:" wrong ]
>
> Just to summarize for the peanut gallery: the logs showed no
> problems at all ... until the PCI files spontaneously vanished
> from sysfs. That's not allowed to happen, something's deeply
> wrong outside USB on that system i
> Add ehci-0613 and send the logs + sysfs output on 2.5 ... the
> diagnostic info in sysfs changed slightly, it should show a
> few things that weren't previously visible.
OK, I've run ehci-0613 on top of 2.5.70-bk9. This is with a VIA EHCI
(PCI device ID 0x8080, unknown to the kernel). The USB d
Correction:
> doesn't find the partition table (fdisk claims it's blank), and any
> attempt to unload sd_mod segfaults. I had to unload the module before
^
Sorry, this should read "causes an oops".
Andras
> The last 2.5 patch was ehci-0612, and it had key differences
> from 0609 that affected problems I saw on NEC hardware, which
> you were using. (You never tested 0610...) Attached, you'll
> see ohci-0613, which should be just 0612 with that relink fix.
I'm confused -- what does this have to do
> This patch brings the 2.4.21-rc8 EHCI driver mostly back
> into sync with the latest 2.5 driver (*), and adds a patch
> to avoid a relink problem (symptoms: rx hang, tx overflow)
> which causes trouble on 2.4 (especially with usb-storage).
Just tried (patched 2.4.21 with it) with the hard drive
Norbert,
> Do you have any examples of programs for Cypress FX2 ? I have to write a
> code using this chip for aquisition date from ADC ...
Which side are you interested in, the firmware, or the linux driver
side? I'm using an FX2, maybe I can give you some help.
Andras
=
David,
> Here's a patch that resolves a regression I've been chasing
> for a while ... it may address other issues too, which is
> why there's a CC list.
I've applied this to 2.5.70-bk8 and see no change in the behaviour at
all. I haven't looked closely, so please let me know if you want
another
Alan, David, everyone else who might be able to help,
I've just caught an oops that seems to come from the EHCI code. This
happened while trying to communicate with my own USB 2.0 device (based
on the Cypress EZ-USB FX2), under vanilla 2.4.20. The device was
connected through a USB 2.0 hub (NEC c
> Andras, if you notice distinct pauses, and this is on 2.5 (seems to be),
> then there's more information available. Basically, the sysfs files
> for EHCI (enabled with CONFIG_USB_DEBUG) may have relevant information.
Yes, it's 2.5.70-bk8.
> Make sure you're running a kernel with the kernel ha
> Maybe the best thing to try would be to repeat that test, but with more
> debugging output. Do you think you can insert
>
> printk(KERN_INFO "%s %d\n", __FUNCTION__, __LINE__);
>
> statements at various judicious places in the usb_physical_reset_device()
> function near the end of dri
> Interesting. This log shows no errors at all. It's got a couple of reads
> followed by 12 writes, and they all completed successfully. Judging from
> this, I would say that the problem must lie somewhere else, not in the USB
> driver.
Interesting...
> I don't understand why the same test sh
> Yes, it would be worthwhile to see if the debugging messages are any
> different with the device attached directly to the computer. From the log
> you sent yesterday, it was faintly possible that the problem lay in the
> intermediate hub. Though I can't imagine how.
OK, here we go. The dri
> By the way, Andras, was the device plugged directly into your computer's
> USB port or did you use an intermediate hub?
It was plugged into a USB 2.0 hub, but behaviour is exactly the same
when it's plugged in directly (well, maybe there is less stuff in the
logs, I haven't tried). Let me know
> Can you send any debugging log information? Either USB debugging or
> usb-storage debugging. The little bit shown here doesn't say anything
> about what went wrong or how the kernel tried to fix it.
OK, here we go. I put in blank lines to make it clear where a
noticable pause occurred.
> J
> I mean 2.5.71 (although usb-2.5.70.bk-patches* will probably do just as
> well -- and I think you do need both). You can get 2.5.70 at
> ftp.kernel.org, and the combined patches up to the current 2.5.71 are in
> the pub/linux/kernel/v2.5/testing/cset directory.
I couldn't make sense of the cset
> > We don't have testing feedback from that new 2.5 code yet.
> > Yes, maybe it'll help us get a better handle on what's
> > going on in the earlier stages.
>
> Indeed. Andras or Mitch, please let us know when you've had a chance to
> try the new version of the USB drivers (as of Monday June 2
Dave,
> Are you sure nothing interesting happened earlier? I
> recognize that usb-storage doesn't normally tell you
> when things go strange ... and storage debug messages
> give so much data that they change i/o timings in
> significant ways, hiding bugs.
Yes, the previous message in all logs
Hi,
I can see in the archives that a problem with the USB storage driver
has been discussed recently. I just got a USB 2.0 hard drive enclosure
(made by a company called Anydisk), and it works out of the box with
the usb-storage driver off all USB hosts I have tried so far (EHCI on
a VIA chipset,
29 matches
Mail list logo
