Hello,
On 9/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 1 Sep 2005, Sven Duscha wrote:
>
> > Hello,
> >
> > I'm using a Cypress FX2LP EZ-USB development board to design software
> > for an USB2 Cy7c68013a-128 FX2LP chip.
> >
> > I got the device to work with the usbcore-driver and am no
Hi,
I have a problem with an eGalax touch screen controller connected on a
VIA UHCI controller together with my own hardware. Sometimes when I
disconnect my own device, the eGalax controller gets disconnected as
well and immediately re-enumerates. This leads to a new assignment of a
event number w
Hi Eric,
On Fri, 2004-11-05 at 07:36 -0800, Eric Blossom wrote:
> On Fri, Nov 05, 2004 at 10:44:36AM +0100, Axel Waggershauser wrote:
> > So, if the total throughput with 2 devices happens to be 32MB/sec as
> > well, I'd conclude that there is no controller available with a h
Hi Eric,
On Fri, 2004-10-29 at 12:51 -0700, Eric Blossom wrote:
> On Fri, Oct 29, 2004 at 01:06:34PM +0200, Axel Waggershauser wrote:
> > another question: Have you tried accessing two devices at the same time?
> > If so, what was your total throughput per sec?
> I haven
On Thu, 2004-10-28 at 13:25 -0700, Eric Blossom wrote:
> > I have to write a custom driver for a FX2 based camera module that
> > should be able to reach a bulk throughput of about 30 MBytes/sec from
> > the device to user space memory. The available CPU performance is less
> > than a 1GHz VIA EDEN
On Fri, 2004-10-29 at 19:33 +0200, Duncan Sands wrote:
> On Friday 29 October 2004 18:50, Johannes Erdfelt wrote:
> > Are you talking about exporting scatter-gather via usbfs? Or having the
> > kernel avoid a copy from userspace by using scatter-gather internally?
> >
> > The former might be usefu
Hi Eric,
another question: Have you tried accessing two devices at the same time?
If so, what was your total throughput per sec?
On Thu, 2004-10-28 at 13:25 -0700, Eric Blossom wrote:
> We built an FX2 based software radio peripheral and we routinely
> sustain 32MB/sec in either direction. CPU c
Hi,
On Thu, 2004-10-28 at 13:25 -0700, Eric Blossom wrote:
> We built an FX2 based software radio peripheral and we routinely
> sustain 32MB/sec in either direction. CPU consumption is minimal --
> on the order of 5% of a 1.4 GHz Pentium M. We did it all in user
> space using libusb, with an add
On Thu, 2004-10-28 at 16:18 -0700, Eric Blossom wrote:
> On Fri, Oct 29, 2004 at 12:27:45AM +0200, Oliver Neukum wrote:
> >
> > > We built an FX2 based software radio peripheral and we routinely
> > > sustain 32MB/sec in either direction. CPU consumption is minimal --
> > > on the order of 5% of
Hi,
I have to write a custom driver for a FX2 based camera module that
should be able to reach a bulk throughput of about 30 MBytes/sec from
the device to user space memory. The available CPU performance is less
than a 1GHz VIA EDEN. Is the libusb capable to provide this performance?
If not, I gu
On Wed, 2004-07-07 at 01:50, Pete Zaitcev wrote:
> On Tue, 06 Jul 2004 23:36:26 +0200
> Axel Waggershauser <[EMAIL PROTECTED]> wrote:
>
> > following problem: After several hours (>10) of continuous bulk
> > transfers from the device to the host, I get a completi
Hi,
I have a self-made USB device and a self-made driver (the same camera
system I talked about several times already) and discovered the
following problem: After several hours (>10) of continuous bulk
transfers from the device to the host, I get a completion call with an
URB status == -84. The co
On Tue, 2004-02-17 at 22:07, Alan Stern wrote:
> The problem of the URB not completing right away will get solved in time.
> There are several other changes to the driver that need to be made first.
OK, I'll hang on...
Thanks,
Axel
---
S
On Tue, 2004-02-17 at 17:31, Alan Stern wrote:
> Did the debugging log end up looking exactly the same as last time?
No it didn't, the difference was that my completion handler used to be
called with the urb->status == 0. After I applied the patch it got
called with urb->status == -108. Besides th
On Mon, 2004-02-16 at 18:30, Alan Stern wrote:
> Axel:
>
> Your problems have been among the most puzzling I've seen... :-)
> You might try this patch:
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107671082606352&w=2
>
> I think it will help solve one of your problems.
[...]
> > 16:45:34:
On Sun, 2004-02-15 at 17:26, Alan Stern wrote:
> On Sun, 15 Feb 2004, Axel Waggershauser wrote:
> > Well, it did not solve my problem... The workaround was applied (showing
> > "VIA UHCI babble workaround applied" in syslog) but seemed to have no
> > effect.
>
Hi Alan,
you didn't explicitly say so, but I hoped your patch might solve my
problem (the controller seems to disable itself after unplugging my
device with a pending bulk urb). I hoped so, since the symptoms seem to
be same (no interrupt from the controller, subsequent enumerations time
out, a re
On Mon, 2004-01-26 at 17:18, Alan Stern wrote:
> Let me see if I understand this. If you plug in your device, run the
> test, and unplug it then your driver works okay and the outstanding URB is
> unlinked. But then the next time you plug anything in, even the mouse, it
> fails to enumerate.
On Fri, 2004-01-23 at 17:26, Alan Stern wrote:
> On Fri, 23 Jan 2004, Axel Waggershauser wrote:
>
> > - with your patch the urb gets unlinked when the controller suspends,
> > that happens about a second after the unplugging.
>
> So now that part works and your driver, e
On Fri, 2004-01-23 at 15:55, Alan Stern wrote:
> > The patch works ... sort of (:-)). It seems to effectively prevent the
> > urb-gets-not-unlinked problem. But on the other hand, it has the same
> > problem than my mentioned panic workaround. In my case the urb gets
> > dequeued when the resume in
On Wed, 2004-01-21 at 23:25, Alan Stern wrote:
> > It is attached. There are quite a lot non-problematic URB's to and from
> > the device before the interesting part begins. I need those to set up my
> > device.
>
> What are those "disable" messages?
hcd_endpoint_disable()
> Basically there are
Hi Alan,
On Thu, 2004-01-22 at 22:42, Alan Stern wrote:
> On Thu, 22 Jan 2004, Axel Waggershauser wrote:
> > I observed the transitions 1->0, 2->0, 3->0, 36->32 and 32->32.
>
> I made the same test on my computer and got the same result. Apparently
> this is
On Wed, 2004-01-21 at 23:25, Alan Stern wrote:
> > It is attached. There are quite a lot non-problematic URB's to and from
> > the device before the interesting part begins. I need those to set up my
> > device.
>
> What are those "disable" messages?
hcd_endpoint_disable()
> Basically there are
On Tue, 2004-01-20 at 22:01, Alan Stern wrote:
> If you unplug (without running the test) and wait for the controller to be
> suspended, does uhci_irq get called right after the suspend_hc message?
No.
> Doesn't urb_dequeue call set_next_interrupt?
Yes, it calls set_next_interrupt.
> If it does
Hi,
here is some additional insight:
I worked around the panic by modifying my drivers completion function to
no call complete() if the device has been removed. That means I can
replug the device now without the panic. Log when I replug now looks
like that:
Jan 20 13:28:47 koffer kernel: uhci_ir
On Mon, 2004-01-19 at 22:46, Alan Stern wrote:
> On Mon, 19 Jan 2004, Axel Waggershauser wrote:
>
> > Summary:
> > - My desktop machine sort of works, as long as I listen to music :-).
> > - None of my machines show any interrupt calls after the controller
On Mon, 2004-01-19 at 17:52, wwp wrote:
> If your usb controller module is loaded by hotplug at startup, you could
> prevent him from loading a buggy module, simply adding the module name
> to /etc/hotplug/blacklist.
> Also see the hotplug init.d script you may find comments related to this.
No, t
On Mon, 2004-01-19 at 16:53, Alan Stern wrote:
> It's possible those interrupts were generated by another device sharing
> the IRQ line. If that happens when the controller is suspended, I'm not
> sure if the status should be 0 or 32. I'll have to recheck the
> specification.
Meanwhile I found t
On Sun, 2004-01-18 at 23:38, Alan Stern wrote:
> You can selectively ignore that controller in your debugging messages
> simply by checking the value of io_addr (or uhci->io_addr).
Isn't it possible to somehow really disable it, as if I disabled it in
the BIOS. Or tell the uhci-hcd module to just
On Fri, 2004-01-16 at 22:51, Alan Stern wrote:
> I still don't understand those 32's. They don't occur on my computer.
> If you look at uhci_irq() you'll see that unless uhci->state is <= 0,
> status = 32 (= USBSTS_HCH) should trigger a rather ominous "host
> controller halted. very bad" message
Hi,
unfortunately I had to realize that the "buggy" machine, the one which
is actually of interest here, has no BIOS option to disable a single USB
controller. So I am back where I started (see below).
Thanks,
Axel
On Sun, 2004-01-18 at 20:57, Axel Waggershauser wrote:
> Hi again,
On Fri, 2004-01-16 at 19:42, Alan Stern wrote:
> Let me attempt to duplicate your experiments on my system. I've got a
> device that can be set up to delay responding to a bulk message (was your
> URB bulk or control? -- I forget) and I will unplug the cable during that
> delay and see what happen
Hi again,
just as I pressed the send-button there came a thought to my mind: THE
BIOS. OK, next time I try to think a little longer before I send
emails...
Axel.
On Sun, 2004-01-18 at 20:51, Axel Waggershauser wrote:
> Hi,
>
> I am currently trying to debug the uhci controller dri
Hi,
I am currently trying to debug the uhci controller driver which seems to
behave strange on one of my test machines (see the thread
"usb_submit_urb -> unplug -> timeout -> replug -> kernel panic"). Now I
found that at least some of this observed "misbehaving" is perfectly
explainable with the f
On Sat, 2004-01-17 at 01:51, Greg KH wrote:
> Hm, the patch doesn't apply. Care to resend it without the tabs
> stripped?
>
> thanks,
>
> greg k-h
No problem... hope that's better.
Axel.
--- linux-2.6.0/drivers/usb/usb-skeleton.c 2004-01-18 19:23:46.0 +0100
+++ linux-2.6.0-fixed/driver
On Thu, 2004-01-15 at 17:20, Alan Stern wrote:
> > So I guess that is bad (meaning the hardware is buggy?).
>
> I would hesitate to make that conclusion, but it's certainly a
> possibility. The best test would be to try running your driver on a
> different computer.
I don't know why I didn't h
On Fri, 2004-01-16 at 00:23, James Courtier-Dutton wrote:
> Do you have "hotplug" installed?
No.
> I find that "hotplug" causes problems with plug/unplug/plug of usb audio
> devices, so it might also effect you.
I don't think so, thanks anyway.
Axel.
Hi,
I organized a hub and tested how the machine behaves if I connect the
device to the hub. It behaves different than without the hub. I get no
disable_endpoint calls and (maybe therefore) _no_ uhci_urb_dequeue calls
for my URB. After my wait_event times out (about 3 seconds later), I
call usb_un
On Thu, 2004-01-15 at 17:20, Alan Stern wrote:
> > So I guess that is bad (meaning the hardware is buggy?).
>
> I would hesitate to make that conclusion, but it's certainly a
> possibility. The best test would be to try running your driver on a
> different computer.
As mentioned in one of my f
On Wed, 2004-01-14 at 22:53, Alan Stern wrote:
> I'm not sure. uhci_set_next_interrupt makes a trivial change to a data
> structure which should cause the controller to signal an interrupt at the
> end of the current or next frame. That change is undone by
> uhci_clear_next_interrupt. You could
Hi,
I sent this mail already yesterday but didn't receive it
on the list so I guess something went wrong. Sorry if someone
receives it twice.
On Tue, 2004-01-13 at 21:31, Alan Stern wrote:
> I assume you verified that when uhci_urb_dequeue() gets called, it is for
> _your_ URB.
yes.
> The unli
On Tue, 2004-01-13 at 16:36, Alan Stern wrote:
> > I still have these printks in giveback() and found to my surprise that
> > this function gets called repeatedly for an other urb with a frequency
> > of about 4/sec. This starts about the same time the unplugging is
> > detected, that means shortly
On Tue, 2004-01-13 at 05:20, David Brownell wrote:
> Neither; for now, disconnect() should wait until all the urbs complete.
> Definitely no timeout.
I patched my driver to use asynchronous unlinking and to
wait_for_completion() for the unlinked URB. There are two places now
where I do that. First
On Tue, 2004-01-13 at 03:14, David Brownell wrote:
> Somewhere there's a patch floating around which makes UHCI wait
> for those URBs to complete too. Lacking that patch, you need to
> do what all robust USB drivers have always done: wait for all
> their urbs to complete.
Should I wait with a ti
On Mon, 2004-01-12 at 23:38, Alan Stern wrote:
> Try adding some printk's to the giveback_urb routine. That will at least
> tell you if the URB is getting stuck in the controller driver or somewhere
> else. You can also try adding some printk's to hcd_endpoint_disable()
> also in the hcd.c sou
On Mon, 2004-01-12 at 19:43, Alan Stern wrote:
> On Mon, 12 Jan 2004, Axel Waggershauser wrote:
> > ...so far so good...
>
> Not really... Your completion routine should get called as soon as the
> "USB disconnect" message appears in the syslog. Below you said t
Hi,
I am still working on my driver for our proprietary usb-device. I get a
kernel panic under the following condition:
1. usb_submit_urb // bulk in endpoint, urb with usb_complete_t set
2. wait_event_interruptible_timeout // about 3 seconds timeout
3. unplug the device
-> I see "usb 1-2: USB
Hi,
On Wed, 2003-12-31 at 12:12, Martin Diehl wrote:
> IIRC I've seen something similar when I tried to push bulk bandwidth to
> the limit with usb-uhci (long ago...). It turned out big transfers were
> suffering from the FSBR-timeout. About 50 msec after submitting the urb
> the HCD assumed th
Hi,
I've been away for new years eve, therefore the delay... I try to
answer/comment all mails you sent me on this subject.
> Try using a non-UHCI controller.
Well, I would if I had one. But even if so, it would not solve my
problem since the 'target' hardware in question has a uhci controller.
Hi,
I have a problem with inadequate throughput when submitting bulk urbs
with transfer buffers greater than about 128kB. I have written a simple
usb driver to access our proprietary device. The device has a "testing"
mode, in which it dumps data to its 64 byte bulk endpoint as fast as I
can trans
On Wed, 2003-12-17 at 19:06, Alan Stern wrote:
> On Wed, 17 Dec 2003, Axel Waggershauser wrote:
>
> > Hi,
> >
> > I was about to write a usb driver (port my old one) based on the
> > usb-skeleton.c example in the 2.6.0-test11 source. I either found a bug
> >
Hi,
I was about to write a usb driver (port my old one) based on the
usb-skeleton.c example in the 2.6.0-test11 source. I either found a bug
or overlooked something...
The problem occurs in the following scenario: some usb-device is plugged
in, two clients open the corresponding file, the device
52 matches
Mail list logo
