Also, I haven't made one point clear-- the fact that Jon isn't doing
or asking for anything unreasonable, just that the hidden layers of
complexity make delivering upon the request more deifficult than is
obvious from the outside.
The logs Jon has sent have already indicated the 100% certainty of
On 12/22/06, Jon Smirl [EMAIL PROTECTED] wrote:
I did some more experiments. If my FS LIRC device is the only thing
plugged into the USB 2.0 hub it works. If also seems to work when
mixed with HS and other FS devices.
If I plug in my LS keyboard it stops working.
Something isn't quite right
On 12/22/06, Jon Smirl [EMAIL PROTECTED] wrote:
As for the symptoms, calls that work for reading/writing under USB 1.0
are succeeding without error, but they don't return any data,
...the logs you provided indicate there is an error (specifically 'not
enough bandwidth'). Either a driver is
Further looking at the logs...
The problem with that low speed device is that it places a giant
boulder in the middle of the only place QHs can reasonably go in the
compatability bandwidth schedule; the budgeting code is only capable
of packing so many smaller pebbles around it. QHs are severely
On 12/22/06, Jon Smirl [EMAIL PROTECTED] wrote:
Hub is a Dlink DUB-H7, it is current, shipping product from Dlink.
http://www.dlink.com/products/?sec=0pid=149
yes, single-TT.
This fails even when I am not typing and using the mouse.
Any device on the USB periodic schedule is always holding a
Well known issue; the 'stock' ehci scheduler is not efficient enough
using hub TT bandwidth to allow many audio devices to work through a
2.0 hub.
The -mm kernel series has a new, experimental scheduler in testing for
eventual mainline deployment that should allow all full-speed (USB
1.1) devices
On 12/19/06, Jon Smirl [EMAIL PROTECTED] wrote:
That's a pretty bad scheduler if it can't schedule a single 12Mb
device on a 480Mb hub.
It's only sharing the hub with a USB keyboard. The audio being sent to
it is less than 1Mb.
That's not the problem; it has trouble scheduling the bandwidth
On 12/19/06, Jon Smirl [EMAIL PROTECTED] wrote:
I was giving the hub more credit than it deserved. I thought it was
doing store and forward so that it was talking 480Mb to the PC and
then 1Mb, 12Mb or 480Mb to the peripherals.
It is, but it makes none of the timing decisions itself. This
On 12/5/06, David Brownell [EMAIL PROTECTED] wrote:
Which is further evidence that the bottleneck is either in the mass storage
protocol (it has no pipelining) or in the peripheral silicon ... since the
disks themselves are often capable of more than 50 MB/sec.
For short bursts, perhaps, but
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 10/9/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
We will still run
into rebudgeting problems int he case of XRUN though, and we will
still run into the problem of an app running happily for several
hours, having an inadvertant XRUN and suddenly throwing 'ENOSPC'.
Throwing
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
The gap is inherent in having let the stream empty. Once that happens,
given IRQ latencies there aren't many good controls over how much of
a gap exists. The original notion of SLOP would not have kicked in
there ... if your patches added
On 10/9/06, David Brownell [EMAIL PROTECTED] wrote:
Really? With URBs having 1 uframe periodicity?? I doubt it.
Maybe with ones having 1 frame (8 uframe) periodicity; in those
cases the system will often be fast enough.
Ah, no, one frame (8 uframe), not one uFrame.
Monty
FWIW, if we really could get 5ms latency with a 4ms buffering
requirement, that counts as 'good enough for now' and probably 'good
enough for the forseeable future'.
Monty
-
Take Surveys. Earn Cash. Influence the Future of
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' and probably 'good
enough for the forseeable future'.
5 ms
On 10/9/06, [EMAIL PROTECTED] [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' and
On 10/8/06, Christopher Monty Montgomery [EMAIL PROTECTED] wrote:
Right now, that attempt would be outright rejected. ehci-sched will
not (and never would) schedule into the currently active frame. In
fact, it would not schedule into any frame within 'SCHEDULE_SLOP' of
the active frame. I
17 matches
Mail list logo
