Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 let's redo it, using the new and proper interface for resetting endpoints. To tell the truth, I'm not entirely certain this will work either. The hardware may cache the endpoint state, so it may be necessary to unlink the endpoint completely. Still, try this version and see what happens. Alan Stern 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 some other peripherals check that they work ok. Thanks a lot! David patch2.log.bz2 Description: application/bzip
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 some more with some other peripherals check that they work ok. Thanks a lot! I'm not done yet. That patch seemed a bit unsafe, so I revised it. This version is a lot more careful about modifying data structures while they are still in use by the hardware. If it works okay for you, I'll submit it. Still looks good to me. Cheers David patch3.log.bz2 Description: application/bzip
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 and give it another go. While CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I guess there's nothing I can do to test? 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 illegal tricks to look at data already mapped for DMA, the code used to work for a few releases. Bisecting may help. I cannot be sure of it though, and it's going to take a lot of reboots. Unfortunately, although I have an Opteron, the issue does not occur here, so I'm at a loss for the moment. But I'll have to tackle it somehow. Not sure how though. Any suggestions are welcome. Try asking the people responsible for maintaining DMA support for help. And David is very good about testing new patches. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 essentially illegal tricks to look at data already mapped for DMA, the code used to work for a few releases. Bisecting may help. I cannot be sure of it though, and it's going to take a lot of reboots. Unfortunately, although I have an Opteron, the issue does not occur here, so I'm at a loss for the moment. But I'll have to tackle it somehow. Not sure how though. Any suggestions are welcome. -- Pete 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. Cheers David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 good to know, thanks a lot. I can always just stub out any attempt to peek into the IOMMU on Opterons. This would bring us back into the days of 'D' returned from everything, although maybe not so bad as we've cut out some unnecessary usb_buffer use. At least, no more crashing. -- Pete -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 device memory). Indeed it looks the same. Is this an AMD CPU? yes, a Phenom. 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. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 there's nothing I can do to test? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -88,7 +88,7 @@ static inline void
qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
{
/* writes to an active overlay are unsafe */
- BUG_ON(qh-qh_state != QH_STATE_IDLE);
+ BUG_ON(qh-qh_state != QH_STATE_IDLE !list_empty(qh-qtd_list));
qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
qh-hw_alt_next = EHCI_LIST_END(ehci);
@@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
/* can't sleep here, we have ehci-lock... */
qh = qh_make (ehci, urb, GFP_ATOMIC);
*ptr = qh;
+ } else if (list_empty(qh-qtd_list)) {
+ /* There might have been a Clear-Halt while the QH
+ * was linked but empty.
+ */
+ qh_refresh(ehci, qh);
}
+
if (likely (qh != NULL)) {
struct ehci_qtd *qtd;
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.
[ 118.017016] usb 1-10: new high speed USB device using ehci_hcd and
address 5
[ 118.148589] usb 1-10: configuration #1 chosen from 1 choice
[ 118.452964] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[ 118.452972] usb 1-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[ 118.488474] dvb-usb: downloading firmware from file
'dvb-usb-tt-s2400-01.fw'
[ 118.550946] usbcore: registered new interface driver dvb_usb_ttusb2
[ 118.552553] usb 1-10: USB disconnect, address 5
[ 118.561083] dvb-usb: generic DVB-USB module successfully
deinitialized and disconnected.
[ 120.313020] usb 1-10: new high speed USB device using ehci_hcd and
address 6
[ 120.444942] usb 1-10: configuration #1 chosen from 1 choice
[ 120.445886] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm
state.
[ 120.446672] dvb-usb: will pass the complete MPEG2 transport stream to
the software demuxer.
[ 120.447014] DVB: registering new adapter (Technotrend TT-connect S-2400)
[ 120.455026] DVB: registering adapter 0 frontend 129197120 (Philips
TDA10086 DVB-S)...
[ 120.458383] LNBx2x attached on addr=83dvb-usb: recv bulk message
failed: -110
[ 122.457126] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[ 124.456109] dvb-usb: recv bulk message failed: -110
[ 124.456117] ttusb2: there might have been an error during control
message transfer. (rlen = 0, was 0)
[ 124.456122] dvb-usb: Technotrend TT-connect S-2400 successfully
initialized and connected.
David
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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
===
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -88,7 +88,7 @@ static inline void
qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd *qtd)
{
/* writes to an active overlay are unsafe */
-BUG_ON(qh-qh_state != QH_STATE_IDLE);
+BUG_ON(qh-qh_state != QH_STATE_IDLE !list_empty(qh-qtd_list));
qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
qh-hw_alt_next = EHCI_LIST_END(ehci);
@@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
/* can't sleep here, we have ehci-lock... */
qh = qh_make (ehci, urb, GFP_ATOMIC);
*ptr = qh;
+} else if (list_empty(qh-qtd_list)) {
+/* There might have been a Clear-Halt while the QH
+ * was linked but empty.
+ */
+qh_refresh(ehci, qh);
}
+
if (likely (qh != NULL)) {
struct ehci_qtd *qtd;
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!
David
postpatch.log.bz2
Description: application/bzip
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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
===
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -88,7 +88,7 @@ static inline void
qh_update (struct ehci_hcd *ehci, struct ehci_qh *qh, struct ehci_qtd
*qtd)
{
/* writes to an active overlay are unsafe */
- BUG_ON(qh-qh_state != QH_STATE_IDLE);
+ BUG_ON(qh-qh_state != QH_STATE_IDLE !list_empty(qh-qtd_list));
qh-hw_qtd_next = QTD_NEXT(ehci, qtd-qtd_dma);
qh-hw_alt_next = EHCI_LIST_END(ehci);
@@ -971,7 +971,13 @@ static struct ehci_qh *qh_append_tds (
/* can't sleep here, we have ehci-lock... */
qh = qh_make (ehci, urb, GFP_ATOMIC);
*ptr = qh;
+ } else if (list_empty(qh-qtd_list)) {
+ /* There might have been a Clear-Halt while the QH
+ * was linked but empty.
+ */
+ qh_refresh(ehci, qh);
}
+
if (likely (qh != NULL)) {
struct ehci_qtd *qtd;
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!
Yes, the log shows two timeouts. Maybe I misunderstood something and
the patch only made the situation worse!
We may have to try a debugging patch to find out what's really
happening here. I'll get back to you on that...
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 CONFIG_HAVE_DMA_API_DEBUG was set, DMA_API_DEBUG was not, so I guess there's nothing I can do to test? 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 illegal tricks to look at data already mapped for DMA, the code used to work for a few releases. Bisecting may help. I cannot be sure of it though, and it's going to take a lot of reboots. Unfortunately, although I have an Opteron, the issue does not occur here, so I'm at a loss for the moment. But I'll have to tackle it somehow. Not sure how though. Any suggestions are welcome. -- Pete -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 and without the reversion. Maybe some difference will stick ou 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). Cheers David just a note, since you said it is some ATI chipset. Is it the SB700? We have lots of reports about disconnects, but then also claimed to be fixed in between, and i don't know the current status ... The latest trace is from an Intel dual core (SL9400) laptop, so the problem exists across Nvidia, ATI and Intel USB Hardware. The ATI system with the quad core (AMD 790FX, Phenom) hangs solid when trying to use usbmon though (if that's what you are getting at)? David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 over an ssh connection -- you end up dumping the packets containing the dump output! But if not then this is a genuine bug and it should be reported separately on the linux-usb mailing list. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 will stick ou 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). I see a suggestive pattern, though the exact mechanism still isn't clear. The log shows: An URB for bulk endpoint 1-in (the only URB queued) completes. About 150 us later, the driver does Clear-Halt on that endpoint. About 150 us after that, the driver submits another URB. Without the patch this URB completes normally and transfers 64 bytes (i.e., only one packet). With the patch, the URB times out. We can safely conclude that the endpoint toggle setting is getting out of sync between the device and the host, as a result of the Clear-Halt. There is code in ehci-hcd to prevent this from happening; the question is why doesn't it work now when it used to work before? I'll think about it some more... Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 for the keyboard and mouse. I then plugged in the S-2400 and was greeted with this kernel panic (jpg attached). David 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). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 looks the same. Is this an AMD CPU? I wonder if CONFIG_HAVE_DMA_API_DEBUG does it (enabled with a select in arch/x86/Kconfig). Strange that it started happening now. -- Pete -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 introduced in 2.6.27. Reverting this change in 2.6.29-rc5 makes the card work happily again. [ Note: David meant 2.6.30-rc5 here. ] Thanks for doing the bisect! On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote: I don't know enough about USB protocols to speculate on whether there may be a better fix, but hopefully someone cleverer than me can get to the bottom of the problem? Lets start with cc'ing the right people. :-) Pekka -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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: b963801164618e25fbdc0cd452ce49c3628b46c8 USB: ehci-hcd unlink speedups ..that was introduced in 2.6.27. Reverting this change in 2.6.29-rc5 makes the card work happily again. [ Note: David meant 2.6.30-rc5 here. ] Thanks for doing the bisect! On Sat, May 23, 2009 at 12:32 AM, David da...@unsolicited.net wrote: I don't know enough about USB protocols to speculate on whether there may be a better fix, but hopefully someone cleverer than me can get to the bottom of the problem? It's hard to see how that patch could cause any problems, provided the hardware is working correctly. (There was a case where the hardware was _not_ working as expected.) Is any more information available about this failure? Here's all I have. The device is a USB connected Technotrend TT-Connect S-2400. Support for this was added in kernel 2.6.26. When I came to upgrade my media PC beyond .26 the dmesg showed the following:- 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-connect S-2400' in cold state, will try to load a firmware 19:13:18 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw 19:13:18 s kernel: dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw' 19:13:18 s kernel: usb 1-3: USB disconnect, address 6 19:13:18 s kernel: dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. 19:13:20 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 7 19:13:20 s kernel: usb 1-3: configuration #1 chosen from 1 choice 19:13:20 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state. 19:13:20 s kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. 19:13:20 s kernel: DVB: registering new adapter (Technotrend TT-connect S-2400) 19:13:20 s kernel: DVB: registering frontend 0 (Philips TDA10086 DVB-S)... 19:13:23 s kernel: dvb-usb: recv bulk message failed: -110 19:13:23 s kernel: ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0) 19:13:23 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected. The device times out. Reverting b963801164618e25fbdc0cd452ce49c3628b46c8 causes it to work again 19:09:53 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 5 19:09:53 s kernel: usb 1-3: configuration #1 chosen from 1 choice 19:09:58 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware 19:09:58 s kernel: firmware: requesting dvb-usb-tt-s2400-01.fw 19:09:59 s kernel: dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw' 19:09:59 s kernel: usb 1-3: USB disconnect, address 5 19:09:59 s kernel: dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. 19:09:59 s kernel: usbcore: registered new interface driver dvb_usb_ttusb2 19:10:00 s kernel: usb 1-3: new high speed USB device using ehci_hcd and address 6 19:10:00 s kernel: usb 1-3: configuration #1 chosen from 1 choice 19:10:01 s kernel: dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state. 19:10:01 s kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. 19:10:01 s kernel: DVB: registering new adapter (Technotrend TT-connect S-2400) 19:10:01 s kernel: DVB: registering frontend 3 (Philips TDA10086 DVB-S)... 19:10:01 s kernel: dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected. My PC (64 bit - ATI chipset, using 2.6.30-rc5) [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 [12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware [12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw [12044.918854] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw' [12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2 [12044.981478] usb 4-10: USB disconnect, address 5 [12044.985169] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [12046.744023] usb 4-10: new high speed USB device using ehci_hcd and address 6 [12046.876980] usb 4-10: configuration #1 chosen from 1 choice [12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state. [12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400) [12046.886861] DVB:
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 [12044.881621] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware [12044.881626] usb 4-10: firmware: requesting dvb-usb-tt-s2400-01.fw [12044.918854] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw' [12044.980719] usbcore: registered new interface driver dvb_usb_ttusb2 [12044.981478] usb 4-10: USB disconnect, address 5 [12044.985169] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [12046.744023] usb 4-10: new high speed USB device using ehci_hcd and address 6 [12046.876980] usb 4-10: configuration #1 chosen from 1 choice [12046.877673] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state. [12046.878601] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [12046.878959] DVB: registering new adapter (Technotrend TT-connect S-2400) [12046.886861] DVB: registering adapter 0 frontend 0 (Philips TDA10086 DVB-S)... [12046.891434] LNBx2x attached on addr=83dvb-usb: recv bulk message failed: -110 [12048.888080] ttusb2: there might have been an error during control message transfer. (rlen = 0, was 0) [12048.888320] dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected. Yes, there's an obvious problem. Reverting b963801164618e25fbdc0cd452ce49c3628b46c8 (manually, as there are conflicting changes) causes it to work again. The wierd random frontend number looks strange though. [ 2406.492027] usb 2-10: new high speed USB device using ehci_hcd and address 7 [ 2406.625622] usb 2-10: configuration #1 chosen from 1 choice [ 2406.626328] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold state, will try to load a firmware [ 2406.626335] usb 2-10: firmware: requesting dvb-usb-tt-s2400-01.fw [ 2406.628650] dvb-usb: downloading firmware from file 'dvb-usb-tt-s2400-01.fw' [ 2406.690868] usb 2-10: USB disconnect, address 7 [ 2406.693282] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [ 2408.453024] usb 2-10: new high speed USB device using ehci_hcd and address 8 [ 2408.585983] usb 2-10: configuration #1 chosen from 1 choice [ 2408.586652] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state. [ 2408.587727] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 2408.588080] DVB: registering new adapter (Technotrend TT-connect S-2400) [ 2408.591575] DVB: registering adapter 0 frontend 42056112 (Philips TDA10086 DVB-S)... [ 2408.595941] LNBx2x attached on addr=86dvb-usb: Technotrend TT-connect S-2400 successfully initialized and connected. I don't know what's going on with that frontend number. In fact, I don't know anything about DVB in general... but I am familiar with EHCI. 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 out. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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. Maybe some difference will stick ou 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). Cheers David just a note, since you said it is some ATI chipset. Is it the SB700? We have lots of reports about disconnects, but then also claimed to be fixed in between, and i don't know the current status ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB/DVB - Old Technotrend TT-connect S-2400 regression tracked down
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 work happily again. I don't know enough about USB protocols to speculate on whether there may be a better fix, but hopefully someone cleverer than me can get to the bottom of the problem? Cheers David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
