PCTV 290e - assorted problems

Hi,

I've been experimenting with my new PCTV 290e DVB-T2 device this weekend, and have a couple of observations. For example, the device sometimes has trouble initialising itself:

usb 4-2: new high speed USB device number 4 using ehci_hcd
em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) em28xx #0: chip ID is em28174
em28xx #0: Identified as PCTV nanoStick T2 290e (card=78)
Registered IR keymap rc-pinnacle-pctv-hd
input: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-2/rc/rc1/input10
rc1: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-2/rc/rc1 em28xx #0: v4l2 driver version 0.1.2
em28xx #0: V4L2 video device registered as video1

INFO: task khubd:1100 blocked for more than 120 seconds.

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
khubd D 0000000000000000 0 1100 2 0x00000000
ffff8801a694e930 0000000000000046 ffff8801a691ffd8 ffffffff8162b020 0000000000010280 ffff8801a691ffd8 0000000000004000 0000000000010280 ffff8801a691ffd8 ffff8801a694e930 0000000000010280 ffff8801a691e000

Call Trace:
 [<ffffffff8128580e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff8113ffff>] ? memscan+0x3/0x18
 [<ffffffff8128354e>] ? __mutex_lock_slowpath+0x15c/0x295
 [<ffffffff81283690>] ? mutex_lock+0x9/0x18
 [<ffffffffa06af671>] ? dvb_init+0x99/0xcc8 [em28xx_dvb]
 [<ffffffffa067d459>] ? em28xx_init_extension+0x35/0x53 [em28xx]
 [<ffffffffa067b938>] ? em28xx_usb_probe+0x827/0x8df [em28xx]
 [<ffffffffa013f5bc>] ? usb_probe_interface+0xfc/0x16f [usbcore]
 [<ffffffff811c2eec>] ? driver_probe_device+0xa8/0x138
 [<ffffffff811c2feb>] ? __driver_attach+0x6f/0x6f
 [<ffffffff811c1f19>] ? bus_for_each_drv+0x47/0x7b
 [<ffffffff811c2d8d>] ? device_attach+0x6f/0x8f
 [<ffffffff811c2714>] ? bus_probe_device+0x22/0x40
 [<ffffffff811c0f80>] ? device_add+0x3bf/0x531
 [<ffffffff811bfffa>] ? dev_set_name+0x3f/0x44
 [<ffffffff8102956d>] ? sub_preempt_count+0x83/0x94
 [<ffffffffa013e1b1>] ? usb_set_configuration+0x536/0x58f [usbcore]
 [<ffffffff8110cd99>] ? sysfs_do_create_link+0x14c/0x1a1
 [<ffffffffa01450c5>] ? generic_probe+0x48/0x77 [usbcore]
 [<ffffffff811c2eec>] ? driver_probe_device+0xa8/0x138
 [<ffffffff811c2feb>] ? __driver_attach+0x6f/0x6f
 [<ffffffff811c1f19>] ? bus_for_each_drv+0x47/0x7b
 [<ffffffff811c2d8d>] ? device_attach+0x6f/0x8f
 [<ffffffff811c2714>] ? bus_probe_device+0x22/0x40
 [<ffffffff811c0f80>] ? device_add+0x3bf/0x531
 [<ffffffff810b3818>] ? kfree+0x13/0xa2
 [<ffffffffa013811b>] ? usb_new_device+0x9d/0x111 [usbcore]
 [<ffffffffa01391cd>] ? hub_thread+0xa03/0xe89 [usbcore]
 [<ffffffff81046361>] ? wake_up_bit+0x23/0x23
 [<ffffffffa01387ca>] ? usb_remote_wakeup+0x2f/0x2f [usbcore]
 [<ffffffffa01387ca>] ? usb_remote_wakeup+0x2f/0x2f [usbcore]
 [<ffffffff81045f73>] ? kthread+0x7a/0x82
 [<ffffffff81285c54>] ? kernel_thread_helper+0x4/0x10
 [<ffffffff81045ef9>] ? kthread_worker_fn+0x149/0x149
 [<ffffffff81285c50>] ? gs_change+0xb/0xb
INFO: task usb_id:13895 blocked for more than 120 seconds.

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
usb_id D 0000000000000004 0 13895 13887 0x00000080
ffff880195e5ef60 0000000000000082 ffff880196064e60 ffff88018e8156a0 0000000000010280 ffff88018b2c5fd8 0000000000004000 0000000000010280 ffff88018b2c5fd8 ffff880195e5ef60 0000000000010280 ffff88018b2c4000

Call Trace:
 [<ffffffff81088f59>] ? __alloc_pages_nodemask+0x130/0x72a
 [<ffffffff810294d8>] ? get_parent_ip+0x9/0x1b
 [<ffffffff8128354e>] ? __mutex_lock_slowpath+0x15c/0x295
 [<ffffffff81283690>] ? mutex_lock+0x9/0x18
 [<ffffffffa01416a8>] ? show_manufacturer+0x1a/0x45 [usbcore]
 [<ffffffff811c001d>] ? dev_attr_show+0x1e/0x46
 [<ffffffff810895e1>] ? __get_free_pages+0x12/0x52
 [<ffffffff8110b3b6>] ? sysfs_read_file+0xa8/0x12e
 [<ffffffff8102956d>] ? sub_preempt_count+0x83/0x94
 [<ffffffff810bb922>] ? vfs_read+0xac/0x126
 [<ffffffff810bb9e1>] ? sys_read+0x45/0x6e
 [<ffffffff81284e7b>] ? system_call_fastpath+0x16/0x1b

A more successful hotplug looks like this:

usb 4-3.1: new high speed USB device number 3 using ehci_hcd
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
lirc_dev: IR Remote Control driver registered, major 250
IR LIRC bridge handler initialized
em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) em28xx #0: chip ID is em28174
em28xx #0: Identified as PCTV nanoStick T2 290e (card=78)
Registered IR keymap rc-pinnacle-pctv-hd
input: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3.1/rc/rc0/input7
rc0: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-3/4-3.1/rc/rc0 em28xx #0: v4l2 driver version 0.1.2
em28xx #0: V4L2 video device registered as video1
usbcore: registered new interface driver em28xx
em28xx driver loaded
tda18271 7-0060: creating new instance
TDA18271HD/C2 detected @ 7-0060
tda18271 7-0060: attaching existing instance
DVB: registering new adapter (em28xx #0)
DVB: registering adapter 0 frontend 0 (Sony CXD2820R (DVB-T/T2))...
DVB: registering adapter 0 frontend 1 (Sony CXD2820R (DVB-C))...
em28xx #0: Successfully loaded em28xx-dvb
Em28xx: Initialized (Em28xx dvb Extension) extension
tda18271: performing RF tracking filter calibration
tda18271: RF tracking filter calibration complete

Tuning the adapter into the HD MUX is also proving to be more difficult that I anticipated. Successful attempts are so rare that I am now forced to assume that I was merely lucky.

The following parameters *should* be enough, but clearly aren't in practice:

T 554000000 8MHz 2/3 AUTO QAM256 AUTO AUTO AUTO

Cheers,
Chris

I think it crashes before it even goes to PCTV 290e specific part. I suspect it is bug somewhere in em28xx driver. I am not much familiar with em28xx driver. Does someone else see where it crashes?

That is DVB-T2 since QAM256 I suspect. Actually everything else but frequency and bandwidth are needed, all others are detected automatically. T 554000000 8MHz + auto auto auto etc.
is enough.

I have 570 MHz DVB-T2 live here working fine. It is only 2 UHF channels (16MHz) more. Have you tried it on Windows?

regards
Antti

http://palosaari.fi/

Hmm, not here it isn't:

$ scandvb -u -vvv uk-CrystalPalace 
scanning uk-CrystalPalace
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 554000000 0 9 9 6 2 4 4

WARNING: >>> tuning failed!!!

WARNING: >>> tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.

Although it was working (briefly) on Saturday morning.

No, because I don't own a Windows machine.

Cheers,
Chris

Most likely demod does not got full lock since weak/noisy signal. It is possible to increase lock waiting time from changing driver but it is not wise before signal is known to be good enough.

Antti

http://palosaari.fi/

Hi,

This is my third draft at fixing the em28xx modules for the PCTV 290e DVB adapter. The highlights are:

- resolve the locking issue when replugging the USB adapter,
- remove race condition when initialising an adapter and simultaneously loading the em28xx-dvb module,
- more reliable releasing of resources on error paths,
- use atomic bit operations for em28xx_devused mask, and enforce hard limit of EM28XX_MAXBOARDS adapters.

The patch is against 3.0, but these particular files don't seem to have changed much by 3.1. Any review comments welcome.

Cheers,
Chris

@@ -1160,10 +1160,9 @@
 static DEFINE_MUTEX(em28xx_devlist_mutex);
 
 /*
- * em28xx_realease_resources()
- * unregisters the v4l2,i2c and usb devices
- * called when the device gets disconected or at module unload
-*/
+ * em28xx_remove_from_devlist()
+ * Removes the device from the list of active devices.
+ */
 void em28xx_remove_from_devlist(struct em28xx *dev)
 {
 	mutex_lock(&em28xx_devlist_mutex);

@@ -1171,13 +1170,6 @@
 	mutex_unlock(&em28xx_devlist_mutex);
 };
 
-void em28xx_add_into_devlist(struct em28xx *dev)
-{
-	mutex_lock(&em28xx_devlist_mutex);
-	list_add_tail(&dev->devlist, &em28xx_devlist);
-	mutex_unlock(&em28xx_devlist_mutex);
-};
-
 /*
  * Extension interface
  */

@@ -1193,8 +1185,8 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->init(dev);
 	}
-	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Initialized (%s) extension\n", ops->name);
 	return 0;
 }
 EXPORT_SYMBOL(em28xx_register_extension);

@@ -1207,9 +1199,9 @@
 	list_for_each_entry(dev, &em28xx_devlist, devlist) {
 		ops->fini(dev);
 	}
-	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 	list_del(&ops->next);
 	mutex_unlock(&em28xx_devlist_mutex);
+	printk(KERN_INFO "Em28xx: Removed (%s) extension\n", ops->name);
 }
 EXPORT_SYMBOL(em28xx_unregister_extension);
 

@@ -1218,11 +1210,10 @@
 	struct em28xx_ops *ops = NULL;
 
 	mutex_lock(&em28xx_devlist_mutex);
-	if (!list_empty(&em28xx_extension_devlist)) {
-		list_for_each_entry(ops, &em28xx_extension_devlist, next) {
-			if (ops->init)
-				ops->init(dev);
-		}
+	list_add_tail(&dev->devlist, &em28xx_devlist);
+	list_for_each_entry(ops, &em28xx_extension_devlist, next) {
+		if (ops->init)
+			ops->init(dev);
 	}
 	mutex_unlock(&em28xx_devlist_mutex);
 }

@@ -542,7 +542,6 @@
 	dev->dvb = dvb;
 	dvb->fe[0] = dvb->fe[1] = NULL;
 
-	mutex_lock(&dev->lock);
 	em28xx_set_mode(dev, EM28XX_DIGITAL_MODE);
 	/* init frontend */
 	switch (dev->model) {

@@ -711,7 +710,6 @@
 	em28xx_info("Successfully loaded em28xx-dvb\n");
 ret:
 	em28xx_set_mode(dev, EM28XX_SUSPEND);
-	mutex_unlock(&dev->lock);
 	return result;
 
 out_free:

Hi Chris,

Take a look at this breakdown of muxes on the crystal palace transmitter:

http://www.ukfree.tv/txdetail.php?a=TQ339712

You'll see mixed power levels and FFT sizes. I have the same thing (albeit with a larger range of power levels) here in Mendip and as a result its very difficult to get certain muxes.

You could try a variable attenuator to see if you can trim things a bit to make the tuner/frontend happier getting a lock on all the muxes. It depends on whether the problem is a weak signal or a too strong signal.

Of course it might be something else altogether, but this sort of thing is precisely the kind of rubbish we have to deal with during the UK digital switchover.

Regards,

Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

I suspect that the HD signal is too weak where I am, because I am in the transmitter's "green area". So it's possible that I'll have to wait until April before getting a decent HD service.

Hmph! Well, at least I'll have time to look into that locking bug... The em28xx_dvb module's clean-up code might be a good place to start, if unloading this module "fixes" things.

Cheers,
Chris