On Sun, 20 Jan 2008, Jon Smirl wrote:
> On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > > Sorry ... I thought he had posted lcpci showing a NEC controller
> > > > with EHCI *and* OHCI.
> > >
> > > It is a NEC controller with both. But I have 1.0 hub plugged in with
> > > three 1.0
On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > Sorry ... I thought he had posted lcpci showing a NEC controller
> > > with EHCI *and* OHCI.
> >
> > It is a NEC controller with both. But I have 1.0 hub plugged in with
> > three 1.0 devices in it. The 1.0 hub causes the OHCI controlle
> > Sorry ... I thought he had posted lcpci showing a NEC controller
> > with EHCI *and* OHCI.
>
> It is a NEC controller with both. But I have 1.0 hub plugged in with
> three 1.0 devices in it. The 1.0 hub causes the OHCI controller in
> the NEC to be used.
>
> I have had even worse luck tryin
On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote:
> On Sunday 20 January 2008, Alan Stern wrote:
> > On Sun, 20 Jan 2008, David Brownell wrote:
> >
> > > Some patches for managing periodic _completions_ have been posted
> > > recently. You might try those ... I suspect they wouldn't affect
> >
On Sunday 20 January 2008, Alan Stern wrote:
> On Sun, 20 Jan 2008, David Brownell wrote:
>
> > Some patches for managing periodic _completions_ have been posted
> > recently. You might try those ... I suspect they wouldn't affect
> > this behavior, but it'd be good to know for sure.
> >
> > I d
On 1/20/08, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sun, 20 Jan 2008, David Brownell wrote:
>
> > Some patches for managing periodic _completions_ have been posted
> > recently. You might try those ... I suspect they wouldn't affect
> > this behavior, but it'd be good to know for sure.
> >
> >
On Sun, 20 Jan 2008, David Brownell wrote:
> Some patches for managing periodic _completions_ have been posted
> recently. You might try those ... I suspect they wouldn't affect
> this behavior, but it'd be good to know for sure.
>
> I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is se
Some patches for managing periodic _completions_ have been posted
recently. You might try those ... I suspect they wouldn't affect
this behavior, but it'd be good to know for sure.
I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set.
Try the other setting. That affects the on-the-wir
On Sat, 19 Jan 2008, Jon Smirl wrote:
> I see that the device has an audio input (not exposed externally). Do
> the audio inputs consume time slots and I have six streams instead of
> three? I'm not using the input streams.
If they aren't being used then they don't consume time slots.
By the way
L PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Periodic USB failure
> CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-usb@vger.kernel.org
>
> Full lsusb -vv attached.
>
> I will need to figure out how to build a kernel for the thing to turn
> on CONFIG_USB_DEBUG
I see that the device has an audio input (not exposed externally). Do
the audio inputs consume time slots and I have six streams instead of
three? I'm not using the input streams.
It says 100mA power and I have 2.5A available.
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
Full lsusb -vv attached.
I will need to figure out how to build a kernel for the thing to turn
on CONFIG_USB_DEBUG.
--
Jon Smirl
[EMAIL PROTECTED]
Bus 003 Device 002: ID 0402:5621 ALi Corp. USB 2.0 Storage Device
Device Descriptor:
bLength18
bDescriptorType 1
bcd
On Fri, 18 Jan 2008, Jon Smirl 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?
You didn't provide enough data to really tell what was happe
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 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 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
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
22 matches
Mail list logo