Alan Stern wrote:
> On Wed, 27 May 2009, David wrote:
>
>
>> Sorry for the delay, your patch reached me just after I turned in last
>> night.
>>
>> It looks good to me. dmesg is how I'd expect, and I've attached the usb
>> trace which looks pretty similar to when the original patch was reverted.
On Wed, 27 May 2009, David wrote:
> Sorry for the delay, your patch reached me just after I turned in last
> night.
>
> It looks good to me. dmesg is how I'd expect, and I've attached the usb
> trace which looks pretty similar to when the original patch was reverted.
>
> I'll test some more with
Alan Stern wrote:
> On Mon, 25 May 2009, David wrote:
>
>
> I think the idea of the patch was good, but the endpoint direction
> information got lost (because the information was taken from the dummy
> qTD which is always marked as OUT -- I don't see how this could ever
> have worked properly).
On Mon, 25 May 2009, David wrote:
> > No luck I'm afraid (although there now appear to be 2 timeouts, not
> > one). I'm going to follow up on the laptop and get a USB log.
> >
> USB log post-patch attached. Thanks for all the effort so far!
I think the idea of the patch was good, but the endpo
On Tue, 26 May 2009 19:42:00 +0100, David wrote:
> I've been doing a bit of random rebooting (I don't really have time to
> do a full bisect), and can reproduce the usbmon panic on this machine
> back to 2.6.24.. so it certainly hasn't appeared that recently.
Actually that's good to know, thanks
Pete Zaitcev wrote:
> On Mon, 25 May 2009 13:25:55 +0100, David wrote:
>
>
> I suppose so. I misunderstood how this worked. I guessed that the
> DMA API debugging was the culprit because its introduction coincided
> with the recent onset of this oops.
>
> Although usbmon does essentially illega
On Mon, 25 May 2009, Pete Zaitcev wrote:
> On Mon, 25 May 2009 13:25:55 +0100, David wrote:
>
> > >> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
> > >> in arch/x86/Kconfig). Strange that it started happening now.
> > >>
> > > That is enabled. I'll switch it off and
On Mon, 25 May 2009 13:25:55 +0100, David wrote:
> >> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
> >> in arch/x86/Kconfig). Strange that it started happening now.
> >>
> > That is enabled. I'll switch it off and give it another go.
> >
> While CONFIG_HAVE_DMA_API
On Mon, 25 May 2009, David wrote:
> David wrote:
> > Alan Stern wrote:
> >
> >> Okay, here's a patch for you to try. It refreshes the toggle setting
> >> in a linked but otherwise idle QH when a new URB is queued.
> >>
> >> Alan Stern
> >>
> >>
> >> Index: usb-2.6/drivers/usb/host/ehci-q.c
>
David wrote:
> Alan Stern wrote:
>
>> Okay, here's a patch for you to try. It refreshes the toggle setting
>> in a linked but otherwise idle QH when a new URB is queued.
>>
>> Alan Stern
>>
>>
>> Index: usb-2.6/drivers/usb/host/ehci-q.c
>> ==
Alan Stern wrote:
> Okay, here's a patch for you to try. It refreshes the toggle setting
> in a linked but otherwise idle QH when a new URB is queued.
>
> Alan Stern
>
>
> Index: usb-2.6/drivers/usb/host/ehci-q.c
> ===
> --- usb-2.6.
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reversion. Maybe some differ
David wrote:
>
>> I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select
>> in arch/x86/Kconfig). Strange that it started happening now.
>>
>>
> That is enabled. I'll switch it off and give it another go.
>
>
While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, s
Pete Zaitcev wrote:
> On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern
> wrote:
>
>
>> Pete, you should look at this. It appears to be a problem with the DMA
>> mapping in usbmon. Probably the same sort of thing you were working on
>> about a week ago (trying to access device memory).
>>
On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern
wrote:
> Pete, you should look at this. It appears to be a problem with the DMA
> mapping in usbmon. Probably the same sort of thing you were working on
> about a week ago (trying to access device memory).
Indeed it looks the same. Is this
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > But if not then this is a genuine bug and it should be reported
> > separately on the linux-usb mailing list.
> >
> >
> >
>
> Stranger and stranger. I started usbmon on the quad core and (at the
> console) cat /sys/kernel/debug/usbmon/0
On Sun, 24 May 2009, David wrote:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reversion. Maybe some differ
On Sun, 24 May 2009, David wrote:
> Traces attached. Took a while as my quad core hangs solid when 0u is
> piped to a file (I had to compile on a laptop and take the logs there).
Is the output file being written to a USB device? Obviously that's not
a good thing to do; it's like running tcpdump
hermann pitton wrote:
> Hi,
>
> Am Sonntag, den 24.05.2009, 01:15 +0100 schrieb David:
>
>> Alan Stern wrote:
>>
>>> It's not obvious what could be causing this, so let's start out easy.
>>> Try collecting two usbmon traces (instructions are in
>>> Documentation/usb/usbmon.txt), showing w
Hi,
Am Sonntag, den 24.05.2009, 01:15 +0100 schrieb David:
> Alan Stern wrote:
> > It's not obvious what could be causing this, so let's start out easy.
> > Try collecting two usbmon traces (instructions are in
> > Documentation/usb/usbmon.txt), showing what happens with and without
> > the reve
Alan Stern wrote:
> It's not obvious what could be causing this, so let's start out easy.
> Try collecting two usbmon traces (instructions are in
> Documentation/usb/usbmon.txt), showing what happens with and without
> the reversion. Maybe some difference will stick ou
>
Traces attached. Took
On Sat, 23 May 2009, David wrote:
> My PC (64 bit - ATI chipset, using 2.6.30-rc5)
Let's continue to work with 2.6.30-rc for testing purposes.
> [12044.364021] usb 4-10: new high speed USB device using ehci_hcd and address
> 5
> [12044.497561] usb 4-10: configuration #1 chosen from 1 choice
> [
Again, hopefully with word wrap sorted out...
Media PC (32-bit - Nvidia chipset. kernel 2.6.27)
19:13:18 s kernel: usb 1-3: new high speed USB device using ehci_hcd and
address 6
19:13:18 s kernel: usb 1-3: configuration #1 chosen from 1 choice
19:13:18 s kernel: dvb-usb: found a 'Technotrend TT
Alan Stern wrote:
> On Sat, 23 May 2009, Pekka Enberg wrote:
>
>
>> On Sat, May 23, 2009 at 12:32 AM, David wrote:
>>
>>> I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
>>> finally had time to do some digging, and the regression is caused by:
>>>
>>>b963801164618e2
On Sat, 23 May 2009, Pekka Enberg wrote:
> On Sat, May 23, 2009 at 12:32 AM, David wrote:
> > I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
> > finally had time to do some digging, and the regression is caused by:
> >
> > b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci
On Sat, May 23, 2009 at 12:32 AM, David wrote:
> I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
> finally had time to do some digging, and the regression is caused by:
>
> b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups
>
> ..that was introduced in 2.
I reported this DVB-S card breaking between 2.6.26 and 2.6.27. I've
finally had time to do some digging, and the regression is caused by:
b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups
..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
makes the card
David wrote:
> ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5
> makes the card work happily again.
>
Make that 2.6.30-rc5 .. my brain is obviously fried from too much .NET
this week :-(
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body o
28 matches
Mail list logo
