On Mon, Jan 18, 2010 at 2:33 PM, Harald Milz wrote:
> Hi,
>
> I am trying to use a S-2400 for Hotbird in addition to 2 S2-3650's pointing at
> Astra. For the 3650's I need to use s2-liplianin because the box is not yet
> supported by my stock OpenSUSE 11.1 (update) kernel. The 3650's work fine so
André Weidemann wrote:
> Could please post a link to this patch? I think that a few people on
> this list, including me, are interested in a solution.
The patches should be small enough to post here and are attached. They
were sent to me by Alan Stern when he was looking at the issue. Apply
patch 1
Hi David,
On 24.08.2009 19:17, David wrote:
still broken as of 2.6.30. The 2.6.31rc should have the fix, and I have
a patch for 2.6.30 if you want it.
Could please post a link to this patch? I think that a few people on
this list, including me, are interested in a solution.
Regards.
André
-
Markus Schuss wrote:
> Hi,
>
> i have some problems getting a technotrend tt-connect s-2400 usb dvb-s
> card to work. the problem is not unknown (as mentioned at
> http://lkml.org/lkml/2009/5/23/95) but i have no idea how to fix this.
> (any help according to the remote of this
Hi,
i have some problems getting a technotrend tt-connect s-2400 usb dvb-s
card to work. the problem is not unknown (as mentioned at
http://lkml.org/lkml/2009/5/23/95) but i have no idea how to fix this.
(any help according to the remote of this card would also be appreciated)
dmesg:
usb 2
Hi!
I know the device itself works but is there any way to get the remote
control to work?
thx in advance,
schuschu
--
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/maj
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
>> ==
ppear 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-24
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
sen 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
> 'd
el: 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-24
e 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 m
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
3-10: configuration #1 chosen from 1 choice
[ 3087.066065] dvb-usb: found a 'Technotrend TT-connect S-2400' in cold
state, will try to load a firmware
[ 3087.066073] usb 3-10: firmware: requesting dvb-usb-tt-s2400-01.fw
[ 3087.102717] dvb-usb: downloading firmware from file
'dv
35 matches
Mail list logo
