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). So
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.
I'll test
On Mon, 25 May 2009, Pete Zaitcev wrote:
On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net 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
Pete Zaitcev wrote:
On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net 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
On Tue, 26 May 2009 19:42:00 +0100, David da...@unsolicited.net 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
Pete Zaitcev wrote:
On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern
st...@rowland.harvard.edu 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
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, so I
guess
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
===
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
On Mon, 25 May 2009 13:25:55 +0100, David da...@unsolicited.net 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
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 what happens with
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
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 difference
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/0u worked fine
On Sun, 24 May 2009 22:10:50 -0400 (EDT), Alan Stern
st...@rowland.harvard.edu 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
On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net 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
Alan Stern wrote:
On Sat, 23 May 2009, Pekka Enberg wrote:
On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net 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:
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
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 reversion.
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 of a
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
22 matches
Mail list logo
