[linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Andrew Junev]

Hello All,

I was successfully using two TT S-1401 DVB-S cards in my HTPC running
Fedora 8. One of my antennas is positioned to Astra 19.2E and its
signal quality is quite low in my area. But the setup worked just fine
for me most of the time.

Last weekend I updated my system from kernel-2.6.23.15-137.fc8 to
kernel-2.6.24.3-12.fc8. It was just a 'yum update', nothing else.
Right after that I got no lock on most of Astra transponders (other
satellites were still Ok, but they normally have a far better signal).
After checking everything twice without any success, I booted back to
2.6.23.15 and my Astra was back!

Is this a known behavior? I suppose it was not discussed before, so
this makes me think I am the only one with such a problem...
Strange... I think the problem is somehow related to the signal level / 
signal error rate. Looks like weak transponders are harder to lock
with the new kernel...
I'd appreciate any comments on this. I don't think I have an urgent
need to move to 2.6.24 now, but I'd still like to be able to do that
without loosing my TV... 


P.S. I can see there's kernel-2.6.24.3-34.fc8 already available for
Fedora 8. But I didn't try it yet...

-- 
Best regards,
 Andrew


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

Andrew Junev wrote:
> Hello All,
> 
> I was successfully using two TT S-1401 DVB-S cards in my HTPC running
> Fedora 8. One of my antennas is positioned to Astra 19.2E and its
> signal quality is quite low in my area. But the setup worked just fine
> for me most of the time.
> 
> Last weekend I updated my system from kernel-2.6.23.15-137.fc8 to
> kernel-2.6.24.3-12.fc8. It was just a 'yum update', nothing else.
> Right after that I got no lock on most of Astra transponders (other
> satellites were still Ok, but they normally have a far better signal).
> After checking everything twice without any success, I booted back to
> 2.6.23.15 and my Astra was back!
> 
> Is this a known behavior? I suppose it was not discussed before, so
> this makes me think I am the only one with such a problem...
> Strange... I think the problem is somehow related to the signal level / 
> signal error rate. Looks like weak transponders are harder to lock
> with the new kernel...
> I'd appreciate any comments on this. I don't think I have an urgent
> need to move to 2.6.24 now, but I'd still like to be able to do that
> without loosing my TV... 
> 
> 
> P.S. I can see there's kernel-2.6.24.3-34.fc8 already available for
> Fedora 8. But I didn't try it yet...

Afaik this is a known regression in 2.6,24.

See 
  http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023477.html
and
  http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023559.html
for the fix.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Andrew Junev]

Hello Oliver,

Thursday, March 20, 2008, 2:48:14 AM, you wrote:

> Afaik this is a known regression in 2.6,24.

> See 
>  
> http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023477.html
> and
>  
> http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023559.html
> for the fix.


Umm... Sorry for a stupid question, but does it mean I won't be able
to use 'repo-bundled' 2.6.24 kernel at all? Do you know if there was
any information that the fix (in fact, the removal of a patch) is to
be included in the next kernel? 

-- 
Best regards,
 Andrew



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi,

Am Donnerstag, den 20.03.2008, 00:48 +0100 schrieb Oliver Endriss:
> Andrew Junev wrote:
> > Hello All,
> > 
> > I was successfully using two TT S-1401 DVB-S cards in my HTPC running
> > Fedora 8. One of my antennas is positioned to Astra 19.2E and its
> > signal quality is quite low in my area. But the setup worked just fine
> > for me most of the time.
> > 
> > Last weekend I updated my system from kernel-2.6.23.15-137.fc8 to
> > kernel-2.6.24.3-12.fc8. It was just a 'yum update', nothing else.
> > Right after that I got no lock on most of Astra transponders (other
> > satellites were still Ok, but they normally have a far better signal).
> > After checking everything twice without any success, I booted back to
> > 2.6.23.15 and my Astra was back!
> > 
> > Is this a known behavior? I suppose it was not discussed before, so
> > this makes me think I am the only one with such a problem...
> > Strange... I think the problem is somehow related to the signal level / 
> > signal error rate. Looks like weak transponders are harder to lock
> > with the new kernel...
> > I'd appreciate any comments on this. I don't think I have an urgent
> > need to move to 2.6.24 now, but I'd still like to be able to do that
> > without loosing my TV... 
> > 
> > 
> > P.S. I can see there's kernel-2.6.24.3-34.fc8 already available for
> > Fedora 8. But I didn't try it yet...
> 
> Afaik this is a known regression in 2.6,24.
> 
> See 
>   http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023477.html
> and
>   http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023559.html
> for the fix.
> 
> CU
> Oliver
> 

hmm, thought that this we exactly did avoid on 2.6.24 and 2.6.25.

IIRC, this should never made it into 2.6.24, at least I thought we could
always stop it on 2.6.25 before it harms.

Fedora downports from release canditates, and almost always is fine,
so I don't trust the 2.6._24_ here.

If nothing else to do ..., might investigate it.

Cheers,
Hermann



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

hermann pitton wrote:
> Hi,
> 
> Am Donnerstag, den 20.03.2008, 00:48 +0100 schrieb Oliver Endriss:
> > Andrew Junev wrote:
> > > Hello All,
> > > 
> > > I was successfully using two TT S-1401 DVB-S cards in my HTPC running
> > > Fedora 8. One of my antennas is positioned to Astra 19.2E and its
> > > signal quality is quite low in my area. But the setup worked just fine
> > > for me most of the time.
> > > 
> > > Last weekend I updated my system from kernel-2.6.23.15-137.fc8 to
> > > kernel-2.6.24.3-12.fc8. It was just a 'yum update', nothing else.
> > > Right after that I got no lock on most of Astra transponders (other
> > > satellites were still Ok, but they normally have a far better signal).
> > > After checking everything twice without any success, I booted back to
> > > 2.6.23.15 and my Astra was back!
> > > 
> > > Is this a known behavior? I suppose it was not discussed before, so
> > > this makes me think I am the only one with such a problem...
> > > Strange... I think the problem is somehow related to the signal level / 
> > > signal error rate. Looks like weak transponders are harder to lock
> > > with the new kernel...
> > > I'd appreciate any comments on this. I don't think I have an urgent
> > > need to move to 2.6.24 now, but I'd still like to be able to do that
> > > without loosing my TV... 
> > > 
> > > 
> > > P.S. I can see there's kernel-2.6.24.3-34.fc8 already available for
> > > Fedora 8. But I didn't try it yet...
> > 
> > Afaik this is a known regression in 2.6,24.
> > 
> > See 
> >   http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023477.html
> > and
> >   http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023559.html
> > for the fix.
> > 
> > CU
> > Oliver
> > 
> 
> hmm, thought that this we exactly did avoid on 2.6.24 and 2.6.25.
> 
> IIRC, this should never made it into 2.6.24, at least I thought we could
> always stop it on 2.6.25 before it harms.
> 
> Fedora downports from release canditates, and almost always is fine,
> so I don't trust the 2.6._24_ here.
> 
> If nothing else to do ..., might investigate it.

Unfortunately, the regression made it into the 2.6.24 series.
I just checked and found it in 2.6.24.2. :-(

So we should submit a bug fix for 2.6,24, too.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Andrew Junev]

Friday, March 21, 2008, 9:42:56 AM, you wrote:

> hermann pitton wrote:
>> hmm, thought that this we exactly did avoid on 2.6.24 and 2.6.25.
>> 
>> IIRC, this should never made it into 2.6.24, at least I thought we could
>> always stop it on 2.6.25 before it harms.
>> 
>> Fedora downports from release canditates, and almost always is fine,
>> so I don't trust the 2.6._24_ here.
>> 
>> If nothing else to do ..., might investigate it.

> Unfortunately, the regression made it into the 2.6.24 series.
> I just checked and found it in 2.6.24.2. :-(

> So we should submit a bug fix for 2.6,24, too.

For the record: I just checked it with kernel-2.6.24.3-34.fc8
and the problem is still there.

Is there an easy way to check whether the bug fix was added to the
kernel (2.6.24.x)?

Thank you guys for your support!!!

> CU
> Oliver


-- 
Best regards,
 Andrew



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi again,

Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> Hello Hermann,
> 
> Thanks a lot for this detailed explanation!
> I really appreciate your help!
> 
> One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> _should_ have this patch already included?
> 

seems we hang in current stable kernel rules.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD

If we go back to 2.6.23 level, that patch might have less than 100 lines
with context, but we break the

 - It must fix only one thing

rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.

Seems sombody with such a device should reopen the bug on Bugzilla ...

Cheers,
Hermann



--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Am Donnerstag, den 03.04.2008, 01:38 +0200 schrieb hermann pitton:
> Hi again,
> 
> Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> > Hello Hermann,
> > 
> > Thanks a lot for this detailed explanation!
> > I really appreciate your help!
> > 
> > One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> > _should_ have this patch already included?
> > 
> 
> seems we hang in current stable kernel rules.
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD
> 
> If we go back to 2.6.23 level, that patch might have less than 100 lines
> with context, but we break the
> 
>  - It must fix only one thing
> 
> rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.
> 
> Seems sombody with such a device should reopen the bug on Bugzilla ...
> 

Hi Guys,

should we really let hang it like this on 2.6.24?

I'm not that happy with a recommendation for the distributions to pick
something out of it.

If we should go back to 2.6.23 level, so far nobody seems to have
realized a improvement for the LifeView Trio stuff, I'm not against it.

The changeset in question to revert is mercurial 6579.

If nobody else is interested and no comments, I also don't care anymore.

Cheers,
Hermann





--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

hermann pitton wrote:
> Am Donnerstag, den 03.04.2008, 01:38 +0200 schrieb hermann pitton:
> > Hi again,
> > 
> > Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> > > Hello Hermann,
> > > 
> > > Thanks a lot for this detailed explanation!
> > > I really appreciate your help!
> > > 
> > > One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> > > _should_ have this patch already included?
> > > 
> > 
> > seems we hang in current stable kernel rules.
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD
> > 
> > If we go back to 2.6.23 level, that patch might have less than 100 lines
> > with context, but we break the
> > 
> >  - It must fix only one thing
> > 
> > rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.
> > 
> > Seems sombody with such a device should reopen the bug on Bugzilla ...
> > 
> 
> Hi Guys,
> 
> should we really let hang it like this on 2.6.24?
> 
> I'm not that happy with a recommendation for the distributions to pick
> something out of it.
> 
> If we should go back to 2.6.23 level, so far nobody seems to have
> realized a improvement for the LifeView Trio stuff, I'm not against it.
> 
> The changeset in question to revert is mercurial 6579.
> 
> If nobody else is interested and no comments, I also don't care anymore.

(Basically I don't care because I am tired of discussing kernel
politics.)

Imho a fix should be applied, no matter how many lines it has.
If that is not possible the offending patch should be reverted in
2.6.24.x.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Am Freitag, den 04.04.2008, 02:32 +0200 schrieb Oliver Endriss:
> hermann pitton wrote:
> > Am Donnerstag, den 03.04.2008, 01:38 +0200 schrieb hermann pitton:
> > > Hi again,
> > > 
> > > Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> > > > Hello Hermann,
> > > > 
> > > > Thanks a lot for this detailed explanation!
> > > > I really appreciate your help!
> > > > 
> > > > One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> > > > _should_ have this patch already included?
> > > > 
> > > 
> > > seems we hang in current stable kernel rules.
> > > 
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD
> > > 
> > > If we go back to 2.6.23 level, that patch might have less than 100 lines
> > > with context, but we break the
> > > 
> > >  - It must fix only one thing
> > > 
> > > rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.
> > > 
> > > Seems sombody with such a device should reopen the bug on Bugzilla ...
> > > 
> > 
> > Hi Guys,
> > 
> > should we really let hang it like this on 2.6.24?
> > 
> > I'm not that happy with a recommendation for the distributions to pick
> > something out of it.
> > 
> > If we should go back to 2.6.23 level, so far nobody seems to have
> > realized a improvement for the LifeView Trio stuff, I'm not against it.
> > 
> > The changeset in question to revert is mercurial 6579.
> > 
> > If nobody else is interested and no comments, I also don't care anymore.
> 
> (Basically I don't care because I am tired of discussing kernel
> politics.)
> 
> Imho a fix should be applied, no matter how many lines it has.
> If that is not possible the offending patch should be reverted in
> 2.6.24.x.
> 
> CU
> Oliver


I fully agree!

But that is exactly where they hang us and I have it totally sick,
especially in combination with current checkpatch.pl brain damage.

Cheers,
Hermann




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Am Donnerstag, den 03.04.2008, 22:18 -0300 schrieb Mauro Carvalho
Chehab:
> On Fri, 04 Apr 2008 01:23:22 +0200
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > Am Donnerstag, den 03.04.2008, 01:38 +0200 schrieb hermann pitton:
> > > Hi again,
> > > 
> > > Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> > > > Hello Hermann,
> > > > 
> > > > Thanks a lot for this detailed explanation!
> > > > I really appreciate your help!
> > > > 
> > > > One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> > > > _should_ have this patch already included?
> > > > 
> > > 
> > > seems we hang in current stable kernel rules.
> > > 
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD
> > > 
> > > If we go back to 2.6.23 level, that patch might have less than 100 lines
> > > with context, but we break the
> > > 
> > >  - It must fix only one thing
> > > 
> > > rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.
> > > 
> > > Seems sombody with such a device should reopen the bug on Bugzilla ...
> > > 
> > 
> > Hi Guys,
> > 
> > should we really let hang it like this on 2.6.24?
> > 
> > I'm not that happy with a recommendation for the distributions to pick
> > something out of it.
> > 
> > If we should go back to 2.6.23 level, so far nobody seems to have
> > realized a improvement for the LifeView Trio stuff, I'm not against it.
> > 
> > The changeset in question to revert is mercurial 6579.
> > 
> > If nobody else is interested and no comments, I also don't care anymore.
> 
> I don't see why to revert changeset 6579. On changeset 7186, an option were added at the frontend structure, to allow specify if diseqc requires a modulated signal or not. It is just a matter of changing the struct. Something like:
> 
>  static struct tda10086_config dvbs_card1 = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 0,	/* Non-modulated tone - The default behavior after changeset 6579 */
>  };
> 
>  static struct tda10086_config dvbs_card2 = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 1,	/* modulated tone - The default behavior before changeset 6579 */
>  };
> 
> The problem seems to be related to this struct:
> 
> static struct tda10086_config flydvbs = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 0,
> };
> 
> is currently in use by several variants:
> 	SAA7134_BOARD_FLYDVB_TRIO,
> 	SAA7134_BOARD_MEDION_MD8800_QUADRO,
> 	SAA7134_BOARD_FLYDVBS_LR300,
> 	SAA7134_BOARD_PHILIPS_SNAKE,
> 	SAA7134_BOARD_MD7134_BRIDGE_2.
> 
> Probably, some of those boards need .diseqc_tone=1 while others require .diseqc_tone=0.
> 
> What are the boards that are currently broken?
> 
> Cheers,
> Mauro

Mauro,

as far I can see on v4l-dvb master, none. On 2.6.25 none. On 2.6.26 we
will have some new fun.

What Hartmut added is fully sufficient.

The problen is only on 2.6.24.something currently.

We can't add the necessarry fix currently, because above 100 lines
including context are not allowed bullshit we have to face. To go below
it, 2.6.23, means to break the Trio DVB-S stuff you took in from
Bugzilla. It is not the first time that something goes wrong here and I
really don't like the _pisszilla_ ;;) at all.

Too much comes easily in to just please and do a favour, but not on
devel and crosschecked level.

We have the right point I think, we can't accept some idiotic 100 lines
restriction including context here for a fix.

Cheers,
Hermann




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

Mauro Carvalho Chehab wrote:
> > > > If we should go back to 2.6.23 level, so far nobody seems to have
> > > > realized a improvement for the LifeView Trio stuff, I'm not against it.
> > > > 
> > > > The changeset in question to revert is mercurial 6579.
> > > > 
> > > > If nobody else is interested and no comments, I also don't care anymore.
> > > 
> > > (Basically I don't care because I am tired of discussing kernel
> > > politics.)
> > > 
> > > Imho a fix should be applied, no matter how many lines it has.
> > > If that is not possible the offending patch should be reverted in
> > > 2.6.24.x.
> ...
> 
> Let me try to reset to a sane state.
> 
> With the current tree (changesets 6579 and 7186), is there any broken board? If
> so, what board(s)?
> 
> Both patches are already applied at mainstream and should be available on
> 2.6.25. Are those OK for 2.6.25?
> 
> Is there any missing patch that should be sent to -stable (2.6.24)? If so, what
> patch?

The point is that 6579 was applied to 2.6.24.x, but 7186 wasn't.
So TTS_1401 support is broken for the 2.6.24 series.

Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Michael Krufky]

Oliver Endriss wrote:
> Mauro Carvalho Chehab wrote:
>   
>>>>> If we should go back to 2.6.23 level, so far nobody seems to have
>>>>> realized a improvement for the LifeView Trio stuff, I'm not against it.
>>>>>
>>>>> The changeset in question to revert is mercurial 6579.
>>>>>
>>>>> If nobody else is interested and no comments, I also don't care anymore.
>>>>>           
>>>> (Basically I don't care because I am tired of discussing kernel
>>>> politics.)
>>>>
>>>> Imho a fix should be applied, no matter how many lines it has.
>>>> If that is not possible the offending patch should be reverted in
>>>> 2.6.24.x.
>>>>         
>> ...
>>
>> Let me try to reset to a sane state.
>>
>> With the current tree (changesets 6579 and 7186), is there any broken board? If
>> so, what board(s)?
>>
>> Both patches are already applied at mainstream and should be available on
>> 2.6.25. Are those OK for 2.6.25?
>>
>> Is there any missing patch that should be sent to -stable (2.6.24)? If so, what
>> patch?
>>     
>
> The point is that 6579 was applied to 2.6.24.x, but 7186 wasn't.
> So TTS_1401 support is broken for the 2.6.24 series.
>
> Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.
>   
Are you saying that THIS is the patch that needs to be applied to 2.6.24.y ?

http://linuxtv.org/hg/v4l-dvb/rev/eb6bc7f18024

If so, this patch seems fine for -stable.  We just have to make sure it
applies correctly, etc.

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Mauro Carvalho Chehab]

>> Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.
>>
> Are you saying that THIS is the patch that needs to be applied to 2.6.24.y ?
>
> http://linuxtv.org/hg/v4l-dvb/rev/eb6bc7f18024
>
> If so, this patch seems fine for -stable.  We just have to make sure it
> applies correctly, etc.

Agreed.

I don't see why the patch would be rejected for -stable. It is a fix, 
proofed to work, and simple enough for everybody to understand what it is 
doing.

The kernel documents are guidances, not absolute rules. In the end, good 
sense is the main rule for a patch to be applied or not.

---

Next time, please ask first for us to submit a patch to mainstream or 
-stable before complaining why it weren't submitted.

Side note: after reviewing the entire thread, and finally understanding 
the hole picture, it seems that you've implicitly asked. The better is to 
send an objective email. Something like:
 	Subject: [PATCH -stable] Please send patch xxxx to -stable

Requesting to add a patch in the middle of a thread generally means that 
the patch won't be handled as so. The better is to send a separate e-mail, 
with the word [PATCH] at the subject, copying the one who will be 
responsible for applying it at the tree (the driver maintainer or me), for 
this to be handled. In the case of patches for -stable, please c/c 
mkrufky.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

Michael Krufky wrote:
> Oliver Endriss wrote:
> > Mauro Carvalho Chehab wrote:
> >   
> >>>>> If we should go back to 2.6.23 level, so far nobody seems to have
> >>>>> realized a improvement for the LifeView Trio stuff, I'm not against it.
> >>>>>
> >>>>> The changeset in question to revert is mercurial 6579.
> >>>>>
> >>>>> If nobody else is interested and no comments, I also don't care anymore.
> >>>>>           
> >>>> (Basically I don't care because I am tired of discussing kernel
> >>>> politics.)
> >>>>
> >>>> Imho a fix should be applied, no matter how many lines it has.
> >>>> If that is not possible the offending patch should be reverted in
> >>>> 2.6.24.x.
> >>>>         
> >> ...
> >>
> >> Let me try to reset to a sane state.
> >>
> >> With the current tree (changesets 6579 and 7186), is there any broken board? If
> >> so, what board(s)?
> >>
> >> Both patches are already applied at mainstream and should be available on
> >> 2.6.25. Are those OK for 2.6.25?
> >>
> >> Is there any missing patch that should be sent to -stable (2.6.24)? If so, what
> >> patch?
> >>     
> >
> > The point is that 6579 was applied to 2.6.24.x, but 7186 wasn't.
> > So TTS_1401 support is broken for the 2.6.24 series.
> >
> > Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.
> >   
> Are you saying that THIS is the patch that needs to be applied to 2.6.24.y ?
> 
> http://linuxtv.org/hg/v4l-dvb/rev/eb6bc7f18024
> 
> If so, this patch seems fine for -stable.  We just have to make sure it
> applies correctly, etc.

Correct, this is the patch.
I did a quick check: It applies to 2.6.24.2 with some hunks.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Michael Krufky]

Mauro Carvalho Chehab wrote:
>>> Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.
>>>
>> Are you saying that THIS is the patch that needs to be applied to 2.6.24.y ?
>>
>> http://linuxtv.org/hg/v4l-dvb/rev/eb6bc7f18024
>>
>> If so, this patch seems fine for -stable.  We just have to make sure it
>> applies correctly, etc.
> 
> Agreed.
> 
> I don't see why the patch would be rejected for -stable. It is a fix, 
> proofed to work, and simple enough for everybody to understand what it is 
> doing.
> 
> The kernel documents are guidances, not absolute rules. In the end, good 
> sense is the main rule for a patch to be applied or not.
> 
> ---
> 
> Next time, please ask first for us to submit a patch to mainstream or 
> -stable before complaining why it weren't submitted.
> 
> Side note: after reviewing the entire thread, and finally understanding 
> the hole picture, it seems that you've implicitly asked. The better is to 
> send an objective email. Something like:
>  	Subject: [PATCH -stable] Please send patch xxxx to -stable
> 
> Requesting to add a patch in the middle of a thread generally means that 
> the patch won't be handled as so. The better is to send a separate e-mail, 
> with the word [PATCH] at the subject, copying the one who will be 
> responsible for applying it at the tree (the driver maintainer or me), for 
> this to be handled. In the case of patches for -stable, please c/c 
> mkrufky.



Guys,

Please test this patch against 2.6.24.4 -stable.

I don't have this hardware, or any way to test this myself, so I will wait on your feedback before sending this to the -stable team.  (Please try to test it and get back to me quickly -- I'd like to send this over before the 2.6.24.5 review cycle begins)

-Mike

From: Hartmut Hackmann <hartmut.hackmann@t-online.de>
Date: Sat, 9 Feb 2008 23:54:24 -0300

[2.6.24.y PATCH] DVB: tda10086: make the 22kHz tone for DISEQC a config option

Some cards need the diseqc signal modulated, while some just need
the envelope to control the LNB supply.

This fixes Bug 9887

Signed-off-by: Hartmut Hackmann <hartmut.hackmann@t-online.de>
Acked-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
(cherry picked from commit ea75baf4b0f117564bd50827a49c4b14d61d24e9)
---
 drivers/media/dvb/dvb-usb/ttusb2.c        |    1 +
 drivers/media/dvb/frontends/tda10086.c    |   28 ++++++++++++++++++++++------
 drivers/media/dvb/frontends/tda10086.h    |    3 +++
 drivers/media/dvb/ttpci/budget.c          |    1 +
 drivers/media/video/saa7134/saa7134-dvb.c |    5 +++--
 5 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb/dvb-usb/ttusb2.c b/drivers/media/dvb/dvb-usb/ttusb2.c
index 88dc436..3b9da9c 100644
--- a/drivers/media/dvb/dvb-usb/ttusb2.c
+++ b/drivers/media/dvb/dvb-usb/ttusb2.c
@@ -144,6 +144,7 @@ static int ttusb2_power_ctrl(struct dvb_usb_device *d, int onoff)
 static struct tda10086_config tda10086_config = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 1,
 };
 
 static int ttusb2_frontend_attach(struct dvb_usb_adapter *adap)
diff --git a/drivers/media/dvb/frontends/tda10086.c b/drivers/media/dvb/frontends/tda10086.c
index 9d26ace..0d2b69a 100644
--- a/drivers/media/dvb/frontends/tda10086.c
+++ b/drivers/media/dvb/frontends/tda10086.c
@@ -106,9 +106,12 @@ static int tda10086_write_mask(struct tda10086_state *state, int reg, int mask,
 static int tda10086_init(struct dvb_frontend* fe)
 {
 	struct tda10086_state* state = fe->demodulator_priv;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
 	// reset
 	tda10086_write_byte(state, 0x00, 0x00);
 	msleep(10);
@@ -158,7 +161,7 @@ static int tda10086_init(struct dvb_frontend* fe)
 	tda10086_write_byte(state, 0x3d, 0x80);
 
 	// setup SEC
-	tda10086_write_byte(state, 0x36, 0x80); // all SEC off, no 22k tone
+	tda10086_write_byte(state, 0x36, t22k_off); // all SEC off, 22k tone
 	tda10086_write_byte(state, 0x34, (((1<<19) * (22000/1000)) / (SACLK/1000)));      // } tone frequency
 	tda10086_write_byte(state, 0x35, (((1<<19) * (22000/1000)) / (SACLK/1000)) >> 8); // }
 
@@ -180,16 +183,20 @@ static void tda10086_diseqc_wait(struct tda10086_state *state)
 static int tda10086_set_tone (struct dvb_frontend* fe, fe_sec_tone_mode_t tone)
 {
 	struct tda10086_state* state = fe->demodulator_priv;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	switch (tone) {
 	case SEC_TONE_OFF:
-		tda10086_write_byte(state, 0x36, 0x80);
+		tda10086_write_byte(state, 0x36, t22k_off);
 		break;
 
 	case SEC_TONE_ON:
-		tda10086_write_byte(state, 0x36, 0x81);
+		tda10086_write_byte(state, 0x36, 0x01 + t22k_off);
 		break;
 	}
 
@@ -202,9 +209,13 @@ static int tda10086_send_master_cmd (struct dvb_frontend* fe,
 	struct tda10086_state* state = fe->demodulator_priv;
 	int i;
 	u8 oldval;
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	if (cmd->msg_len > 6)
 		return -EINVAL;
 	oldval = tda10086_read_byte(state, 0x36);
@@ -212,7 +223,8 @@ static int tda10086_send_master_cmd (struct dvb_frontend* fe,
 	for(i=0; i< cmd->msg_len; i++) {
 		tda10086_write_byte(state, 0x48+i, cmd->msg[i]);
 	}
-	tda10086_write_byte(state, 0x36, 0x88 | ((cmd->msg_len - 1) << 4));
+	tda10086_write_byte(state, 0x36, (0x08 + t22k_off)
+					| ((cmd->msg_len - 1) << 4));
 
 	tda10086_diseqc_wait(state);
 
@@ -225,16 +237,20 @@ static int tda10086_send_burst (struct dvb_frontend* fe, fe_sec_mini_cmd_t minic
 {
 	struct tda10086_state* state = fe->demodulator_priv;
 	u8 oldval = tda10086_read_byte(state, 0x36);
+	u8 t22k_off = 0x80;
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (state->config->diseqc_tone)
+		t22k_off = 0;
+
 	switch(minicmd) {
 	case SEC_MINI_A:
-		tda10086_write_byte(state, 0x36, 0x84);
+		tda10086_write_byte(state, 0x36, 0x04 + t22k_off);
 		break;
 
 	case SEC_MINI_B:
-		tda10086_write_byte(state, 0x36, 0x86);
+		tda10086_write_byte(state, 0x36, 0x06 + t22k_off);
 		break;
 	}
 
diff --git a/drivers/media/dvb/frontends/tda10086.h b/drivers/media/dvb/frontends/tda10086.h
index ed584a8..eeceaee 100644
--- a/drivers/media/dvb/frontends/tda10086.h
+++ b/drivers/media/dvb/frontends/tda10086.h
@@ -33,6 +33,9 @@ struct tda10086_config
 
 	/* does the "inversion" need inverted? */
 	u8 invert;
+
+	/* do we need the diseqc signal with carrier? */
+	u8 diseqc_tone;
 };
 
 #if defined(CONFIG_DVB_TDA10086) || (defined(CONFIG_DVB_TDA10086_MODULE) && defined(MODULE))
diff --git a/drivers/media/dvb/ttpci/budget.c b/drivers/media/dvb/ttpci/budget.c
index 9268a82..14b00f5 100644
--- a/drivers/media/dvb/ttpci/budget.c
+++ b/drivers/media/dvb/ttpci/budget.c
@@ -351,6 +351,7 @@ static struct s5h1420_config s5h1420_config = {
 static struct tda10086_config tda10086_config = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 1,
 };
 
 static u8 read_pwm(struct budget* budget)
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c b/drivers/media/video/saa7134/saa7134-dvb.c
index e1ab099..506de4d 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -826,6 +826,7 @@ static struct tda1004x_config ads_tech_duo_config = {
 static struct tda10086_config flydvbs = {
 	.demod_address = 0x0e,
 	.invert = 0,
+	.diseqc_tone = 0,
 };
 
 /* ==================================================================

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Michael Krufky]

On Fri, Apr 4, 2008 at 8:56 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
>
> Mauro Carvalho Chehab wrote:
>  >>> Imho 7186 _must_ be applied to 2.6.24, no matter how large the patch is.
>  >>>
>  >> Are you saying that THIS is the patch that needs to be applied to 2.6.24.y ?
>  >>
>  >> http://linuxtv.org/hg/v4l-dvb/rev/eb6bc7f18024
>  >>
>  >> If so, this patch seems fine for -stable.  We just have to make sure it
>  >> applies correctly, etc.
>  >
>  > Agreed.
>  >
>  > I don't see why the patch would be rejected for -stable. It is a fix,
>  > proofed to work, and simple enough for everybody to understand what it is
>  > doing.
>  >
>  > The kernel documents are guidances, not absolute rules. In the end, good
>  > sense is the main rule for a patch to be applied or not.
>  >
>  > ---
>  >
>  > Next time, please ask first for us to submit a patch to mainstream or
>  > -stable before complaining why it weren't submitted.
>  >
>  > Side note: after reviewing the entire thread, and finally understanding
>  > the hole picture, it seems that you've implicitly asked. The better is to
>  > send an objective email. Something like:
>  >       Subject: [PATCH -stable] Please send patch xxxx to -stable
>  >
>  > Requesting to add a patch in the middle of a thread generally means that
>  > the patch won't be handled as so. The better is to send a separate e-mail,
>  > with the word [PATCH] at the subject, copying the one who will be
>  > responsible for applying it at the tree (the driver maintainer or me), for
>  > this to be handled. In the case of patches for -stable, please c/c
>  > mkrufky.
>
>
>
>  Guys,
>
>  Please test this patch against 2.6.24.4 -stable.
>
>  I don't have this hardware, or any way to test this myself, so I will wait on your feedback before sending this to the -stable team.  (Please try to test it and get back to me quickly -- I'd like to send this over before the 2.6.24.5 review cycle begins)


I also uploaded the patch to linuxtv.org, in case of mailer whitespace-mangling:

http://linuxtv.org/~mkrufky/stable/2.6.24.y/0002-DVB-tda10086-make-the-22kHz-tone-for-DISEQC-a-conf.patch

Please test.

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[ldvb]

On Fri, 4 Apr 2008, hermann pitton wrote:

> should we really let hang it like this on 2.6.24?
if You are talking about these card, so, I'm using it on 2.6.25.rc-last 
without any strange effects.


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[ldvb]

On Fri, 4 Apr 2008 ldvb@ns.bog.msu.ru wrote:

>> should we really let hang it like this on 2.6.24?
> if You are talking about these card, so, I'm using it on 2.6.25.rc-last
> without any strange effects.
Ah! sorry!
with some changes in registers, it was stressed 2 weeks ago.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

Michael Krufky wrote:
> On Fri, Apr 4, 2008 at 8:56 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> >  Guys,
> >
> >  Please test this patch against 2.6.24.4 -stable.
> >
> >  I don't have this hardware, or any way to test this myself, so I will wait on your feedback before sending this to the -stable team.  (Please try to test it and get back to me quickly -- I'd like to send this over before the 2.6.24.5 review cycle begins)
> 
> 
> I also uploaded the patch to linuxtv.org, in case of mailer whitespace-mangling:
> 
> http://linuxtv.org/~mkrufky/stable/2.6.24.y/0002-DVB-tda10086-make-the-22kHz-tone-for-DISEQC-a-conf.patch
> 
> Please test.

The following devices are affected by the patch:

driver: budget
- Technontrend DVB-S 1401, pci subsystem id: 13c2:1018

driver ttusb2:
- USB_PID_PCTV_400E
- USB_PID_PCTV_450E

driver: saa7134
- SAA7134_BOARD_FLYDVB_TRIO
- SAA7134_BOARD_MEDION_MD8800_QUADRO
- SAA7134_BOARD_FLYDVBS_LR300
- SAA7134_BOARD_PHILIPS_SNAKE
- SAA7134_BOARD_MD7134_BRIDGE_2

Sorry, cannot do any tests, I do not own any of these devices.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi,

Am Freitag, den 04.04.2008, 19:59 +0200 schrieb Oliver Endriss:
> Michael Krufky wrote:
> > On Fri, Apr 4, 2008 at 8:56 AM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> > >  Guys,
> > >
> > >  Please test this patch against 2.6.24.4 -stable.
> > >
> > >  I don't have this hardware, or any way to test this myself, so I will wait on your feedback before sending this to the -stable team.  (Please try to test it and get back to me quickly -- I'd like to send this over before the 2.6.24.5 review cycle begins)
> > 
> > 
> > I also uploaded the patch to linuxtv.org, in case of mailer whitespace-mangling:
> > 
> > http://linuxtv.org/~mkrufky/stable/2.6.24.y/0002-DVB-tda10086-make-the-22kHz-tone-for-DISEQC-a-conf.patch
> > 
> > Please test.
> 
> The following devices are affected by the patch:
> 
> driver: budget
> - Technontrend DVB-S 1401, pci subsystem id: 13c2:1018
> 
> driver ttusb2:
> - USB_PID_PCTV_400E
> - USB_PID_PCTV_450E
> 
> driver: saa7134
> - SAA7134_BOARD_FLYDVB_TRIO
> - SAA7134_BOARD_MEDION_MD8800_QUADRO
> - SAA7134_BOARD_FLYDVBS_LR300
> - SAA7134_BOARD_PHILIPS_SNAKE
> - SAA7134_BOARD_MD7134_BRIDGE_2
> 
> Sorry, cannot do any tests, I do not own any of these devices.
> 
> CU
> Oliver
> 

good, we are likely not dead by external bureaucracy then, but explicit
tests on 2.6.24 are needed.

For saa7134 only the FLYBVBS_LR300 and the FLYDVB_TRIO are on 2.6.24.

Here are two slightly different versions of the MEDION_MD8800_QUADRO,
one in an orange MSI nforce3 amd64 and one in a normal PCI slot, means
only the first 16be:0007 subdevice is functional, but I can use the
second LNB connector for loop through to an external receiver.

Also one of the new Medion/Creatix triple CTX948 low profile PCI cards,
a version sold in Austria, which is auto detected as 16be:0005 and
covered by the MD8800 config. We might add it to the name string.

I would have to down port all our new stuff, including isl6405 support,
to 2.6.24 and likely that is not the sort of test intended.

BTW, the patch in question is in 2.6.25, but none of the new DVB-S
support.

Andrew, since you are waiting for the fix on 2.6.24, can you test the
patch on 2.6.24.4 and report?

Thanks,
Hermann






--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi,

Am Freitag, den 04.04.2008, 18:17 +0400 schrieb ldvb@ns.bog.msu.ru:
> 
> On Fri, 4 Apr 2008 ldvb@ns.bog.msu.ru wrote:
> 
> >> should we really let hang it like this on 2.6.24?
> > if You are talking about these card, so, I'm using it on 2.6.25.rc-last
> > without any strange effects.
> Ah! sorry!
> with some changes in registers, it was stressed 2 weeks ago.
> 

thanks a lot, that problem is only on 2.6.24.

Michael Krufky could just need one confirming that with the patch it is
almost like on 2.6.23 to get it to stable 2.6.24.

Hartmut's config option patch is already on 2.6.25.

Let know if I can test something else, but on Hotbird 13.0E I get all
what I get with an external receiver too, but there is nothing with high
symbol rates.

Cheers,
Hermann




_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[mkrufky]

hermann pitton wrote:
> Hi,
>
> Am Freitag, den 04.04.2008, 19:59 +0200 schrieb Oliver Endriss:
>   
>> Michael Krufky wrote:
>>     
>>> On Fri, Apr 4, 2008 at 8:56 AM, Michael Krufky <mkrufky@linuxtv.org>
wrote:
>>>       
>>>>  Guys,
>>>>
>>>>  Please test this patch against 2.6.24.4 -stable.
>>>>
>>>>  I don't have this hardware, or any way to test this myself, so I will
wait on your feedback before sending this to the -stable team.  (Please try
to test it and get back to me quickly -- I'd like to send this over before
the 2.6.24.5 review cycle begins)
>>>>         
>>> I also uploaded the patch to linuxtv.org, in case of mailer
whitespace-mangling:
>>>
>>>
http://linuxtv.org/~mkrufky/stable/2.6.24.y/0002-DVB-tda10086-make-the-22kHz
-tone-for-DISEQC-a-conf.patch
>>>
>>> Please test.
>>>       
>> The following devices are affected by the patch:
>>
>> driver: budget
>> - Technontrend DVB-S 1401, pci subsystem id: 13c2:1018
>>
>> driver ttusb2:
>> - USB_PID_PCTV_400E
>> - USB_PID_PCTV_450E
>>
>> driver: saa7134
>> - SAA7134_BOARD_FLYDVB_TRIO
>> - SAA7134_BOARD_MEDION_MD8800_QUADRO
>> - SAA7134_BOARD_FLYDVBS_LR300
>> - SAA7134_BOARD_PHILIPS_SNAKE
>> - SAA7134_BOARD_MD7134_BRIDGE_2
>>
>> Sorry, cannot do any tests, I do not own any of these devices.
>>
>> CU
>> Oliver
>>
>>     
>
> good, we are likely not dead by external bureaucracy then, but explicit
> tests on 2.6.24 are needed.
>
> For saa7134 only the FLYBVBS_LR300 and the FLYDVB_TRIO are on 2.6.24.
>
> Here are two slightly different versions of the MEDION_MD8800_QUADRO,
> one in an orange MSI nforce3 amd64 and one in a normal PCI slot, means
> only the first 16be:0007 subdevice is functional, but I can use the
> second LNB connector for loop through to an external receiver.
>
> Also one of the new Medion/Creatix triple CTX948 low profile PCI cards,
> a version sold in Austria, which is auto detected as 16be:0005 and
> covered by the MD8800 config. We might add it to the name string.
>
> I would have to down port all our new stuff, including isl6405 support,
> to 2.6.24 and likely that is not the sort of test intended.
>
> BTW, the patch in question is in 2.6.25, but none of the new DVB-S
> support.
>
> Andrew, since you are waiting for the fix on 2.6.24, can you test the
> patch on 2.6.24.4 and report?

...all of this noise was made, and now not a single person is willing to 
test the proposed solution?

I don't think that there will be many more 2.6.24.y releases.  I have an 
ivtv patch queued for 2.6.24.5, and this tda10086 patch is sitting in my 
outbox, waiting for test results.

I suspect that 2.6.25 will be released in a few days, after which, 
2.6.24.y -stable release turnaround gets slower and slower, and most 
likely will end by the time 2.6.26 is released.

If you want this fixed, then the fix needs testing .... NOW.


Regards,

Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi,

Am Dienstag, den 08.04.2008, 17:01 -0400 schrieb mkrufky@linuxtv.org:
> hermann pitton wrote:
> > Hi,
> >
> > Am Freitag, den 04.04.2008, 19:59 +0200 schrieb Oliver Endriss:
> >   
> >> Michael Krufky wrote:
> >>     
> >>> On Fri, Apr 4, 2008 at 8:56 AM, Michael Krufky <mkrufky@linuxtv.org>
> wrote:
> >>>       
> >>>>  Guys,
> >>>>
> >>>>  Please test this patch against 2.6.24.4 -stable.
> >>>>
> >>>>  I don't have this hardware, or any way to test this myself, so I will
> wait on your feedback before sending this to the -stable team.  (Please try
> to test it and get back to me quickly -- I'd like to send this over before
> the 2.6.24.5 review cycle begins)
> >>>>         
> >>> I also uploaded the patch to linuxtv.org, in case of mailer
> whitespace-mangling:
> >>>
> >>>
> http://linuxtv.org/~mkrufky/stable/2.6.24.y/0002-DVB-tda10086-make-the-22kHz
> -tone-for-DISEQC-a-conf.patch
> >>>
> >>> Please test.
> >>>       
> >> The following devices are affected by the patch:
> >>
> >> driver: budget
> >> - Technontrend DVB-S 1401, pci subsystem id: 13c2:1018
> >>
> >> driver ttusb2:
> >> - USB_PID_PCTV_400E
> >> - USB_PID_PCTV_450E
> >>
> >> driver: saa7134
> >> - SAA7134_BOARD_FLYDVB_TRIO
> >> - SAA7134_BOARD_MEDION_MD8800_QUADRO
> >> - SAA7134_BOARD_FLYDVBS_LR300
> >> - SAA7134_BOARD_PHILIPS_SNAKE
> >> - SAA7134_BOARD_MD7134_BRIDGE_2
> >>
> >> Sorry, cannot do any tests, I do not own any of these devices.
> >>
> >> CU
> >> Oliver
> >>
> >>     
> >
> > good, we are likely not dead by external bureaucracy then, but explicit
> > tests on 2.6.24 are needed.
> >
> > For saa7134 only the FLYBVBS_LR300 and the FLYDVB_TRIO are on 2.6.24.
> >
> > Here are two slightly different versions of the MEDION_MD8800_QUADRO,
> > one in an orange MSI nforce3 amd64 and one in a normal PCI slot, means
> > only the first 16be:0007 subdevice is functional, but I can use the
> > second LNB connector for loop through to an external receiver.
> >
> > Also one of the new Medion/Creatix triple CTX948 low profile PCI cards,
> > a version sold in Austria, which is auto detected as 16be:0005 and
> > covered by the MD8800 config. We might add it to the name string.
> >
> > I would have to down port all our new stuff, including isl6405 support,
> > to 2.6.24 and likely that is not the sort of test intended.
> >
> > BTW, the patch in question is in 2.6.25, but none of the new DVB-S
> > support.
> >
> > Andrew, since you are waiting for the fix on 2.6.24, can you test the
> > patch on 2.6.24.4 and report?
> 
> ...all of this noise was made, and now not a single person is willing to 
> test the proposed solution?
> 
> I don't think that there will be many more 2.6.24.y releases.  I have an 
> ivtv patch queued for 2.6.24.5, and this tda10086 patch is sitting in my 
> outbox, waiting for test results.
> 
> I suspect that 2.6.25 will be released in a few days, after which, 
> 2.6.24.y -stable release turnaround gets slower and slower, and most 
> likely will end by the time 2.6.26 is released.
> 
> If you want this fixed, then the fix needs testing .... NOW.
> 
> 
> Regards,
> 
> Mike

Mike, we know Hartmut's fix is correct and do use it on v4l-dvb master.

I have nothing supported on 2.6.24, if you seriously want me to down
port the new cards to 2.6.24.4, I do that, but scratch my head.

Andrew Junew with a TT S-1401 is willing to help, but fairly new to
linux. I try to talk him through a 2.6.24.4 vanilla build, test, then
apply the patch, test again and report.

Cheers,
Hermann




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Oliver Endriss]

mkrufky@linuxtv.org wrote:
> ...
> ...all of this noise was made, and now not a single person is willing to 
> test the proposed solution?
> 
> I don't think that there will be many more 2.6.24.y releases.  I have an 
> ivtv patch queued for 2.6.24.5, and this tda10086 patch is sitting in my 
> outbox, waiting for test results.
> 
> I suspect that 2.6.25 will be released in a few days, after which, 
> 2.6.24.y -stable release turnaround gets slower and slower, and most 
> likely will end by the time 2.6.26 is released.
> 
> If you want this fixed, then the fix needs testing .... NOW.

Always the same story. :-(

We need a test center, or preferably a community of testers who are
willing to do regression tests with the drivers...

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Mauro Carvalho Chehab]

On Wed, 9 Apr 2008 00:27:18 +0200
Oliver Endriss <o.endriss@gmx.de> wrote:

> mkrufky@linuxtv.org wrote:
> > ...
> > ...all of this noise was made, and now not a single person is willing to 
> > test the proposed solution?
> > 
> > I don't think that there will be many more 2.6.24.y releases.  I have an 
> > ivtv patch queued for 2.6.24.5, and this tda10086 patch is sitting in my 
> > outbox, waiting for test results.
> > 
> > I suspect that 2.6.25 will be released in a few days, after which, 
> > 2.6.24.y -stable release turnaround gets slower and slower, and most 
> > likely will end by the time 2.6.26 is released.
> > 
> > If you want this fixed, then the fix needs testing .... NOW.
> 
> Always the same story. :-(
> 
> We need a test center, or preferably a community of testers who are
> willing to do regression tests with the drivers...

Agreed.

Michael,

About this specific patch, I don't see any reason why not forwarding it to
2.6.24. There were some reports already about this fixing some broken LNA.


Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Hi Andrew,

Am Dienstag, den 08.04.2008, 19:34 +0400 schrieb Andrew Junev:
> Hello Hermann,
> 
> Monday, April 7, 2008, 2:58:05 AM, you wrote:
> 
> > you always drop the lists.
> 
> Not always. :) I do it just sometimes, when I feel my message doesn't
> contain useful information for everybody on the list.
> But we can move back to the lists, if you think it's more appropriate.
> 
> > I come back to you, if nobody else who is more fluently in just add a
> > patch and compile a vanilla kernel does not move in. 
> 
> Well, I believe I can do it, if noone else does. It shouldn't be that
> hard.
> 
> > I of course know for sure the fix is correct, but the stable team wants
> > a report from a user on 2.6.24 and support for my stuff is new and it is
> > nonsense to bring it down to 2.6.24 to demonstrate it working for
> > someone on 2.6.24 ...
> 
> I wonder how the unpatched driver made its way to 2.6.24 stable...
> Or maybe it's just me who gets affected by this problem that much.
> 
> > B.T.W, why you don't use at least the v4l-dvb master stuff to come over
> > it. Needs no patching :)
> 
> If I ever need to move to 2.6.24 and it gets no patch included by
> then, I'll surely do so! :)
> At the moment I'm perfectly fine with 2.6.23...
> 

however it will go out for now, seems in the end you will have something
to test ;)

Cheers,
Hermann


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Andrew Junev]

> Hi Andrew,

> Am Dienstag, den 08.04.2008, 19:34 +0400 schrieb Andrew Junev:
>> Hello Hermann,
>> 
>> Monday, April 7, 2008, 2:58:05 AM, you wrote:
>> 
>> > you always drop the lists.
>> 
>> Not always. :) I do it just sometimes, when I feel my message doesn't
>> contain useful information for everybody on the list.
>> But we can move back to the lists, if you think it's more appropriate.
>> 
>> > I come back to you, if nobody else who is more fluently in just add a
>> > patch and compile a vanilla kernel does not move in. 
>> 
>> Well, I believe I can do it, if noone else does. It shouldn't be that
>> hard.
>> 
>> > I of course know for sure the fix is correct, but the stable team wants
>> > a report from a user on 2.6.24 and support for my stuff is new and it is
>> > nonsense to bring it down to 2.6.24 to demonstrate it working for
>> > someone on 2.6.24 ...
>> 
>> I wonder how the unpatched driver made its way to 2.6.24 stable...
>> Or maybe it's just me who gets affected by this problem that much.
>> 
>> > B.T.W, why you don't use at least the v4l-dvb master stuff to come over
>> > it. Needs no patching :)
>> 
>> If I ever need to move to 2.6.24 and it gets no patch included by
>> then, I'll surely do so! :)
>> At the moment I'm perfectly fine with 2.6.23...
>> 

> however it will go out for now, seems in the end you will have something
> to test ;)


I have no problems with that! :)

Ok, can you point me to a guide on how to do this? Otherwise I'm
affraid I'll waste lots of time just by trying something that I should
not...

I'm ready to test it sometime this week.

-- 
Best regards,
 Andrew


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Am Mittwoch, den 09.04.2008, 10:17 +0400 schrieb Andrew Junev:
> > Hi Andrew,
> 
> > Am Dienstag, den 08.04.2008, 19:34 +0400 schrieb Andrew Junev:
> >> Hello Hermann,
> >> 
> >> Monday, April 7, 2008, 2:58:05 AM, you wrote:
> >> 
> >> > you always drop the lists.
> >> 
> >> Not always. :) I do it just sometimes, when I feel my message doesn't
> >> contain useful information for everybody on the list.
> >> But we can move back to the lists, if you think it's more appropriate.
> >> 
> >> > I come back to you, if nobody else who is more fluently in just add a
> >> > patch and compile a vanilla kernel does not move in. 
> >> 
> >> Well, I believe I can do it, if noone else does. It shouldn't be that
> >> hard.
> >> 
> >> > I of course know for sure the fix is correct, but the stable team wants
> >> > a report from a user on 2.6.24 and support for my stuff is new and it is
> >> > nonsense to bring it down to 2.6.24 to demonstrate it working for
> >> > someone on 2.6.24 ...
> >> 
> >> I wonder how the unpatched driver made its way to 2.6.24 stable...
> >> Or maybe it's just me who gets affected by this problem that much.
> >> 
> >> > B.T.W, why you don't use at least the v4l-dvb master stuff to come over
> >> > it. Needs no patching :)
> >> 
> >> If I ever need to move to 2.6.24 and it gets no patch included by
> >> then, I'll surely do so! :)
> >> At the moment I'm perfectly fine with 2.6.23...
> >> 
> 
> > however it will go out for now, seems in the end you will have something
> > to test ;)
> 
> 
> I have no problems with that! :)
> 
> Ok, can you point me to a guide on how to do this? Otherwise I'm
> affraid I'll waste lots of time just by trying something that I should
> not...
> 
> I'm ready to test it sometime this week.
> 

Hi Andrew,

Mike has forwarded the patch to the stable kernel team. (Thanks!)

Likely it will be fixed in 2.6.24.5 then.

To build a vanilla kernel is still a very easy task, but there are
distribution specific helper scripts and customs.

The real problem, that could appear, is that dependencies on other
utilities are not resolved on your current distribution version anymore
and you run into some circular dependencies, not easy to resolve and
then you must know what you are doing exactly or upgrade.

If a 2.6.24 is available for your current stuff, just install it and see
the missing. If you then install the kernel source for it, we can apply
the patch also there and build a new kernel.

Cheers,
Hermann




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[Andrew Junev]

Thursday, April 10, 2008, 3:03:10 AM, you wrote:

> Am Mittwoch, den 09.04.2008, 10:17 +0400 schrieb Andrew Junev:
>> > Hi Andrew,
>> 
>> > Am Dienstag, den 08.04.2008, 19:34 +0400 schrieb Andrew Junev:
>> >> Hello Hermann,
>> >> 
>> >> Monday, April 7, 2008, 2:58:05 AM, you wrote:
>> >> 
>> >> > you always drop the lists.
>> >> 
>> >> Not always. :) I do it just sometimes, when I feel my message doesn't
>> >> contain useful information for everybody on the list.
>> >> But we can move back to the lists, if you think it's more appropriate.
>> >> 
>> >> > I come back to you, if nobody else who is more fluently in just add a
>> >> > patch and compile a vanilla kernel does not move in. 
>> >> 
>> >> Well, I believe I can do it, if noone else does. It shouldn't be that
>> >> hard.
>> >> 
>> >> > I of course know for sure the fix is correct, but the stable team wants
>> >> > a report from a user on 2.6.24 and support for my stuff is new and it is
>> >> > nonsense to bring it down to 2.6.24 to demonstrate it working for
>> >> > someone on 2.6.24 ...
>> >> 
>> >> I wonder how the unpatched driver made its way to 2.6.24 stable...
>> >> Or maybe it's just me who gets affected by this problem that much.
>> >> 
>> >> > B.T.W, why you don't use at least the v4l-dvb master stuff to come over
>> >> > it. Needs no patching :)
>> >> 
>> >> If I ever need to move to 2.6.24 and it gets no patch included by
>> >> then, I'll surely do so! :)
>> >> At the moment I'm perfectly fine with 2.6.23...
>> >> 
>> 
>> > however it will go out for now, seems in the end you will have something
>> > to test ;)
>> 
>> 
>> I have no problems with that! :)
>> 
>> Ok, can you point me to a guide on how to do this? Otherwise I'm
>> affraid I'll waste lots of time just by trying something that I should
>> not...
>> 
>> I'm ready to test it sometime this week.
>> 

> Hi Andrew,

> Mike has forwarded the patch to the stable kernel team. (Thanks!)

> Likely it will be fixed in 2.6.24.5 then.

> To build a vanilla kernel is still a very easy task, but there are
> distribution specific helper scripts and customs.

> The real problem, that could appear, is that dependencies on other
> utilities are not resolved on your current distribution version anymore
> and you run into some circular dependencies, not easy to resolve and
> then you must know what you are doing exactly or upgrade.

> If a 2.6.24 is available for your current stuff, just install it and see
> the missing. If you then install the kernel source for it, we can apply
> the patch also there and build a new kernel.

> Cheers,
> Hermann


Sorry for my slow response...
I just installed kernel 2.6.24.5 and my S-1401 works good now!

Thanks a million to everyone who was involved!

And once again sorry for not providing my feedback fast enough.


-- 
Best regards,
 Andrew

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton]

Am Dienstag, den 13.05.2008, 19:55 +0400 schrieb Andrew Junev:
> Thursday, April 10, 2008, 3:03:10 AM, you wrote:
> 
> > Am Mittwoch, den 09.04.2008, 10:17 +0400 schrieb Andrew Junev:
> >> > Hi Andrew,
> >> 
> >> > Am Dienstag, den 08.04.2008, 19:34 +0400 schrieb Andrew Junev:
> >> >> Hello Hermann,
> >> >> 
> >> >> Monday, April 7, 2008, 2:58:05 AM, you wrote:
> >> >> 
> >> >> > you always drop the lists.
> >> >> 
> >> >> Not always. :) I do it just sometimes, when I feel my message doesn't
> >> >> contain useful information for everybody on the list.
> >> >> But we can move back to the lists, if you think it's more appropriate.
> >> >> 
> >> >> > I come back to you, if nobody else who is more fluently in just add a
> >> >> > patch and compile a vanilla kernel does not move in. 
> >> >> 
> >> >> Well, I believe I can do it, if noone else does. It shouldn't be that
> >> >> hard.
> >> >> 
> >> >> > I of course know for sure the fix is correct, but the stable team wants
> >> >> > a report from a user on 2.6.24 and support for my stuff is new and it is
> >> >> > nonsense to bring it down to 2.6.24 to demonstrate it working for
> >> >> > someone on 2.6.24 ...
> >> >> 
> >> >> I wonder how the unpatched driver made its way to 2.6.24 stable...
> >> >> Or maybe it's just me who gets affected by this problem that much.
> >> >> 
> >> >> > B.T.W, why you don't use at least the v4l-dvb master stuff to come over
> >> >> > it. Needs no patching :)
> >> >> 
> >> >> If I ever need to move to 2.6.24 and it gets no patch included by
> >> >> then, I'll surely do so! :)
> >> >> At the moment I'm perfectly fine with 2.6.23...
> >> >> 
> >> 
> >> > however it will go out for now, seems in the end you will have something
> >> > to test ;)
> >> 
> >> 
> >> I have no problems with that! :)
> >> 
> >> Ok, can you point me to a guide on how to do this? Otherwise I'm
> >> affraid I'll waste lots of time just by trying something that I should
> >> not...
> >> 
> >> I'm ready to test it sometime this week.
> >> 
> 
> > Hi Andrew,
> 
> > Mike has forwarded the patch to the stable kernel team. (Thanks!)
> 
> > Likely it will be fixed in 2.6.24.5 then.
> 
> > To build a vanilla kernel is still a very easy task, but there are
> > distribution specific helper scripts and customs.
> 
> > The real problem, that could appear, is that dependencies on other
> > utilities are not resolved on your current distribution version anymore
> > and you run into some circular dependencies, not easy to resolve and
> > then you must know what you are doing exactly or upgrade.
> 
> > If a 2.6.24 is available for your current stuff, just install it and see
> > the missing. If you then install the kernel source for it, we can apply
> > the patch also there and build a new kernel.
> 
> > Cheers,
> > Hermann
> 
> 
> Sorry for my slow response...
> I just installed kernel 2.6.24.5 and my S-1401 works good now!
> 
> Thanks a million to everyone who was involved!
> 
> And once again sorry for not providing my feedback fast enough.
> 

Hi Andrew,

thanks for your report!

If someone would have been able to jump in earlier, it would have caused
less noise.

Maybe it is good for something.

Some others have noticed, that we don't have always the fully testing
capabilities on all hardware around.

Some likely assumed until now, that this is no problem at all ...

Cheers,
Hermann


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list