Okay, I think I've kinda solved this one...
The problem is in dvb-usb-dvb.c, in the dvb_usb_fe_init function. It
has this line:
d->fe_init = d->fe->ops->init; d->fe->ops->init = dvb_usb_fe_wakeup;
Which essentially runs the wrapper function "dvb_usb_wakeup" instead of
the specific driver's frontend init function "d->fe_ops_init". As it
happens, "dvb_usb_wakeup" then calls "d->fe_init" which is set to the
driver's frontend init function anyway. All it has is some extra power
control stuff in it.
So the problem with multiple tuners is when the second card is
initialised, it runs that code again. This has the net effect of
setting "d->fe_init" equal to "dvb_usb_fe_wakeup". Of course when this
function runs on this second thread, it ends up calling itself! And not
surprisingly, after a short delay the kernel craps out.
And the same issue applies to the sleep function too.
Here is my patch:
diff -ur linux.orig/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
--- linux.orig/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c 2006-02-02
16:10:24.000000000 +0800
+++ linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c 2006-02-02
16:13:09.000000000 +0800
@@ -184,8 +184,12 @@
/* re-assign sleep and wakeup functions */
if (d->fe != NULL) {
- d->fe_init = d->fe->ops->init; d->fe->ops->init =
dvb_usb_fe_wakeup;
- d->fe_sleep = d->fe->ops->sleep; d->fe->ops->sleep =
dvb_usb_fe_sleep;
+ if (d->fe->ops->init != dvb_usb_fe_wakeup) {
+ d->fe_init = d->fe->ops->init;
d->fe->ops->init = dvb_usb_fe_wakeup;
+ }
+ if (d->fe->ops->sleep != dvb_usb_fe_sleep) {
+ d->fe_sleep = d->fe->ops->sleep;
d->fe->ops->sleep = dvb_usb_fe_sleep;
+ }
if (dvb_register_frontend(&d->dvb_adap, d->fe)) {
err("Frontend registration failed.");
Hilton, do you want to give it a try? It seems to work okay for me,
although I think I have a problem with kernel preemption every so
often. I haven't had a good look at it yet.
Cheers,
Tim.
Hilton wrote:
> I have a hex export of the latest EZ-USB firmware courtesy of the
> helpful staff at DigitalNow.
> Gonna see about compiling it and see if that helps the situation.
> I'll post info/results once I've had a test, probably this weekend.
>
> Hilton.
>
> Tim Davies wrote:
>
>> Well, I had a quick play around with this:
>>
>> - The problem is scheduling while atomic: during the msleep in the
>> vp7045_usb_op function (vp7045.c) initiated by the wakeup of the
>> second frontend.
>> - I did try turning off kernel preemption, but no change
>> - I also tried a few hacks with the driver code, but got nothing
>> conclusive.
>>
>> My config is:
>>
>> 2 x DigitalNow TwinDVB-T device (4 vp7045 tuners)
>> Kernel is 2.4.15-gentoo-r1 running on a Gentoo 2005.1 system
>> Processor is AMD64 3200+
>> DVB drivers are the latest from CVS
>>
>> Not that my knowledge of Linux semaphores and USB is all that great,
>> but wouldn't locking around the send and receive usb_control_msg
>> (with a potentially long mdelay in between) cause problems? Is the
>> semaphore a per-device thing?
>>
>> Maybe it's time for me to read up on USB drivers...
>>
>>
>> Tim.
>>
>>
>> Hilton wrote:
>>
>>> Does anyone successfully have multiple vp7045 dvb-t usb devices
>>> working? (Twinhan Alpha II, Digitalnow TwinDVB-T, multiple Tinyusb2
>>> devices etc)
>>>
>>> I also have the same problem as has been posted about over the last
>>> few months (see quoted below from Tim Davies), with dual vp7045 usb
>>> devices (DigitalNow TwinDVB-T device - rebadged DVICO Tinyusb 2
>>> devices).
>>>
>>> This post is mostly configuration info - along with Tim's debug
>>> output quoted below.
>>>
>>> Currently using Fedora Core 4's 2.6.14-1.1656_FC4 kernel, all
>>> updates applies, and the latest cvs build of the v4l/dvb modules,
>>> along with the dvb-usb-vp7045-01.fw firmware. I've also had the
>>> same problem with the default 2.6.14 kernel modules, and also the
>>> Jan 16th build of 2.6.16-RC1 kernel (yes, I've done a lot of
>>> compiling in the last week ;)
>>>
>>> Both devices work fine (tested on the same hardware with Windows XP)
>>> at the same time, so its not a usb power-rail problem.
>>>
>>> If anyone can help shed some light on a solution, I'd be grateful -
>>> done a lot of reading and found a lot of people with the same issue,
>>> but no resolution yet.
>>>
>>> I'm happy to test any potential solutions - or enable debug in my
>>> current module builds to provide more specific info than is included
>>> below. :)
>>>
>>> Thanks,
>>>
>>> Hilton.
>>>
>>> My dmesg output is:
>>>
>>> [mythtv@tv ~]$ dmesg | grep dvb
>>> dvb-usb: found a 'Twinhan USB2.0 DVB-T receiver (TwinhanDTV
>>> Alpha/MagicBox II)' in warm state.
>>> dvb-usb: will pass the complete MPEG2 transport stream to the
>>> software demuxer.
>>> dvb-usb: MAC address: 08:ca:17:4e:bc:ff
>>> dvb-usb: schedule remote query interval to 400 msecs.
>>> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox
>>> II) successfully initialized and connected.
>>> dvb-usb: found a 'Twinhan USB2.0 DVB-T receiver (TwinhanDTV
>>> Alpha/MagicBox II)' in warm state.
>>> dvb-usb: will pass the complete MPEG2 transport stream to the
>>> software demuxer.
>>> dvb-usb: MAC address: 08:ca:17:4e:b8:ff
>>> dvb-usb: schedule remote query interval to 400 msecs.
>>> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox
>>> II) successfully initialized and connected.
>>> usbcore: registered new driver dvb_usb_vp7045
>>>
>>> My /dev/dvb is:
>>>
>>> [mythtv@tv ~]$ ls -laR /dev/dvb
>>> /dev/dvb:
>>> total 0
>>> drwxr-xr-x 4 root root 80 Jan 21 2006 .
>>> drwxr-xr-x 12 root root 4480 Jan 21 12:04 ..
>>> drwxr-xr-x 2 mythtv mythtv 120 Jan 21 2006 adapter0
>>> drwxr-xr-x 2 mythtv mythtv 120 Jan 21 2006 adapter1
>>>
>>> /dev/dvb/adapter0:
>>> total 0
>>> drwxr-xr-x 2 mythtv mythtv 120 Jan 21 2006 .
>>> drwxr-xr-x 4 root root 80 Jan 21 2006 ..
>>> crw-rw---- 1 mythtv mythtv 212, 4 Jan 21 2006 demux0
>>> crw-rw---- 1 mythtv mythtv 212, 5 Jan 21 2006 dvr0
>>> crw-rw---- 1 mythtv mythtv 212, 3 Jan 21 2006 frontend0
>>> crw-rw---- 1 mythtv mythtv 212, 7 Jan 21 2006 net0
>>>
>>> /dev/dvb/adapter1:
>>> total 0
>>> drwxr-xr-x 2 mythtv mythtv 120 Jan 21 2006 .
>>> drwxr-xr-x 4 root root 80 Jan 21 2006 ..
>>> crw-rw---- 1 mythtv mythtv 212, 68 Jan 21 2006 demux0
>>> crw-rw---- 1 mythtv mythtv 212, 69 Jan 21 2006 dvr0
>>> crw-rw---- 1 mythtv mythtv 212, 67 Jan 21 2006 frontend0
>>> crw-rw---- 1 mythtv mythtv 212, 71 Jan 21 2006 net0
>>>
>>> Performing a scan works fine for adapter0
>>>
>>> [mythtv@tv ~]$ scandvb files/frequency.artarmon
>>> scanning files/frequency.artarmon
>>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>>> initial transponder 226500000 1 2 0 3 1 2 0
>>> initial transponder 191625000 1 2 0 3 1 2 0
>>> initial transponder 571500000 1 2 0 3 1 2 0
>>> initial transponder 219500000 1 3 0 3 1 1 0
>>> initial transponder 177500000 1 2 0 3 1 2 0
>>> >>> tune to:
>>> 226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_NONE:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
>>>
>>>
>>> But with adapter1 (scandvb -a 1 ) I get the "using
>>> '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter0/demux0', then
>>> the PC hard-locks about 15s later with not output.
>>>
>>> And finally, Tim's quoted debug for the same issue.
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I noticed in November there was a problem running multiple Twinhan
>>>> DTV MagicBox II devices, which causes the kernel to lock up. As
>>>> far as I could tell, the issue was abandoned - with a copy of the
>>>> kernel oops being needed to continue...
>>>>
>>>> Well, I also have multiple vp7045 based tuners (the DNTV version)
>>>> and have the same problem. I have an excerpt of the kernel oops
>>>> text below.
>>>>
>>>> Basically the problem seems to occur if any tuner apart from the
>>>> first one is opened, and there is normally a delay (15-20sec?)
>>>> before the crash. I am using the CVS driver from the 16/1/06 (the
>>>> most recent).
>>>>
>>>> Thanks,
>>>>
>>>> Tim.
>>>>
>>>>
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>>
>>>> ... <repeated ~100 times>
>>>>
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff8012cde4>{deactivate_task+20}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff885f7f5b>{:dvb_core:dvb_frontend_thread+219}
>>>> Jan 16 10:39:20 mediabox <ffffffff80130031>{copy_process+4241}
>>>> <ffffffff8010f31e>{child_rip+8}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff885f7e80>{:dvb_core:dvb_frontend_thread+0}
>>>> Jan 16 10:39:20 mediabox <ffffffff8010f316>{child_rip+0}
>>>> Jan 16 10:39:20 mediabox scheduling while atomic:
>>>> kdvb-fe-1/0xffff8100/14284
>>>> Jan 16 10:39:20 mediabox
>>>> Jan 16 10:39:20 mediabox Call
>>>> Trace:<ffffffff803ca99a>{schedule+122}
>>>> <ffffffff8032dbd0>{timeout_kill+0}
>>>> Jan 16 10:39:20 mediabox <ffffffff803cb7b4>{schedule_timeout+148}
>>>> <ffffffff80139670>{process_timeout+0}
>>>> Jan 16 10:39:20 mediabox <ffffffff80139a4a>{msleep+42}
>>>> <ffffffff8860c11c>{:dvb_usb_vp7045:vp7045_usb_op+284}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860c3fa>{:dvb_usb_vp7045:.text.lock.vp7045+5}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860c24a>{:dvb_usb_vp7045:vp7045_power_ctrl+42}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860784c>{:dvb_usb:dvb_usb_fe_wakeup+44}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>>
>>>> ...
>>>>
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff8012cde4>{deactivate_task+20}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff885f7f5b>{:dvb_core:dvb_frontend_thread+219}
>>>> Jan 16 10:39:20 mediabox <ffffffff80130031>{copy_process+4241}
>>>> <ffffffff8010f31e>{child_rip+8}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff885f7e80>{:dvb_core:dvb_frontend_thread+0}
>>>> Jan 16 10:39:20 mediabox <ffffffff8010f316>{child_rip+0}
>>>> Jan 16 10:39:20 mediabox scheduling while atomic:
>>>> kdvb-fe-1/0xffff8100/14284
>>>> Jan 16 10:39:20 mediabox
>>>> Jan 16 10:39:20 mediabox Call
>>>> Trace:<ffffffff803ca99a>{schedule+122}
>>>> <ffffffff803cb7b4>{schedule_timeout+148}
>>>> Jan 16 10:39:20 mediabox <ffffffff80139670>{process_timeout+0}
>>>> <ffffffff80139a4a>{msleep+42}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860c11c>{:dvb_usb_vp7045:vp7045_usb_op+284}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860c3fa>{:dvb_usb_vp7045:.text.lock.vp7045+5}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff8860c24a>{:dvb_usb_vp7045:vp7045_power_ctrl+42}
>>>> Jan 16 10:39:20 mediabox 861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> Jan 16 10:39:20 mediabox
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>> <ffffffff88607861>{:dvb_usb:dvb_usb_fe_wakeup+65}
>>>
>>
>> _______________________________________________
>>
>> linux-dvb@xxxxxxxxxxx
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
>
>
> _______________________________________________
>
> linux-dvb@xxxxxxxxxxx
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
