PCTV 290e - assorted problems

PCTV 290e - assorted problems

[Chris Rankin]

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

Re: PCTV 290e - assorted problems

[Antti Palosaari]

On 08/15/2011 02:20 AM, Chris Rankin wrote:
> 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:

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

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?

> 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

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/

Re: PCTV 290e - assorted problems

[Chris Rankin]

--- On Mon, 15/8/11, Antti Palosaari <crope@iki.fi> wrote:
> T 554000000 8MHz + auto auto auto etc.
> is enough.

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
>>> tune to: 554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
>>> tuning status == 0x00
>>> tuning status == 0x00
>>> tuning status == 0x00
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
WARNING: >>> tuning failed!!!
>>> tune to: 554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO (tuning failed)
>>> tuning status == 0x00
>>> tuning status == 0x00
>>> tuning status == 0x00
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
>>> tuning status == 0x0f
WARNING: >>> tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.

Although it was working (briefly) on Saturday morning.

> Have you tried it on Windows?

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

Cheers,
Chris

Re: PCTV 290e - assorted problems

[Antti Palosaari]

On 08/15/2011 02:56 AM, Chris Rankin wrote:

>>>> tuning status == 0x0f
>>>> tuning status == 0x0f
> WARNING: >>> tuning failed!!!
> ERROR: initial tuning failed
> dumping lists (0 services)
> Done.
> 
> Although it was working (briefly) on Saturday morning.
> 
>> Have you tried it on Windows?
> 
> No, because I don't own a Windows machine.

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/

Re: PCTV 290e - assorted problems

[Chris Rankin]

>> 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]
>
> I think it crashes before it even goes to PCTV 290e specific part. I
> suspect it is bug somewhere in em28xx driver.

The scenario that triggers this crash is:
a) Plug the 290e in, and allow it to initialise correctly
b) Use xine to watch any DVB-T channel successfully
c) Try switching to previously-tuned DVB-T2 channel; this makes xine hang.
d) Kill xine
e) Physically replug adapter

em28xx re-initialisation will now fail:

...
tda18271: performing RF tracking filter calibration
tda18271: RF tracking filter calibration complete
usb 4-1: USB disconnect, device number 3
em28xx #0: disconnecting em28xx #0 video
em28xx #0: V4L2 device video1 deregistered
tda18271 7-0060: destroying instance
usb 4-1: 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-1/rc/rc1/input8
rc1: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-1/rc/rc1
em28xx #0: v4l2 driver version 0.1.2
em28xx #0: V4L2 video device registered as video1
INFO: task khubd:1217 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
khubd           D 0000000000000000     0  1217      2 0x00000000
 ffff8801a7081ef0 0000000000000046 ffff8801a69a9fd8 ffffffff8162b020
 0000000000010280 ffff8801a69a9fd8 0000000000004000 0000000000010280
 ffff8801a69a9fd8 ffff8801a7081ef0 0000000000010280 ffff8801a69a8000
Call Trace:
 [<ffffffff8128580e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff8113ffff>] ? memscan+0x3/0x18
 [<ffffffff8128354e>] ? __mutex_lock_slowpath+0x15c/0x295
 [<ffffffff81283690>] ? mutex_lock+0x9/0x18
 [<ffffffffa0694671>] ? dvb_init+0x99/0xcc8 [em28xx_dvb]
 [<ffffffffa0662459>] ? em28xx_init_extension+0x35/0x53 [em28xx]
 [<ffffffffa0660938>] ? em28xx_usb_probe+0x827/0x8df [em28xx]

Cheers,
Chris

Re: PCTV 290e - assorted problems

[Steve Kerrison]

That is most likely the em28xx locking bug. It'll happen when you plug a
second em28xx device in, or plug one in for a second time. The steps
you've shown include that process. Try doing `rmmod em28xx-dvb` before
re-plugging the device. If that 'cures' it, you're a victim of the same
problem.

I'm not overtly familiar with the interactions of em28xx with the rest
of the kernel & userland and why the bug manifests, but it is on my list
of things to (try to) fix, although I'm hoping somebody more able than
me figures it out first :)

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 

On Sun, 2011-08-14 at 17:05 -0700, Chris Rankin wrote:
> >> 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]
> >
> > I think it crashes before it even goes to PCTV 290e specific part. I
> > suspect it is bug somewhere in em28xx driver.
> 
> The scenario that triggers this crash is:
> a) Plug the 290e in, and allow it to initialise correctly
> b) Use xine to watch any DVB-T channel successfully
> c) Try switching to previously-tuned DVB-T2 channel; this makes xine hang.
> d) Kill xine
> e) Physically replug adapter
> 
> em28xx re-initialisation will now fail:
> 
> ...
> tda18271: performing RF tracking filter calibration
> tda18271: RF tracking filter calibration complete
> usb 4-1: USB disconnect, device number 3
> em28xx #0: disconnecting em28xx #0 video
> em28xx #0: V4L2 device video1 deregistered
> tda18271 7-0060: destroying instance
> usb 4-1: 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-1/rc/rc1/input8
> rc1: em28xx IR (em28xx #0) as /devices/pci0000:00/0000:00:1d.7/usb4/4-1/rc/rc1
> em28xx #0: v4l2 driver version 0.1.2
> em28xx #0: V4L2 video device registered as video1
> INFO: task khubd:1217 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> khubd           D 0000000000000000     0  1217      2 0x00000000
>  ffff8801a7081ef0 0000000000000046 ffff8801a69a9fd8 ffffffff8162b020
>  0000000000010280 ffff8801a69a9fd8 0000000000004000 0000000000010280
>  ffff8801a69a9fd8 ffff8801a7081ef0 0000000000010280 ffff8801a69a8000
> Call Trace:
>  [<ffffffff8128580e>] ? apic_timer_interrupt+0xe/0x20
>  [<ffffffff8113ffff>] ? memscan+0x3/0x18
>  [<ffffffff8128354e>] ? __mutex_lock_slowpath+0x15c/0x295
>  [<ffffffff81283690>] ? mutex_lock+0x9/0x18
>  [<ffffffffa0694671>] ? dvb_init+0x99/0xcc8 [em28xx_dvb]
>  [<ffffffffa0662459>] ? em28xx_init_extension+0x35/0x53 [em28xx]
>  [<ffffffffa0660938>] ? em28xx_usb_probe+0x827/0x8df [em28xx]
> 
> Cheers,
> Chris
> 
> --
> 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

Re: PCTV 290e - assorted problems

[Steve Kerrison]

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/ 

On Sun, 2011-08-14 at 16:56 -0700, Chris Rankin wrote:
> --- On Mon, 15/8/11, Antti Palosaari <crope@iki.fi> wrote:
> > T 554000000 8MHz + auto auto auto etc.
> > is enough.
> 
> 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
> >>> tune to: 554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO
> >>> tuning status == 0x00
> >>> tuning status == 0x00
> >>> tuning status == 0x00
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> WARNING: >>> tuning failed!!!
> >>> tune to: 554000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO (tuning failed)
> >>> tuning status == 0x00
> >>> tuning status == 0x00
> >>> tuning status == 0x00
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> >>> tuning status == 0x0f
> WARNING: >>> tuning failed!!!
> ERROR: initial tuning failed
> dumping lists (0 services)
> Done.
> 
> Although it was working (briefly) on Saturday morning.
> 
> > Have you tried it on Windows?
> 
> No, because I don't own a Windows machine.
> 
> Cheers,
> Chris
> 
> --
> 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

Re: PCTV 290e - assorted problems

[Chris Rankin]

--- On Mon, 15/8/11, Steve Kerrison <steve@stevekerrison.com> wrote:
> It depends on whether the problem is a weak signal or a too strong
> signal.

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

Possible cause of replug lockup in em28xx-dvb

[Chris Rankin]

Hi,

I've been "plugging away" at the locking issue in the em28xx / em28xx-dvb 
modules, and I think I've found the reason. Basically, we're trying to acquire 
the dev->lock mutex again in dvb_init() when we've already acquired it in 
em28xx_init_dev().

The exact sequence is:
	em28xx_init_dev()
	- em28xx_init_extension()
	-- ops->init(dev) function for each extension

where ops->init = dvb_init() for the em28xx-dvb extension. However, if you 
remove the em28xx-dvb module first then the em28xx_extension_devlist is empty
and you avoid calling dvb_init().

As to the fix, I'm thinking of moving the mutex_lock() / mutex_unlock() calls
from dvb_init() to em28xx_register_extension() instead. This way, we ensure that 
dvb_init() is still always called with the dvb->lock mutex held.

I'll submit a patch for review in the morning. (Or should I say, "later this 
morning"...)

Cheers,
Chris