On 1/18/08, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008 19:03:15 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> > That's why I was somewhat suspicious that the disconnects are being
> > caused by software. What happens if the scheduler doesn't have the
> > data ready in time? C
On Thu, Jan 17, 2008 at 03:15:23PM -0800, Kevin Lloyd wrote:
> > > Correct, the 0x0023 is the only newly added device that requires the
> new
> > > features.
> >
> > Does that mean things will not work for this device if it is added to
> > the device table, without the code updates?
> Adding the de
On Fri, 18 Jan 2008 19:03:15 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> That's why I was somewhat suspicious that the disconnects are being
> caused by software. What happens if the scheduler doesn't have the
> data ready in time? Could it cause the reset I am seeing?
Since all three go toge
On 1/18/08, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008 16:25:51 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
>
> > I guess I have to buy another hub. The USB 2.0 hubs I have aren't
> > multi-tt and don't work right with the audio devices.
>
> I would rather think about adding a
On Fri, 18 Jan 2008 16:25:51 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> I guess I have to buy another hub. The USB 2.0 hubs I have aren't
> multi-tt and don't work right with the audio devices.
I would rather think about adding a USB bus or two. The thought of
three isochronous devices on th
On Fri, 18 Jan 2008, Oliver Neukum wrote:
> Am Dienstag, 15. Januar 2008 16:30:34 schrieb Alan Stern:
> > On Tue, 15 Jan 2008, Oliver Neukum wrote:
> >
> > > Hi Alan,
> > >
> > > here's a simple implementation to handle ioctl() by blocking
> > > autosuspend until the device is closed again.
> >
On 1/18/08, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 04:06:45PM -0500, Jon Smirl wrote:
> > On 1/18/08, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Fri, Jan 18, 2008 at 12:45:53PM -0500, Jon Smirl wrote:
> > > > It looks like the hub is resetting.
> > >
> > > Try replacing the h
On Fri, Jan 18, 2008 at 04:06:45PM -0500, Jon Smirl wrote:
> On 1/18/08, Greg KH <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 18, 2008 at 12:45:53PM -0500, Jon Smirl wrote:
> > > It looks like the hub is resetting.
> >
> > Try replacing the hub with a working one :)
>
> Is this TI TUSB2040/2070 cont
On 1/18/08, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 12:45:53PM -0500, Jon Smirl wrote:
> > It looks like the hub is resetting.
>
> Try replacing the hub with a working one :)
Is this TI TUSB2040/2070 controller chip known to be bad?
>
> thanks,
>
> greg k-h
>
--
Jon Smirl
Am Dienstag, 15. Januar 2008 16:30:34 schrieb Alan Stern:
> On Tue, 15 Jan 2008, Oliver Neukum wrote:
>
> > Hi Alan,
> >
> > here's a simple implementation to handle ioctl() by blocking
> > autosuspend until the device is closed again.
> >
> > It is relative to your patch set.
>
> A few comment
On Fri, Jan 18, 2008 at 12:45:53PM -0500, Jon Smirl wrote:
> It looks like the hub is resetting.
Try replacing the hub with a working one :)
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
It looks like the hub is resetting.
Bus 002 Device 074: ID 0451:1446 Texas Instruments, Inc. TUSB2040/2070 Hub
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol
Forgot to use the new USB list...
I have a NSLU2 providing audio for my multi-room audio system. It has
a USB 1.0 hub attached and three CMedia USB audio adapters plugged
into it. These USB devices consistently crash once or twice per day
but then restart without problem. I have dozens of these
cr
On 14/01/08 22:15, Bruce Schultz wrote:
> On 14/01/08 22:15, Bruce Schultz wrote:
>
>> On Mon, Dec 31, 2007 at 04:55:21PM -0500, Alan Stern wrote:
>>
>>> On Mon, 31 Dec 2007, Bruce Schultz wrote:
>>>
I have a USB SD card reader which has never worked properly and finally
g
pl2303: add support for RATOC REX-USB60F
This patch adds support for RATOC REX-USB60F Serial Adapters,
which is widely used in Japan recently.
Signed-off-by: Akira Tsukamoto <[EMAIL PROTECTED]>
---
diff -uprX dontdiff linux-2.6.24-rc8.orig/drivers/usb/serial/pl2303.c
linux-2.6.24-rc8/drivers/us
Am Freitag, 18. Januar 2008 01:57:31 schrieb Jordi Fernández:
>
> I have a printer device that is not listed in usb database:
>
>
> T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 18 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=10ce ProdID=000e Rev=
Am Freitag, 18. Januar 2008 00:31:26 schrieb mathewss:
> This driver for me does not work when i try to cat /dev/ttyUSB2
> it fails and when i try to run
>
> statserial /dev/ttyUSB2
> statserial: TIOCMGET failed: Invalid argument
We are always looking for testers. Can you recompile with CONFIG_U
17 matches
Mail list logo