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