Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

I've been using a PCTV Nanostick T2 USB DVB-T2 receiver (one of the few 
that supports DVB-T2) for over six months with a 3.0 kernel with no 
problems.

The key drivers in use are em28xx, cxd2820r and tda18271.

Seeing the 3.2 kernel I thought I'd upgrade and now I seem to have hit a 
problem.

The Nanostick works fine for between 5 and 25 minutes and then without 
any error messages cuts out. The TS drops to a tiny stream of non-TS 
data. It seems to contain a lot of 0x00s and 0xffs.

It looks like the problem of many years ago when the frontends would be 
shut down if they were closed for more than a few minutes. However, it 
would appear that the frontend fds are still open (according to fuser).

Some more system details:

This is running on a 32-bit system.

Everything works fine if I boot with the 3.0.0 kernel.

The user-land application is kaffeine.

There is a PCI DVB-T card in the system which operates fine even when 
the Nanostick stops producing the correct output.

I'm more than happy to build kernels and add debugging. I'm basically 
just trying to find the maintainer for these modules so we can figure 
out what's going wrong and fix it before 3.2 escapes into several 
distros and we have this problem on a larger scale.

Many thanks for your help,

Jim.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Steven Toth]

> The Nanostick works fine for between 5 and 25 minutes and then without any
> error messages cuts out. The TS drops to a tiny stream of non-TS data. It
> seems to contain a lot of 0x00s and 0xffs.

What does femon show for demodulator statistics?

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

On 10/01/12 13:54, Steven Toth wrote:
>> The Nanostick works fine for between 5 and 25 minutes and then without any
>> error messages cuts out. The TS drops to a tiny stream of non-TS data. It
>> seems to contain a lot of 0x00s and 0xffs.
> What does femon show for demodulator statistics?
>
Well... I downloaded the latest dvb-apps via mecurial from linuxtv.org 
and the following happened at the start while it was working:

status SCVYL | signal ffff | snr 00ef | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00f1 | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00ee | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00f0 | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00f2 | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00ee | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK
status SCVYL | signal ffff | snr 00f0 | ber 00000000 | unc 00000000 | 
FE_HAS_LOCK

and when it stopped working, this time an hour later, nothing had 
changed. In fact, it looks like the driver keeps lock even when it's not 
recording at all.

Any ideas anyone? Looks like the tuner is OK....

The thing that's really confusing me is the totally random amounts of 
time it takes before it fails. This time it was over an hour. For 
reference though this was the first time I'd tried it with standard 
definition transmissions. Not only lower data rate but also DVB-T rather 
than DVB-T2.

Many thanks,

Jim.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Steven Toth]

> status SCVYL | signal ffff | snr 00ee | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status SCVYL | signal ffff | snr 00f0 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
>
> and when it stopped working, this time an hour later, nothing had changed.
> In fact, it looks like the driver keeps lock even when it's not recording at
> all.
>
> Any ideas anyone? Looks like the tuner is OK....

It sounds signal, hardware or heat/environmental related, unlikely to
be driver related.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Andy Walls]

Steven Toth <stoth@kernellabs.com> wrote:

>> status SCVYL | signal ffff | snr 00ee | ber 00000000 | unc 00000000 |
>> FE_HAS_LOCK
>> status SCVYL | signal ffff | snr 00f0 | ber 00000000 | unc 00000000 |
>> FE_HAS_LOCK
>>
>> and when it stopped working, this time an hour later, nothing had
>changed.
>> In fact, it looks like the driver keeps lock even when it's not
>recording at
>> all.
>>
>> Any ideas anyone? Looks like the tuner is OK....
>
>It sounds signal, hardware or heat/environmental related, unlikely to
>be driver related.
>
>-- 
>Steven Toth - Kernel Labs
>http://www.kernellabs.com
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Any chance that transfer buffers are being slowly dropped out of rotation?

That would explain captures stopping after a variable amount of time.  (Early cx18 driver versions had that problem.)

Regards,
Andy

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Antti Palosaari]

On 01/10/2012 03:28 PM, Jim Darby wrote:
> I've been using a PCTV Nanostick T2 USB DVB-T2 receiver (one of the few
> that supports DVB-T2) for over six months with a 3.0 kernel with no
> problems.
>
> The key drivers in use are em28xx, cxd2820r and tda18271.
>
> Seeing the 3.2 kernel I thought I'd upgrade and now I seem to have hit a
> problem.

Do you have possibility to test Kernel 3.1?
Also latest LinuxTV.org devel could be interesting to see. There is one 
patch that changes em28xx driver endpoint configuration. But as that 
patch is going for 3.3 it should not be cause of issue, but I wonder if 
it could fix... Use media_build.git if possible.

> The Nanostick works fine for between 5 and 25 minutes and then without
> any error messages cuts out. The TS drops to a tiny stream of non-TS
> data. It seems to contain a lot of 0x00s and 0xffs.
>
> It looks like the problem of many years ago when the frontends would be
> shut down if they were closed for more than a few minutes. However, it
> would appear that the frontend fds are still open (according to fuser).
>
> Some more system details:
>
> This is running on a 32-bit system.
>
> Everything works fine if I boot with the 3.0.0 kernel.
>
> The user-land application is kaffeine.
>
> There is a PCI DVB-T card in the system which operates fine even when
> the Nanostick stops producing the correct output.

Which is that card? I wonder if there is same drivers used like tda18271...

> I'm more than happy to build kernels and add debugging. I'm basically
> just trying to find the maintainer for these modules so we can figure
> out what's going wrong and fix it before 3.2 escapes into several
> distros and we have this problem on a larger scale.

I am maintainer of the cxd2820r. Mike knows tda18271 and maybe Mauro 
em28xx...

> Many thanks for your help,
>
> Jim.


Antti
-- 
http://palosaari.fi/

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

I thought I'd batch all the answers together.

Andy suggested something about transfer buffers being dropped out of 
rotation. I'm not sure exactly what this is but if it's anything like 
ethernet buffering it would explain it. It would also explain why it 
lasts longer on the lower bit rate standard definition TV rather than HDTV.

In response to Antti's question, I have indeed tested kernel 3.1.6. This 
was where I originally noticed the problem. I upgraded to 3.2.0 to see 
if had been fixed and when I found that it hadn't posted here.

I pulled the LinuxTV.org v4l-dvb from mercurial but it looks more like a 
patch than a full kernel (the previous one I pulled seven months ago was 
a complete kernel). For reference the 3.0.0+ kernel that came from 
LinuxTV.org v4l-dvb seven months ago has functioned flawlessly ever since.

I've just downloaded the media_build.git stuff, installed the extra 
packages it needed and it's be building now.

The other card in the system is a very old Nova-T. It's got a LSI L64781 
frontend on it.

Finally Steven said that it might be signal, hardware or heat related. 
I'm unsure of this because if I boot the machine with the 3.0.0+ kernel 
with exactly the same user-land everything it functions perfectly and 
has done for months.

I'll report back on my adventures with the media_build changes to the 
3.2 kernel.

Best regards,

Jim.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

On 11/01/12 01:05, Antti Palosaari wrote:
> [snip]
> Also latest LinuxTV.org devel could be interesting to see. There is 
> one patch that changes em28xx driver endpoint configuration. But as 
> that patch is going for 3.3 it should not be cause of issue, but I 
> wonder if it could fix... Use media_build.git if possible.

Well, I built the kernel and installed it. Sadly I get entries of the 
form: "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 
call to delivery system 0" which isn't what I was looking for. I guess 
there's a new API? It would appear this is from the set frontend call.

This is most annoying as I'd like to try out the newest code.

Is there a v3 to v3 transition document anywhere?

Best regards,

Jim.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Simon Jones]

On 10 January 2012 13:28, Jim Darby <uberscubajim@gmail.com> wrote:
> I've been using a PCTV Nanostick T2 USB DVB-T2 receiver (one of the few that
> supports DVB-T2) for over six months with a 3.0 kernel with no problems.
>

> Seeing the 3.2 kernel I thought I'd upgrade and now I seem to have hit a
> problem.
>

> This is running on a 32-bit system.
>
> Everything works fine if I boot with the 3.0.0 kernel.
>

I have this tuner in Arch x64, with 2 Dual DVB-T and a dual DVB-S2
(Tevii S660), kernel 3.2 rc7 working perfect.

I do have it in a usb3 port due to an issue with the usb drivers for
the motherboard I have, I found that there is bugs in the drivers for
usb2 chipset so the work around is I use usb3.

I have had this tuner work in 3.0 and 3.1 kernel as well, no issues....

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Gianluca Gennari]

Il 11/01/2012 20:19, Jim Darby ha scritto:
> On 11/01/12 01:05, Antti Palosaari wrote:
>> [snip]
>> Also latest LinuxTV.org devel could be interesting to see. There is
>> one patch that changes em28xx driver endpoint configuration. But as
>> that patch is going for 3.3 it should not be cause of issue, but I
>> wonder if it could fix... Use media_build.git if possible.
> 
> Well, I built the kernel and installed it. Sadly I get entries of the
> form: "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3
> call to delivery system 0" which isn't what I was looking for. I guess
> there's a new API? It would appear this is from the set frontend call.
> 
> This is most annoying as I'd like to try out the newest code.
> 
> Is there a v3 to v3 transition document anywhere?
> 
> Best regards,
> 
> Jim.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Hi Jim,
you spotted a regression in the latest media_build release from
11/01/2012.
I had the same problem here:

"dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
delivery system 0"

with 3 totally different sticks (em28xx, dvb-usb, as102).

Everything was working fine with media_build drivers from 08/01/2011, so
the problem originates from a patch committed in the last few days.

In fact, I reverted this patch:

http://patchwork.linuxtv.org/patch/9443/

and Kaffeine started working again with all my DVB-T sticks.

Best regards,
Gianluca

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

On 12/01/12 16:22, Gianluca Gennari wrote:
> Hi Jim,
> you spotted a regression in the latest media_build release from
> 11/01/2012.
> I had the same problem here:
>
> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0"
>
> with 3 totally different sticks (em28xx, dvb-usb, as102).
>
> Everything was working fine with media_build drivers from 08/01/2011, so
> the problem originates from a patch committed in the last few days.
>
> In fact, I reverted this patch:
>
> http://patchwork.linuxtv.org/patch/9443/
>
> and Kaffeine started working again with all my DVB-T sticks.
>
> Best regards,
> Gianluca

I think that we need to be careful about two different problems here.

The first is the regression that I originally reported. In this case the 
device stops sending data after a variable period of time and we get to 
miss the end of the programme that we're watching.

The second, which is the one that Gianluca has spotted as well, is that 
there seems to be some form of API change in the latest linux-media 
which is causing kaffeine to stop working.

I'm still unsure about the first. It might be a 32/64-bit problem (based 
on evidence from Simon Jones), it might be flaky hardware or it might be 
a real problem. I'm planning to build the 3.2.0 kernel (minus the 
linux-media patches) for 64-bit on different hardware and see what happens.

As for the second I suspect it might be a kaffeine problem. It might 
just need recompiling with the new headers or it might need some work on 
it. I'll investigate that after I've solved the first regression.

Pedant mode: the kaffeine problem isn't really a regression as such. 
It's more of a API versioning issue. More on this later.

Hope this helps,

Jim.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Simon Jones]

> I'm still unsure about the first. It might be a 32/64-bit problem (based on
> evidence from Simon Jones), it might be flaky hardware or it might be a real
> problem. I'm planning to build the 3.2.0 kernel (minus the linux-media
> patches) for 64-bit on different hardware and see what happens.
>
> As for the second I suspect it might be a kaffeine problem. It might just
> need recompiling with the new headers or it might need some work on it. I'll
> investigate that after I've solved the first regression.
>

Might have been a bit prem on the working perfect.... cam home to the
wife saying the system has crashed... looked in the logs and this is
reported:

Jan 12 05:27:59 localhost kernel: [308040.577546] xhci_hcd
0000:02:00.0: WARN: buffer overrun event on endpoint
---> This error has occured since I built the system at christmas,
have been ignoring it because it didn't seem to cause any issues.

Jan 12 05:33:03 localhost kernel: [308344.766507] xhci_hcd
0000:02:00.0: WARN: babble error on endpoint
Jan 12 05:33:03 localhost kernel: [308344.766541] hub 1-0:1.0: port 1
disabled by hub (EMI?), re-enabling...
Jan 12 05:33:03 localhost kernel: [308344.766546] usb 1-1: USB
disconnect, device number 2
Jan 12 05:33:03 localhost kernel: [308344.766602] em28xx #0:
disconnecting em28xx #0 video
Jan 12 05:33:04 localhost kernel: [308344.805942] cxd2820r: i2c rd
failed ret:-19 reg:10 len:1
Jan 12 05:33:04 localhost kernel: [308344.849191] cxd2820r: i2c rd
failed ret:-19 reg:26 len:2
Jan 12 05:33:04 localhost kernel: [308344.859414] em28xx #0: V4L2
device video0 deregistered
Jan 12 05:33:04 localhost kernel: [308344.889276] cxd2820r: i2c rd
failed ret:-19 reg:28 len:2
Jan 12 05:36:00 localhost kernel: [308521.689250] INFO: task khubd:140
blocked for more than 120 seconds.
Jan 12 05:36:00 localhost kernel: [308521.689256] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 12 05:36:00 localhost kernel: [308521.689262] khubd           D
0000000105821dfa     0   140      2 0x00000000
Jan 12 05:36:00 localhost kernel: [308521.689272]  ffff8804227e9b80
0000000000000046 ffff880400000000 00000000435d27dc
Jan 12 05:36:00 localhost kernel: [308521.689282]  ffff880423637200
ffff8804227e9fd8 ffff8804227e9fd8 ffff8804227e9fd8
Jan 12 05:36:00 localhost kernel: [308521.689290]  ffff8804244cf200
ffff880423637200 ffff8804227e9b30 ffffffff814156f8
Jan 12 05:36:00 localhost kernel: [308521.689299] Call Trace:
Jan 12 05:36:00 localhost kernel: [308521.689311]
[<ffffffff814156f8>] ? wait_for_common+0x128/0x160
Jan 12 05:36:00 localhost kernel: [308521.689323]
[<ffffffff8105cf70>] ? try_to_wake_up+0x290/0x290
Jan 12 05:36:00 localhost kernel: [308521.689330]
[<ffffffff8141574d>] ? wait_for_completion+0x1d/0x20
Jan 12 05:36:00 localhost kernel: [308521.689337]
[<ffffffff8141640f>] schedule+0x3f/0x60
Jan 12 05:36:00 localhost kernel: [308521.689366]
[<ffffffffa028f2c5>] dvb_unregister_frontend+0xc5/0x110 [dvb_core]
Jan 12 05:36:00 localhost kernel: [308521.689376]
[<ffffffff810868f0>] ? abort_exclusive_wait+0xb0/0xb0
Jan 12 05:36:00 localhost kernel: [308521.689386]
[<ffffffffa01fda22>] em28xx_dvb_fini+0xf2/0x150 [em28xx_dvb]
Jan 12 05:36:00 localhost kernel: [308521.689400]
[<ffffffffa037606e>] em28xx_close_extension+0x3e/0xa0 [em28xx]
Jan 12 05:36:00 localhost kernel: [308521.689410]
[<ffffffffa0373ef5>] em28xx_usb_disconnect+0xe5/0x190 [em28xx]
Jan 12 05:36:00 localhost kernel: [308521.689436]
[<ffffffffa0011242>] usb_unbind_interface+0x52/0x180 [usbcore]
Jan 12 05:36:00 localhost kernel: [308521.689448]
[<ffffffff8130071c>] __device_release_driver+0x7c/0xe0
Jan 12 05:36:00 localhost kernel: [308521.689456]
[<ffffffff813007ac>] device_release_driver+0x2c/0x40
Jan 12 05:36:00 localhost kernel: [308521.689463]
[<ffffffff81300258>] bus_remove_device+0x78/0xb0
Jan 12 05:36:00 localhost kernel: [308521.689475]
[<ffffffff812fdb5d>] device_del+0x12d/0x1b0
Jan 12 05:36:00 localhost kernel: [308521.689482]
[<ffffffffa000ef9f>] usb_disable_device+0xaf/0x1d0 [usbcore]
Jan 12 05:36:00 localhost kernel: [308521.689489]
[<ffffffffa00073a8>] usb_disconnect+0x98/0x130 [usbcore]
Jan 12 05:36:00 localhost kernel: [308521.689497]
[<ffffffffa00092fc>] hub_thread+0xa4c/0x12d0 [usbcore]
Jan 12 05:36:00 localhost kernel: [308521.689500]
[<ffffffff810868f0>] ? abort_exclusive_wait+0xb0/0xb0
Jan 12 05:36:00 localhost kernel: [308521.689507]
[<ffffffffa00088b0>] ? usb_remote_wakeup+0x40/0x40 [usbcore]
Jan 12 05:36:00 localhost kernel: [308521.689510]
[<ffffffff81085fac>] kthread+0x8c/0xa0
Jan 12 05:36:00 localhost kernel: [308521.689513]
[<ffffffff8141bd74>] kernel_thread_helper+0x4/0x10
Jan 12 05:36:00 localhost kernel: [308521.689516]
[<ffffffff81085f20>] ? kthread_worker_fn+0x190/0x190
Jan 12 05:36:00 localhost kernel: [308521.689519]
[<ffffffff8141bd70>] ? gs_change+0x13/0x13


It goes on longer than this, but think it's the same repeated
information and call stack trace etc.

But this could just be related to the usb drivers being a bit unstable
on this motherboard.

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Gianluca Gennari]

Il 12/01/2012 17:35, Jim Darby ha scritto:
> On 12/01/12 16:22, Gianluca Gennari wrote:
>> Hi Jim,
>> you spotted a regression in the latest media_build release from
>> 11/01/2012.
>> I had the same problem here:
>>
>> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0"
>>
>> with 3 totally different sticks (em28xx, dvb-usb, as102).
>>
>> Everything was working fine with media_build drivers from 08/01/2011, so
>> the problem originates from a patch committed in the last few days.
>>
>> In fact, I reverted this patch:
>>
>> http://patchwork.linuxtv.org/patch/9443/
>>
>> and Kaffeine started working again with all my DVB-T sticks.
>>
>> Best regards,
>> Gianluca
> 
> I think that we need to be careful about two different problems here.
> 
> The first is the regression that I originally reported. In this case the
> device stops sending data after a variable period of time and we get to
> miss the end of the programme that we're watching.
> 
> The second, which is the one that Gianluca has spotted as well, is that
> there seems to be some form of API change in the latest linux-media
> which is causing kaffeine to stop working.
> 
> I'm still unsure about the first. It might be a 32/64-bit problem (based
> on evidence from Simon Jones), it might be flaky hardware or it might be
> a real problem. I'm planning to build the 3.2.0 kernel (minus the
> linux-media patches) for 64-bit on different hardware and see what happens.

Yes, of course reverting that patch is not going to affect your first issue.

> As for the second I suspect it might be a kaffeine problem. It might
> just need recompiling with the new headers or it might need some work on
> it. I'll investigate that after I've solved the first regression.
> 
> Pedant mode: the kaffeine problem isn't really a regression as such.
> It's more of a API versioning issue. More on this later.
> 
> Hope this helps,
> 
> Jim.
> 

I don't think the intention of that patch was to broke support for DVBv3
applications when using a tuner with a single delivery system.
That would be quite a big API change.

Best regards,
Gianluca

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Mauro Carvalho Chehab]

Em 12-01-2012 14:22, Gianluca Gennari escreveu:
> Il 11/01/2012 20:19, Jim Darby ha scritto:
>> On 11/01/12 01:05, Antti Palosaari wrote:
>>> [snip]
>>> Also latest LinuxTV.org devel could be interesting to see. There is
>>> one patch that changes em28xx driver endpoint configuration. But as
>>> that patch is going for 3.3 it should not be cause of issue, but I
>>> wonder if it could fix... Use media_build.git if possible.
>>
>> Well, I built the kernel and installed it. Sadly I get entries of the
>> form: "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3
>> call to delivery system 0" which isn't what I was looking for. I guess
>> there's a new API? It would appear this is from the set frontend call.
>>
>> This is most annoying as I'd like to try out the newest code.
>>
>> Is there a v3 to v3 transition document anywhere?
>>
>> Best regards,
>>
>> Jim.
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> Hi Jim,
> you spotted a regression in the latest media_build release from
> 11/01/2012.
> I had the same problem here:
> 
> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
> delivery system 0"
> 
> with 3 totally different sticks (em28xx, dvb-usb, as102).
> 
> Everything was working fine with media_build drivers from 08/01/2011, so
> the problem originates from a patch committed in the last few days.
> 
> In fact, I reverted this patch:
> 
> http://patchwork.linuxtv.org/patch/9443/
> 
> and Kaffeine started working again with all my DVB-T sticks.

Hmm... this patch shouldn't be causing troubles for an application that
only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with 
SYS_UNDEFINED (0)?

If so, then Kaffeine has a bug, as it is requesting a non-existent
delivery system.

Could you please turn on the dvb-core debug, and see if it is trying to
do a DVBv5 call with DTV_DELIVERY_SYSTEM?

Thanks,
Mauro

> 
> Best regards,
> Gianluca

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Gianluca Gennari]

[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]

Il 13/01/2012 12:21, Mauro Carvalho Chehab ha scritto:
> Em 12-01-2012 14:22, Gianluca Gennari escreveu:
>> Il 11/01/2012 20:19, Jim Darby ha scritto:
>>> On 11/01/12 01:05, Antti Palosaari wrote:
>>>> [snip]
>>>> Also latest LinuxTV.org devel could be interesting to see. There is
>>>> one patch that changes em28xx driver endpoint configuration. But as
>>>> that patch is going for 3.3 it should not be cause of issue, but I
>>>> wonder if it could fix... Use media_build.git if possible.
>>>
>>> Well, I built the kernel and installed it. Sadly I get entries of the
>>> form: "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3
>>> call to delivery system 0" which isn't what I was looking for. I guess
>>> there's a new API? It would appear this is from the set frontend call.
>>>
>>> This is most annoying as I'd like to try out the newest code.
>>>
>>> Is there a v3 to v3 transition document anywhere?
>>>
>>> Best regards,
>>>
>>> Jim.
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hi Jim,
>> you spotted a regression in the latest media_build release from
>> 11/01/2012.
>> I had the same problem here:
>>
>> "dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to
>> delivery system 0"
>>
>> with 3 totally different sticks (em28xx, dvb-usb, as102).
>>
>> Everything was working fine with media_build drivers from 08/01/2011, so
>> the problem originates from a patch committed in the last few days.
>>
>> In fact, I reverted this patch:
>>
>> http://patchwork.linuxtv.org/patch/9443/
>>
>> and Kaffeine started working again with all my DVB-T sticks.
> 
> Hmm... this patch shouldn't be causing troubles for an application that
> only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with 
> SYS_UNDEFINED (0)?
> 
> If so, then Kaffeine has a bug, as it is requesting a non-existent
> delivery system.
> 
> Could you please turn on the dvb-core debug, and see if it is trying to
> do a DVBv5 call with DTV_DELIVERY_SYSTEM?
> 
> Thanks,
> Mauro
> 
>>
>> Best regards,
>> Gianluca
> 
> 

Hi Mauro,
I don't think Kaffeine is (intentionally) messing up with the delivery
system.
But maybe the issue I've reported is related to this other one.

Maybe you remember that I reported a problem on the xc2028 tuner that
was reloading all the firmwares each time a new frequency is tuned.
As a consequence, the time to switch to a new channel was much higher
that usual.

I tracked down the problem to the fact that the xc2028 is put in
power-off mode and then immediately woken-up each time Kaffeine sets a
new frequency.

I investigated the issue a bit deeper (enabling debugging also in the
dvb-core) and this is what I discovered:

[ 1635.878002] dvb_frontend_release
[ 1635.878029] xc2028 9-0061: Putting xc2028/3028 into poweroff mode.
[ 1635.878041] dvb_frontend_open
[ 1635.939253] dvb_frontend_start
[ 1635.939326] dvb_frontend_thread
[ 1635.939332] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353
DVB-T)...
[ 1635.939504] dvb_frontend_ioctl (76)
[ 1635.942896] set_delivery_system() Using delivery system to 3

So the frontend is released and then reinitialized each time a new
frequency is tuned. This strange behavior was introduced with the
conversion of drivers to the DVBv5 API; before, the frontend was
initialized just one time.

This happens with all drivers: I reproduced the same issue with a stick
using the as102 driver (which is completely different from the
em28xx-dvb driver).

Here is the relevant part of the log:

[ 2339.647230] dvb_frontend_release
[ 2339.656954] dvb_frontend_open
[ 2339.665675] dvb_frontend_start
[ 2339.665872] dvb_frontend_thread
[ 2339.665878] DVB: initialising adapter 0 frontend 0 (Sky IT Digital
Key (green led))...
[ 2339.666049] dvb_frontend_ioctl (76)
[ 2339.666053] set_delivery_system() Using delivery system to 3
[ 2339.666057] dtv_property_cache_sync() Preparing OFDM req
[ 2339.666060] dvb_frontend_add_event

I'm attaching a longer log file with 2 consecutive channel switches for
each of the 2 drivers.

I have no idea if this is a bug in Kaffeine that is triggered by the new
DVBv3 emulation logic, or a bug in the emulation logic itself.

Best regards,
Gianluca

[-- Attachment #2: debug_xc2028_3.txt --]
[-- Type: text/plain, Size: 13927 bytes --]


tune a new channel:

[ 1635.878002] dvb_frontend_release
[ 1635.878029] xc2028 9-0061: Putting xc2028/3028 into poweroff mode.
[ 1635.878041] dvb_frontend_open
[ 1635.939253] dvb_frontend_start
[ 1635.939326] dvb_frontend_thread
[ 1635.939332] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[ 1635.939504] dvb_frontend_ioctl (76)
[ 1635.942896] set_delivery_system() Using delivery system to 3
[ 1635.942901] dtv_property_cache_sync() Preparing OFDM req
[ 1635.942905] dvb_frontend_add_event
[ 1635.942922] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
[ 1635.951507] xc2028 9-0061: xc2028_set_params called
[ 1635.951513] xc2028 9-0061: generic_set_freq called
[ 1635.951517] xc2028 9-0061: should set frequency 514000 kHz
[ 1635.951521] xc2028 9-0061: check_firmware called
[ 1635.951524] xc2028 9-0061: checking firmware, user requested type=F8MHZ MTS D2633 DTV8 (216), id 0000000000000000, int_freq 4760, scode_nr 0
[ 1636.011210] xc2028 9-0061: load_firmware called
[ 1636.011215] xc2028 9-0061: seek_firmware called, want type=BASE F8MHZ MTS D2633 DTV8 (217), id 0000000000000000.
[ 1636.011225] xc2028 9-0061: Found firmware for type=BASE F8MHZ MTS (7), id 0000000000000000.
[ 1636.011232] xc2028 9-0061: Loading firmware for type=BASE F8MHZ MTS (7), id 0000000000000000.
[ 1636.043183] dvb_frontend_ioctl (69)
[ 1637.142869] xc2028 9-0061: Load init1 firmware, if exists
[ 1637.142874] xc2028 9-0061: load_firmware called
[ 1637.142878] xc2028 9-0061: seek_firmware called, want type=BASE INIT1 F8MHZ MTS D2633 DTV8 (4217), id 0000000000000000.
[ 1637.142888] xc2028 9-0061: Can't find firmware for type=BASE INIT1 F8MHZ MTS (4007), id 0000000000000000.
[ 1637.142896] xc2028 9-0061: load_firmware called
[ 1637.142900] xc2028 9-0061: seek_firmware called, want type=BASE INIT1 MTS D2633 DTV8 (4215), id 0000000000000000.
[ 1637.142908] xc2028 9-0061: Can't find firmware for type=BASE INIT1 MTS (4005), id 0000000000000000.
[ 1637.142915] xc2028 9-0061: load_firmware called
[ 1637.142918] xc2028 9-0061: seek_firmware called, want type=F8MHZ MTS D2633 DTV8 (216), id 0000000000000000.
[ 1637.142926] xc2028 9-0061: Found firmware for type=D2633 DTV8 (210), id 0000000000000000.
[ 1637.142932] xc2028 9-0061: Loading firmware for type=D2633 DTV8 (210), id 0000000000000000.
[ 1637.158858] xc2028 9-0061: Trying to load scode 0
[ 1637.158862] xc2028 9-0061: load_scode called
[ 1637.158866] xc2028 9-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id 0000000000000000.
[ 1637.161447] xc2028 9-0061: xc2028_get_reg 0004 called
[ 1637.162448] xc2028 9-0061: xc2028_get_reg 0008 called
[ 1637.163483] xc2028 9-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
[ 1637.282661] xc2028 9-0061: divisor= 00 00 7f d0 (freq=514.000)
[ 1637.286984] dvb_frontend_ioctl (69)
[ 1637.387161] dvb_frontend_ioctl (69)
[ 1637.486899] dvb_frontend_ioctl (69)
[ 1637.587114] dvb_frontend_ioctl (69)
[ 1637.686811] dvb_frontend_ioctl (69)
[ 1637.786782] dvb_frontend_ioctl (69)
[ 1637.886734] dvb_frontend_ioctl (69)
[ 1637.986691] dvb_frontend_ioctl (69)
[ 1638.086911] dvb_frontend_ioctl (69)
[ 1638.186597] dvb_frontend_ioctl (69)
[ 1638.285137] dvb_frontend_add_event
[ 1638.288343] dtv_property_legacy_params_sync() Preparing OFDM req
[ 1638.288348] dvb_frontend_swzigzag_update_delay
[ 1639.804660] dvb_frontend_swzigzag_update_delay
[ 1641.036254] dvb_frontend_swzigzag_update_delay



and then another one:

[ 1732.409089] dvb_frontend_release
[ 1732.409115] xc2028 9-0061: Putting xc2028/3028 into poweroff mode.
[ 1732.409135] dvb_frontend_open
[ 1732.468844] dvb_frontend_start
[ 1732.468983] dvb_frontend_thread
[ 1732.468989] DVB: initialising adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[ 1732.469155] dvb_frontend_ioctl (76)
[ 1732.472520] set_delivery_system() Using delivery system to 3
[ 1732.472525] dtv_property_cache_sync() Preparing OFDM req
[ 1732.472529] dvb_frontend_add_event
[ 1732.472546] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
[ 1732.480508] xc2028 9-0061: xc2028_set_params called
[ 1732.480515] xc2028 9-0061: generic_set_freq called
[ 1732.480521] xc2028 9-0061: should set frequency 626000 kHz
[ 1732.480526] xc2028 9-0061: check_firmware called
[ 1732.480529] xc2028 9-0061: checking firmware, user requested type=F8MHZ MTS D2633 DTV8 (216), id 0000000000000000, int_freq 4760, scode_nr 0
[ 1732.540685] xc2028 9-0061: load_firmware called
[ 1732.540693] xc2028 9-0061: seek_firmware called, want type=BASE F8MHZ MTS D2633 DTV8 (217), id 0000000000000000.
[ 1732.540708] xc2028 9-0061: Found firmware for type=BASE F8MHZ MTS (7), id 0000000000000000.
[ 1732.540719] xc2028 9-0061: Loading firmware for type=BASE F8MHZ MTS (7), id 0000000000000000.
[ 1732.572568] dvb_frontend_ioctl (69)
[ 1733.673001] xc2028 9-0061: Load init1 firmware, if exists
[ 1733.673006] xc2028 9-0061: load_firmware called
[ 1733.673010] xc2028 9-0061: seek_firmware called, want type=BASE INIT1 F8MHZ MTS D2633 DTV8 (4217), id 0000000000000000.
[ 1733.673021] xc2028 9-0061: Can't find firmware for type=BASE INIT1 F8MHZ MTS (4007), id 0000000000000000.
[ 1733.673029] xc2028 9-0061: load_firmware called
[ 1733.673032] xc2028 9-0061: seek_firmware called, want type=BASE INIT1 MTS D2633 DTV8 (4215), id 0000000000000000.
[ 1733.673041] xc2028 9-0061: Can't find firmware for type=BASE INIT1 MTS (4005), id 0000000000000000.
[ 1733.673048] xc2028 9-0061: load_firmware called
[ 1733.673051] xc2028 9-0061: seek_firmware called, want type=F8MHZ MTS D2633 DTV8 (216), id 0000000000000000.
[ 1733.673059] xc2028 9-0061: Found firmware for type=D2633 DTV8 (210), id 0000000000000000.
[ 1733.673065] xc2028 9-0061: Loading firmware for type=D2633 DTV8 (210), id 0000000000000000.
[ 1733.689120] xc2028 9-0061: Trying to load scode 0
[ 1733.689125] xc2028 9-0061: load_scode called
[ 1733.689129] xc2028 9-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id 0000000000000000.
[ 1733.691748] xc2028 9-0061: xc2028_get_reg 0004 called
[ 1733.692866] xc2028 9-0061: xc2028_get_reg 0008 called
[ 1733.693863] xc2028 9-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
[ 1733.812264] xc2028 9-0061: divisor= 00 00 9b d0 (freq=626.000)
[ 1733.836716] dvb_frontend_ioctl (69)
[ 1733.936676] dvb_frontend_ioctl (69)
[ 1734.036641] dvb_frontend_ioctl (69)
[ 1734.136737] dvb_frontend_ioctl (69)
[ 1734.358896] dvb_frontend_ioctl (69)
[ 1734.458855] dvb_frontend_ioctl (69)
[ 1734.814927] dvb_frontend_add_event
[ 1734.818626] dtv_property_legacy_params_sync() Preparing OFDM req
[ 1734.818631] dvb_frontend_swzigzag_update_delay
[ 1736.334002] dvb_frontend_swzigzag_update_delay
[ 1737.565861] dvb_frontend_swzigzag_update_delay



AS102

[ 2339.647230] dvb_frontend_release
[ 2339.656954] dvb_frontend_open
[ 2339.665675] dvb_frontend_start
[ 2339.665872] dvb_frontend_thread
[ 2339.665878] DVB: initialising adapter 0 frontend 0 (Sky IT Digital Key (green led))...
[ 2339.666049] dvb_frontend_ioctl (76)
[ 2339.666053] set_delivery_system() Using delivery system to 3
[ 2339.666057] dtv_property_cache_sync() Preparing OFDM req
[ 2339.666060] dvb_frontend_add_event
[ 2339.666077] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
[ 2339.666085] tuner parameters: freq: 514000000  bw: 0x03  gi: 0xff
[ 2339.766090] dvb_frontend_ioctl (69)
[ 2339.766732] tuner status: 0x03, strength 98, per: 10000, ber: 65535
[ 2339.866191] dvb_frontend_ioctl (69)
[ 2339.867329] tuner status: 0x04, strength 99, per: 10000, ber: 65535
[ 2339.966003] dvb_frontend_ioctl (69)
[ 2339.966734] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.066000] dvb_frontend_ioctl (69)
[ 2340.071284] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.165908] dvb_frontend_ioctl (69)
[ 2340.166787] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.265947] dvb_frontend_ioctl (69)
[ 2340.266363] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.365813] dvb_frontend_ioctl (69)
[ 2340.371035] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.465773] dvb_frontend_ioctl (69)
[ 2340.466662] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.565720] dvb_frontend_ioctl (69)
[ 2340.566074] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.664688] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2340.664693] dvb_frontend_add_event
[ 2340.664699] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:1 auto_sub_step:0 started_auto_step:0
[ 2340.664704] tuner parameters: freq: 514000000  bw: 0x03  gi: 0xff
[ 2340.665682] dvb_frontend_ioctl (69)
[ 2340.666826] tuner status: 0x02, strength 99, per: 10000, ber: 37500
[ 2340.765637] dvb_frontend_ioctl (69)
[ 2340.766308] tuner status: 0x03, strength 99, per: 10000, ber: 65535
[ 2340.865594] dvb_frontend_ioctl (69)
[ 2340.870909] tuner status: 0x03, strength 99, per: 10000, ber: 65535
[ 2340.965547] dvb_frontend_ioctl (69)
[ 2340.966315] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2341.065496] dvb_frontend_ioctl (69)
[ 2341.065900] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2341.184028] dvb_frontend_ioctl (69)
[ 2341.184724] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2341.664281] tuner status: 0x02, strength 99, per: 10000, ber: 65535
[ 2341.664286] dvb_frontend_add_event
[ 2341.664291] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:2 auto_sub_step:0 started_auto_step:0
[ 2341.664297] tuner parameters: freq: 514000000  bw: 0x03  gi: 0xff
[ 2342.664227] tuner status: 0x04, strength 99, per: 10000, ber: 37500
[ 2342.664232] dvb_frontend_add_event
[ 2342.664236] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:3 auto_sub_step:0 started_auto_step:0
[ 2342.664242] tuner parameters: freq: 514000000  bw: 0x03  gi: 0xff
[ 2343.663928] tuner status: 0x04, strength 98, per: 10000, ber: 5138
[ 2343.663935] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:4 auto_sub_step:0 started_auto_step:0
[ 2343.663941] tuner parameters: freq: 514000000  bw: 0x03  gi: 0xff


another one:


[ 2402.863701] dvb_frontend_release
[ 2402.867110] dvb_frontend_open
[ 2402.870852] dvb_frontend_start
[ 2402.871035] dvb_frontend_thread
[ 2402.871042] DVB: initialising adapter 0 frontend 0 (Sky IT Digital Key (green led))...
[ 2402.871209] dvb_frontend_ioctl (76)
[ 2402.871213] set_delivery_system() Using delivery system to 3
[ 2402.871217] dtv_property_cache_sync() Preparing OFDM req
[ 2402.871220] dvb_frontend_add_event
[ 2402.871236] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
[ 2402.871243] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff
[ 2402.971413] dvb_frontend_ioctl (69)
[ 2402.976686] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.071396] dvb_frontend_ioctl (69)
[ 2403.072257] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.171163] dvb_frontend_ioctl (69)
[ 2403.171692] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.271114] dvb_frontend_ioctl (69)
[ 2403.272193] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.371069] dvb_frontend_ioctl (69)
[ 2403.371656] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.471028] dvb_frontend_ioctl (69)
[ 2403.472191] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.570990] dvb_frontend_ioctl (69)
[ 2403.571672] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.670999] dvb_frontend_ioctl (69)
[ 2403.672131] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.770904] dvb_frontend_ioctl (69)
[ 2403.771708] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.870302] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2403.870310] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:1 auto_sub_step:0 started_auto_step:0
[ 2403.870315] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff
[ 2403.870945] dvb_frontend_ioctl (69)
[ 2403.872276] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2404.077607] dvb_frontend_ioctl (69)
[ 2404.082967] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2404.177559] dvb_frontend_ioctl (69)
[ 2404.178813] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2404.277511] dvb_frontend_ioctl (69)
[ 2404.278629] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2404.377533] dvb_frontend_ioctl (69)
[ 2404.378485] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2404.477430] dvb_frontend_ioctl (69)
[ 2404.478309] tuner status: 0x02, strength 102, per: 10000, ber: 65535
[ 2404.869773] tuner status: 0x04, strength 102, per: 10000, ber: 65535
[ 2404.869778] dvb_frontend_add_event
[ 2404.869784] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:2 auto_sub_step:0 started_auto_step:0
[ 2404.869789] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff
[ 2405.869351] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2405.869356] dvb_frontend_add_event
[ 2405.869362] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:3 auto_sub_step:0 started_auto_step:0
[ 2405.869367] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff
[ 2406.868800] tuner status: 0x02, strength 103, per: 10000, ber: 65535
[ 2406.868807] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:4 auto_sub_step:0 started_auto_step:0
[ 2406.868813] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff
[ 2407.868249] tuner status: 0x02, strength 102, per: 10000, ber: 65535
[ 2407.868256] dvb_frontend_swzigzag_autotune: drift:0 inversion:0 auto_step:5 auto_sub_step:0 started_auto_step:0
[ 2407.868262] tuner parameters: freq: 626000000  bw: 0x03  gi: 0xff

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Jim Darby]

On 13/01/12 11:21, Mauro Carvalho Chehab wrote:

> Hmm... this patch shouldn't be causing troubles for an application that
> only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with
> SYS_UNDEFINED (0)?

I think this is perhaps where (some of) our problems are starting. I 
just looked at the kaffeine source code and, as far as I can make out, 
DTV_DELIVERY_SYSTEM is filled out by performing a FE_SET_PROPERTY ioctl 
with a key/value pair of something like DTV_DELIVERY_SYSTEM/SYS_DVBS2 
(amongst other parameters).

The issue here is that kaffeine *only* performs any sort of 
FE_SET_PROPERTY ioctl for DVB-S2. It certainly doesn't for any form of 
DVB-T (2 or original).

It would therefore appear that kaffeine is committing a sin of omission 
in not setting the front-end properties and hence we have this problem.

Mauro, if you can confirm that this is the case and that with the latest 
linux-media drivers performing the FE_SET_PROPERTY ioctl is mandatory 
then I can work with the kaffeine developers and get this fixed.

For reference, the existing kaffeine works with the stock 3.2.0 kernel. 
It's just the linux-media from linux-tv.org that breaks it.

Many thanks,

Jim.

[PATCH] [media] dvb-core: preserve the delivery system at cache clear

[Mauro Carvalho Chehab]

The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.

So, the delivery system needs to be explicitly preserved there.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

---

If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should
fix the current issue.

 drivers/media/dvb/dvb-core/dvb_frontend.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 2ad7faf..f5fa7aa 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 {
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int i;
+	u32 delsys;
 
+	delsys = c->delivery_system;
 	memset(c, 0, sizeof(struct dtv_frontend_properties));
+	c->delivery_system = delsys;
 
 	c->state = DTV_CLEAR;
 
-- 
1.7.8

Re: Possible regression in 3.2 kernel with PCTV Nanostick T2 (em28xx, cxd2820r and tda18271)

[Gianluca Gennari]

Il 13/01/2012 14:09, Jim Darby ha scritto:
> On 13/01/12 11:21, Mauro Carvalho Chehab wrote:
> 
>> Hmm... this patch shouldn't be causing troubles for an application that
>> only uses DVBv3 call. Is Kaffeine filling the DTV_DELIVERY_SYSTEM with
>> SYS_UNDEFINED (0)?
> 
> I think this is perhaps where (some of) our problems are starting. I
> just looked at the kaffeine source code and, as far as I can make out,
> DTV_DELIVERY_SYSTEM is filled out by performing a FE_SET_PROPERTY ioctl
> with a key/value pair of something like DTV_DELIVERY_SYSTEM/SYS_DVBS2
> (amongst other parameters).
> 
> The issue here is that kaffeine *only* performs any sort of
> FE_SET_PROPERTY ioctl for DVB-S2. It certainly doesn't for any form of
> DVB-T (2 or original).
> 
> It would therefore appear that kaffeine is committing a sin of omission
> in not setting the front-end properties and hence we have this problem.

Hi Jim,
that's because Kaffeine is using the new DVBv5 API to interface with
DVB-S2 hardware (as this is the only API supported), while it is using
the old DVBv3 API to interface to DVB-T/C hardware. It's not a real
problem, as in dvb-core there is some emulation logic that takes care of
supporting DVBv3 applications.

> Mauro, if you can confirm that this is the case and that with the latest
> linux-media drivers performing the FE_SET_PROPERTY ioctl is mandatory
> then I can work with the kaffeine developers and get this fixed.
> 
> For reference, the existing kaffeine works with the stock 3.2.0 kernel.
> It's just the linux-media from linux-tv.org that breaks it.

Mauro already fixed the bug I reported. But if you can work with the
Kaffeine developers to adopt DVBv5 API also for DVB-T/C tuners, it would
be a nice contribution.

Best regards,
Gianluca

Re: [PATCH] [media] dvb-core: preserve the delivery system at cache clear

[Gianluca Gennari]

Il 13/01/2012 14:50, Mauro Carvalho Chehab ha scritto:
> The changeset 240ab508aa is incomplete, as the first thing that
> happens at cache clear is to do a memset with 0 to the cache.
> 
> So, the delivery system needs to be explicitly preserved there.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> ---
> 
> If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should
> fix the current issue.
> 
>  drivers/media/dvb/dvb-core/dvb_frontend.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 2ad7faf..f5fa7aa 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
>  {
>  	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
>  	int i;
> +	u32 delsys;
>  
> +	delsys = c->delivery_system;
>  	memset(c, 0, sizeof(struct dtv_frontend_properties));
> +	c->delivery_system = delsys;
>  
>  	c->state = DTV_CLEAR;
>  

Hi Mauro,
I applied this new patch on top of the current media_build tree and I
can confirm that the issue with Kaffeine is solved.
All of my DVB-T sticks works fine again.

Best regards,
Gianluca

Re: [PATCH] [media] dvb-core: preserve the delivery system at cache clear

[Jim Darby]

Thanks for the patch Mauro. According to Gianluca that solves the 
backwards compatibility issue. This is great news.

In other news I've tried a few experiments. Firstly I tried using a 
3.2.0 unmodified straight out of the box kernel on my Core 2 64-bit 
system. I was unable to produce any faults. This would tend to lead one 
to suspect that it's a 32-bit problem or that my 32-bit machine is a bit 
flaky or slow.

So, as I wanted to try the new alpha 3 for Mageia 2 (a Mandriva fork) 
out and it has a 3.0 kernel that seemed to be a good idea. The bad news 
is that I'd run out of hardware. So I thought I'd be clever and run it 
as a virtual machine on my Core 2 system.

The good news is that it correctly recognised the stick and it seemed to 
work for standard definition. However, after setting it to record some 
HDTV programmes it failed. More importantly it failed in the same way as 
the 32-bit system.

This makes me think it's some kind of timing problem. The USB 
passthrough of VirtualBox may well not operate at the performance 
required for HDTV. Also by this time I'd put the stick on a USB 
extension lead which may have adversely affected the power feed.

For my next series of tests I plan to run it again on bare hardware. I'm 
going to try and use my older Core 2 machine which should have the CPU 
and electrical power.

None of which explains why it works on the 32-bit Athlon XP 2200+ when 
it's running 3.0.0 though. And has done so reliably for some time. Maybe 
some other things are happening in the kernel that much up the device 
timing or something.

Anyway, I'll keep people posted as to the progression of the testing.

Best regards,

Jim.

Re: [PATCH] [media] dvb-core: preserve the delivery system at cache clear

[Mauro Carvalho Chehab]

Em 13-01-2012 22:00, Jim Darby escreveu:
> Thanks for the patch Mauro. According to Gianluca that solves the backwards compatibility issue. This is great news.

Good!

> In other news I've tried a few experiments. Firstly I tried using a 3.2.0 unmodified straight out of the box kernel on my Core 2 64-bit system. I was unable to produce any faults. This would tend to lead one to suspect that it's a 32-bit problem or that my 32-bit machine is a bit flaky or slow.
> 
> So, as I wanted to try the new alpha 3 for Mageia 2 (a Mandriva fork) out and it has a 3.0 kernel that seemed to be a good idea. The bad news is that I'd run out of hardware. So I thought I'd be clever and run it as a virtual machine on my Core 2 system.
> 
> The good news is that it correctly recognised the stick and it seemed to work for standard definition. However, after setting it to record some HDTV programmes it failed. More importantly it failed in the same way as the 32-bit system.
> 
> This makes me think it's some kind of timing problem. The USB passthrough of VirtualBox may well not operate at the performance required for HDTV. Also by this time I'd put the stick on a USB extension lead which may have adversely affected the power feed.

Never used the USB passthrough of VirtualBox. At KVM, Hans de Goede wrote several patches 
to allow it to work with webcams.

On my tests with it with video cards, sometimes it works, sometimes it doesn't.


> For my next series of tests I plan to run it again on bare hardware. I'm going to try and use my older Core 2 machine which should have the CPU and electrical power.
> 
> None of which explains why it works on the 32-bit Athlon XP 2200+ when it's running 3.0.0 though. And has done so reliably for some time. Maybe some other things are happening in the kernel that much up the device timing or something.
> 
> Anyway, I'll keep people posted as to the progression of the testing.

>From DVB drivers perspective, a full 32bits system should work just like a 64 bits one.

Btw, I was working with a 32 bits kernel for my ISDB-T tests with the dvbv5-scan tool
I'm writing. I'm now using a 64 bits kernel for DVB-C, and everything is working
as fine as before.
> 
> Best regards,
> 
> Jim.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html