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 Fri, 22 Dec 2006, Jon Smirl wrote:
> On 12/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 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=0&pid=149
> >
> > yes, single-TT
Attached is lsusb -v for about half of the USB devices I own.
Bus 005 Device 003: ID 2001:f103 D-Link Corp. [hex]
Bus 005 Device 010: ID 0471:0155 Philips
Bus 005 Device 007: ID 05a9:8519 OmniVision Technologies, Inc.
Bus 005 Device 006: ID 0ace:1215 ZyDAS
Bus 005 Device 004: ID 0471:0815 Philips
Tom's article explaining the single/multi TT difference:
http://www.tomshardware.com/2003/09/09/usb_technology/index.html
--
Jon Smirl
[EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge
On 12/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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=0&pid=149
>
> yes, single-TT.
>
> > This fails even when I am not typing and us
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=0&pid=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 hold
Hub is a Dlink DUB-H7, it is current, shipping product from Dlink.
http://www.dlink.com/products/?sec=0&pid=149
The low speed device is a Logitech wireless keyboard/mouse combo.
This fails even when I am not typing and using the mouse. I stop doing
that while I unplug the device and plug it back
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:
> 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
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 qui
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 with the mm ehci scheduling code yet.
--
Jon Smirl
I turned on verbose scheduling in ehci. These requests work on USB 1.0.
[ 869.178063] lirc_mceusb2[9]: receive request called (size=0x10)
[ 869.178074] ehci_hcd :00:1d.7: Budgeting new QH: owner
f79ac800, timing 1,2,32, interval 8
[ 869.178079] FS/LS strategy, Metrics:
[ 869.178082] uF
On 12/22/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Dec 2006, Jon Smirl wrote:
>
> > I've got three USB 1.0 devices now that fail to work when plugged into
> > a USB 2.0 hub. I have all of the EHCI patches from mm applied to my
> > kernel.
> >
> > I have the source the device drivers. C
On 12/22/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Dec 2006, Jon Smirl wrote:
>
> > I've got three USB 1.0 devices now that fail to work when plugged into
> > a USB 2.0 hub. I have all of the EHCI patches from mm applied to my
> > kernel.
> >
> > I have the source the device drivers. C
On Fri, 22 Dec 2006, Jon Smirl wrote:
> I've got three USB 1.0 devices now that fail to work when plugged into
> a USB 2.0 hub. I have all of the EHCI patches from mm applied to my
> kernel.
>
> I have the source the device drivers. Can someone explain to be what
> needs to be done to adjust thes
I've got three USB 1.0 devices now that fail to work when plugged into
a USB 2.0 hub. I have all of the EHCI patches from mm applied to my
kernel.
I have the source the device drivers. Can someone explain to be what
needs to be done to adjust these drivers to work with a USB 2.0 hub? I
have some t
16 matches
Mail list logo
