This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1GxcZZ-00064K-6x
The subject of the message i
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
Can devices have control endpoints other than endpoint zero? The USB
specification says that direction is ignored for control endpoints, so
non-default control endpoints must support both directions, correct?
Sarah Bailey
signature.asc
Description: Digital signature
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
Apparently, my earlier reply was lost, trying again:
> 2. You must not do IO after returning from
> disconnect
Does usb_kill_urb count as "IO"?
Many drivers call it from their shutdown routines,
which may be called after disconnect.
> It is perfectly valid to do (in pseudocode)
>
> disconnect:
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
Am Samstag, 23. Dezember 2006 00:37 schrieb J:
> * usb_get_dev - increments the reference count of the
> usb device structure
> * @dev: the device being referenced
> *
> * Each live reference to a device should be
> refcounted.
> *
> * Drivers for USB interfaces should normally record
> such
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
OK, if I got you right, usb-serial is not supposed to
access any USB stuff after usb_serial_disconnect
because device to driver association is already broken
(even if usb_device structure is still
in memory by means of ref counting),
In fact, I just noticed the following comment
(in usb_get_dev
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/media/video/usbvision/usbvision-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/video/usbvision/usbvision-core.c
+++ b/drivers/media/video/usbvision/usbvision-core.c
@@ -2305,7 +2305,7 @@ int usbvi
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
Am Freitag, 22. Dezember 2006 23:45 schrieb J:
> > if (!port || port->serial->dev->state ==
> > USB_STATE_NOTATTACHED)
>
> > There's no use checking for attachement. The state
> > may have changed.
> > In fact, if a device is disconnected via sysfs, this
> > code will happily write
> > to a de
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
On Friday 22 December 2006 2:45 pm, J wrote:
> As for the USB_STATE_NOTATTACHED, there is a long
> comment in hub.c about it. Also I see plenty of
> code, which checks it without any lock.
> So, I guess, it should not kill anybody.
Remember that "device attached" doesn't correlate
well to "driver
On Friday 22 December 2006 10:20 am, Michael Holzt wrote:
> > I will however attach the relevant part of 'lsusb -v' anyway,
>
> Oh, i noticed that there is a error reported:
>
> > HID Device Descriptor:
> > bLength 9
> > bDescriptorType33
> >
> if (!port || port->serial->dev->state ==
> USB_STATE_NOTATTACHED)
> There's no use checking for attachement. The state
> may have changed.
> In fact, if a device is disconnected via sysfs, this
> code will happily write
> to a device somebody else has claimed.
I don't understand. serial->
Am Freitag, 22. Dezember 2006 21:51 schrieb J:
I am dropping linux-kernel. This is an USB issue.
> Now, I am not yet 100% convinced that ref counting
> will, indeed, work. Atomics are known to have
> problems on SMP CPUs, which can reorder operations.
> But I would not discard atomics yet.
> Glob
> No, this is a fundamental problem. You don't
> refcount
> a pointer, you refcount a data structure.
> But this is insufficient. We need to make
> sure the pointer points to valid memory.
I understand. But a typical definition of ref-count
requires the count in the data structure to be
equal to
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
Am Freitag, 22. Dezember 2006 20:08 schrieb J:
> > This problem will need some deeper surgery probably
> > involving
> > removal of the refcounting.
>
> Refcounting may be OK if used consistently.
> It is not OK when some pointers are ref-counted,
> but other (in serial_table) are not (like it i
> This problem will need some deeper surgery probably
> involving
> removal of the refcounting.
Refcounting may be OK if used consistently.
It is not OK when some pointers are ref-counted,
but other (in serial_table) are not (like it is
in the current version).
As for the deeper surgery, what d
> I will however attach the relevant part of 'lsusb -v' anyway,
Oh, i noticed that there is a error reported:
> HID Device Descriptor:
> bLength 9
> bDescriptorType33
> bcdHID 1.01
> bCountryCode0 N
> > So whats the status of support for such composite devices in linux? If
> It should work. Please post "lsusb -v"
Hmm, shame on me. My kernel was missing a driver for usb audio :-/ and as
it did not complain about a missing driver (i remember that older kernels
had such a warning for usb devices
Am Mittwoch, 20. Dezember 2006 23:24 schrieb J:
> > Could you test the attached patch against 2.6?
>
> Alas, I only have an old 2.4 right now.
> May be I will install 2.6 later (in few weeks).
> Currently I am just trying to read 2.6 code with my
> eyes.
>
> I studied the patch, which you sent.
>
Am Freitag, 22. Dezember 2006 18:49 schrieb Michael Holzt:
> So whats the status of support for such composite devices in linux? If
It should work. Please post "lsusb -v"
Regards
Oliver
-
Take Surveys
From: Rainer Weikusat <[EMAIL PROTECTED]>
At least the Keyspan USA-19HS USB-to-serial converter supports
two different configurations, one where the input endpoints
have interrupt transfer type and one where they are bulk endpoints.
The default configuration uses the interrupt input endpoints.
The
>From a friend i got a Philips VOIP433 cordless (DECT) phone. The base
station of the phone can be connected to a PC using USB. It is intended
to be used with the "Windows Live Messenger" service to allow making
VoIP calls from the cordless handset.
Now the device seems to be something called a "c
On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 22. Dezember 2006 18:02 schrieb Dmitry Torokhov:
> > On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > right now, it merely shrinks the window.
> > > However, device_remove_file() working asynchronous is a design bug.
>
Am Freitag, 22. Dezember 2006 18:02 schrieb Dmitry Torokhov:
> On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > right now, it merely shrinks the window.
> > However, device_remove_file() working asynchronous is a design bug.
> > When would you safely call kfree? Therefore I've made a patc
On 12/22/06, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 22. Dezember 2006 17:18 schrieb Dmitry Torokhov:
> > Hi,
> >
> > On 12/20/06, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > >dev = usb_get_intfdata (interface);
> > > - usb_set_intfdata(interface, NULL);
> > >devic
Am Freitag, 22. Dezember 2006 17:18 schrieb Dmitry Torokhov:
> Hi,
>
> On 12/20/06, Greg KH <[EMAIL PROTECTED]> wrote:
> >dev = usb_get_intfdata (interface);
> > - usb_set_intfdata(interface, NULL);
> >device_remove_file(&interface->dev, &dev_attr_speed);
> > + usb_set
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 10 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1GxcZZ-00064K-6x
The subject of the message i
Hi,
On 12/20/06, Greg KH <[EMAIL PROTECTED]> wrote:
> From: Oliver Neukum <[EMAIL PROTECTED]>
>
> in disconnect you set the interface's private data to NULL. In your IO
> methods you unconditionally follow the pointer into never never land.
>
> Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> Si
Martin Williges wrote:
> --- usblp.c.orig2006-11-29 22:57:37.0 +0100
> +++ usblp.c 2006-12-22 12:08:00.0 +0100
> @@ -217,6 +217,7 @@ static const struct quirk_printer_struct
Your mailer has mangled tabs into whitespace. Also, your patch needs to
be applicable with -p1
Greg KH wrote:
> try posting follow-up stuff on the linux-usb-devel mailing list, not the
> -user list.
OK then:
> On Wed, Dec 13, 2006 at 03:23:31PM +, Phil Endecott wrote:
>> Dear USB Experts,
>>
>> I am trying to understand the relative merits of the various
>> programming interfaces to
from: Martin Williges <[EMAIL PROTECTED]>
this patch gets the Kyocera FS 820 working with cups 1.2 via usb again. It
adds the printer to the list of "quirky" printers. Patch is based on
linux-2.6.19.
Signed-off-by: Martin Williges <[EMAIL PROTECTED]>
---
Background:
I have little knowledge of u
43 matches
Mail list logo
