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

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.

What does femon show for demodulator statistics?

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

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.

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

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

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

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.

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

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

Antti

http://palosaari.fi/

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.

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.

Il 11/01/2012 20:19, Jim Darby ha scritto:

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.

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.

Il 12/01/2012 17:35, Jim Darby ha scritto:

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

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

Em 12-01-2012 14:22, Gianluca Gennari escreveu:

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

Il 13/01/2012 12:21, Mauro Carvalho Chehab ha scritto:

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

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

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.

---

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(-)

index 2ad7faf..f5fa7aa 100644
@@ -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

Il 13/01/2012 14:50, Mauro Carvalho Chehab ha scritto:

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.

Em 13-01-2012 22:00, Jim Darby escreveu:

Good!

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.

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.

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.

Il 13/01/2012 14:09, Jim Darby ha scritto:

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 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

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....