David Brownell wrote:
On Saturday 07 October 2006 12:47 pm, Alan Stern wrote:
We could in fact return an error code and _not_ accept the submission,
counting on the driver to realize what went wrong and make a new
submission. I think this is overly complicated. And it provides no hint
Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
Moreover, I found many usb input device driver do not call
input_free_device() at all,
Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
Moreover, I found many usb input device driver do not call
input_free_device() at all,
Christopher Monty Montgomery wrote:
On 10/9/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
Christopher Monty Montgomery wrote:
Hrm. that's non-atomic and as such involves a race and is not
reliable. Or am I missing something in the API? Does the xrun staus
persist until read?
The
Liyu wrote:
Hi.
In hid-input, It seem we only call input_allocate_device(), but not
call input_free_device() at anywhere. Is there a memory leak here? Even,
I can not found this invoke in drivers/usb/hid*.c.
I see. it is freed by input_class.release() method. So mysterious.
Hi All,
I am working on embedded OHCI USB host controller on which i am using
linux-2.6.14.
With Isochronous transfers after some time my board is getting hanged.
I observed that the TD Hash table is getting corrupted.
According to the OHCI Specification there is chance for 8 PSWs but in
the
-- Forwarded message --
From: Rupesh Kumar [EMAIL PROTECTED]
Date: Oct 10, 2006 1:37 PM
Subject: TD Hash table getting corrupted with Isochoronous transfers
To: [EMAIL PROTECTED]
Cc: linux-usb-users@lists.sourceforge.net, linux-usb-devel@lists.sourceforge.net
Hi All,
I am
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 9 Oct 2006, Christopher Monty Montgomery wrote:
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
So you're saying if the current uframe is N when you receive an URB whose
first slot belongs in uframe N+1, then you have to reject it,
On 10/10/06, Clemens Ladisch [EMAIL PROTECTED] wrote:
You could read the delay just after the write and check that it is at
least as big as the data you've written, but this can, of course, race
in the other way. (Well, you could think of that as a safety margin ...)
The race is more
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
The lengths of underruns are generally biased toward low numbers, right?
The most common length is 0 (no underrun), and the next most common is 1
slot.
I'm not actually sure of that.
Now I don't have hard numbers to support this, but I rather
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
It's amusing watching the two of you talk past each other... especially
in regard to issues of latency.
I'd have called it 'frustrating', but the discussion is at least still
moving forward.
Let's consider a simple case. Suppose we're using a
This patch (as798) adds a workaround to uhci-hcd. At least one Asus
motherboard is wired in such a way that any device attached to a
suspended UHCI controller will prevent the system from entering
suspend-to-RAM by immediately waking it up. The only way around the
problem is to turn the
On 10/9/06, Alan Stern [EMAIL PROTECTED] wrote:
Don't much like that one. Requires HCDs to record history that would
otherwise not be needed, and interrogate it.
I don't like it either; even less than #1. However Monty seemed to
mention it, so I brought it up for discussion.
If it turned
181 ULKEDE 8500 SEHIRDE 124000 OTEL DE SIZE ÖZEL FIYATLAR.
KURUMLARA , GURUPLARA ,SÝZE ÖZEL FÝYATLAR.
20-30 Ekim tarihleri arasýnda en az 5 gün konaklamalý
Alanya
5* Club paradiso pp AI 64,00 YTL
5* First Clas Hotel pp AI 55,00 YTL
5* Sunlife
This email lists some known regressions in 2.6.19-rc1 compared to 2.6.18
that are not yet fixed Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
This patch (as799) fixes a nasty refcount error in the USB endpoint class.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Greg, didn't you write this? Shame, shame... :-)
Index: usb-2.6/drivers/usb/core/endpoint.c
===
---
This patch (as800) straightens out the USB endpoint class device
creation routine, fixing a refcount bug in the process.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Index: usb-2.6/drivers/usb/core/endpoint.c
===
---
Greg:
I spent a lot of time debugging during the last two days. In addition to
various problems in the EHCI root-hub changes, there were nasty bugs in
the usbcore endpoint class device routines (patches submitted a few
minutes ago).
Here's the updated version of as738. As far as I know, the
On Monday 09 October 2006 9:44 am, [EMAIL PROTECTED] wrote:
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
On Monday 09 October 2006 9:11 am, [EMAIL PROTECTED] wrote:
FWIW, if we really could get 5ms latency with a 4ms buffering
requirement, that counts as 'good enough for now'
On Monday 09 October 2006 7:46 pm, Alan Stern wrote:
On Mon, 9 Oct 2006, David Brownell wrote:
I don't like the idea of having two separate pathways for reporting
the
same kind of error. If one reporting technique is reliable and
another
isn't, why keep the
On Tuesday 10 October 2006 1:07 am, Rupesh Kumar wrote:
According to the OHCI Specification there is chance for 8 PSWs but in
the driver we are using only 2 PSW.but my hardware is always doing
8PSW DMA Transfer there by hardware is overwriting the Software fields
sitting immediately after the
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
What happens if, when you're done filling, the clock is exactly at the
slot? Unless you wait for the clock to move past the slot, you can't know
whether or not the slot will end up being processed. But you can't wait
during a
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
We should do what makes the best balance of practical and semantic
sense. At best 'easiest' only factors into it.
So far we haven't settled on anything that is exactly correct. That's the
first consideration; only later should we
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
Let's consider a simple case. Suppose we're using a full-speed controller
instead of EHCI. It's easier to analyze and more demanding. Here's a
best-case scenario:
A. During frame 0 a pressure wave strikes the microphone.
On 10/10/06, Alan Stern [EMAIL PROTECTED] wrote:
So far we haven't settled on anything that is exactly correct.
Agreed.
In any case, missed slots do _not_ turn into delayed/out-of-phase data.
They are just missed, or as you say, pure dropouts.
You assume a single device at a time.
On 10/10/06, Alan Stern [EMAIL PROTECTED] wrote:
You're talking about detecting URB completion before a completion IRQ
arrives. In other words, polling. I would prefer not to see that added
to the HCDs, but it is a possibility.
Ah, EHCI (or USB in general) specifies a completion interrupt
On 10/10/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Ah, EHCI (or USB in general) specifies a completion interrupt happens
only at the end of a frame? I was suggesting the interrupt be thrown
as soon as the URB completes, even if that's mid-frame.
[I realize it's the HC
On Tue, 10 Oct 2006, David Brownell wrote:
On Monday 09 October 2006 7:46 pm, Alan Stern wrote:
On Mon, 9 Oct 2006, David Brownell wrote:
I don't like the idea of having two separate pathways for reporting
the
same kind of error. If one reporting technique is reliable
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
On 10/10/06, Alan Stern [EMAIL PROTECTED] wrote:
You're talking about detecting URB completion before a completion IRQ
arrives. In other words, polling. I would prefer not to see that added
to the HCDs, but it is a possibility.
On Tue, 10 Oct 2006 16:02:54 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
Ah, EHCI (or USB in general) specifies a completion interrupt happens
only at the end of a frame? I was suggesting the interrupt be thrown
as soon as the
This is a note to let you know that I've just added the patch titled
Subject: UHCI: workaround for Asus motherboard
to my gregkh-2.6 tree. Its filename is
uhci-workaround-for-asus-motherboard.patch
This tree can be found at
This is a note to let you know that I've just added the patch titled
Subject: [PATCH 2/2] usbcore: fix endpoint device creation
to my gregkh-2.6 tree. Its filename is
usbcore-fix-endpoint-device-creation.patch
This tree can be found at
This is a note to let you know that I've just added the patch titled
Subject: usbcore: fix refcount bug in endpoint removal
to my gregkh-2.6 tree. Its filename is
usbcore-fix-refcount-bug-in-endpoint-removal.patch
This tree can be found at
On Tue, Oct 10, 2006 at 11:55:47AM -0400, Alan Stern wrote:
This patch (as799) fixes a nasty refcount error in the USB endpoint class.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Greg, didn't you write this? Shame, shame... :-)
Ick, sorry about that. That's why I write opensource
On Oct 6, 2006, at 12:49 PM, Alan Stern wrote:
On Fri, 6 Oct 2006, Kumar Gala wrote:
Tried the device under Mac OS X and works fine. Any ideas on how to
debug what might be going on in Linux?
Did you try changing the value of USB_CTRL_GET_TIMEOUT?
Can you get hold of a USB bus analyzer?
On Tuesday 10 October 2006 1:20 pm, Pete Zaitcev wrote:
On Tue, 10 Oct 2006 16:02:54 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
On Tue, 10 Oct 2006, Christopher Monty Montgomery wrote:
Ah, EHCI (or USB in general) specifies a completion interrupt happens
only at the end of a
On Tuesday 10 October 2006 12:26 pm, Alan Stern wrote:
You're talking about detecting URB completion before a completion IRQ
arrives. In other words, polling. I would prefer not to see that added
to the HCDs, but it is a possibility.
Actually EHCI can and does run into a similar case,
This is the first time I've heard of that kind of hardware bug.
If it's always doing 8 transfers, despite being told to do only
one, that's pretty significant ...
Have you verified with the silicon vendor that this is what's
happening? And that they won't fix it?
I have verified with the
38 matches
Mail list logo
