[linux-dvb] Multiple vp7045 DVB USB devices and lockups

Hilton dvb at hiltonday.com
Wed Jan 25 08:29:34 CET 2006


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 at 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 at 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 at 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 mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb





More information about the linux-dvb mailing list