[linux-dvb] Re: Twinhan Visionplus VisionDVT mini ter

[Manu Abraham <manu@kromtek.com>]

On Wed December 22 2004 8:22 pm, Benedict White wrote:
> Right, well I have made some progress sort off.
>
> I am using kernel 2.6.10-rc3.
>
> I took the cvs, and patched it with the patch mentioned in:
> http://www.linuxtv.org/mailinglists/linux-dvb/2004/12-2004/msg00600.html
>
> I then liked that in and recompiled the kernel and rebooted.
>
> OK so far.
>
> Edited modprobe.conf to put in:
> options bttv i2c_hw=1 card=0x71
>
> On bootup bttv is loaded OK with:
>
> Dec 22 15:46:02 pvr Linux video capture interface: v1.00
> Dec 22 15:46:02 pvr bttv: driver version 0.9.15 loaded
> Dec 22 15:46:02 pvr bttv: using 8 buffers with 2080k (520 pages) each for
> capture Dec 22 15:46:02 pvr bttv: Bt8xx card found (0).
> Dec 22 15:46:02 pvr ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
> Dec 22 15:46:02 pvr PCI: setting IRQ 5 as level-triggered
> Dec 22 15:46:02 pvr ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 5 (level,
> low) -> IRQ 5
> Dec 22 15:46:02 pvr bttv0: Bt878 (rev 17) at 0000:00:0a.0, irq: 5, latency:
> 32, mmio: 0xdf002000
> Dec 22 15:46:02 pvr bttv0: detected: Twinhan VisionPlus DVB-T [card=113],
> PCI subsystem ID is 1822:0001
> Dec 22 15:46:02 pvr bttv0: using: Twinhan DST + clones [card=113,insmod
> option] Dec 22 15:46:02 pvr bttv0: gpio: en=00000000, out=00000000
> in=00ffffff [init] Dec 22 15:46:03 pvr bttv0: using tuner=4
> Dec 22 15:46:03 pvr bttv0: add subdevice "dvb0"
> Dec 22 15:46:03 pvr bt878: AUDIO driver version 0.0.0 loaded
> Dec 22 15:46:03 pvr bt878: Bt878 AUDIO function found (0).
> Dec 22 15:46:03 pvr ACPI: PCI interrupt 0000:00:0a.1[A] -> GSI 5 (level,
> low) -> IRQ 5
> Dec 22 15:46:03 pvr bt878(0): Bt878 (rev 17) at 00:0a.1, irq: 5, latency:
> 32, memory: 0xdf000000
>
> Then I do a modprobe dvb_bt8xx
>
> which gets me:
>
> Dec 22 15:59:50 pvr DVB: registering new adapter (bttv0).
> Dec 22 15:59:51 pvr DVB: registering frontend 0 (<NULL>)...
>
> Then I modprobe dst dst_type=1
There is no module parameter dst_type

>
> I then get nothing in kernel.log. Is that odd?
>
> I get the following devices in /dev
> dvb0.demux0
> dvb0.dvr0
> dvb0.frontend0
> dvb0.net0
>
> So nothing in /dev/dvb/adapter0/
If you are using FC3, udev to manage your /dev/ directory, then you shouls 
configure udev... 

I think somebody else had the same problem. Should be there in the archives.
Either you can configure udev to configure the devices properly, or you can 
run the MAKEDEV script on every reboot..

>
> so i symlinked as follows:
>
> lrwxrwxrwx  1 root root 16 2004-12-22 16:03 demux0 -> /dev/dvb0.demux0
> lrwxrwxrwx  1 root root 14 2004-12-22 16:03 dvr0 -> /dev/dvb0.dvr0
> lrwxrwxrwx  1 root root 19 2004-12-22 16:03 frontend0 ->
> /dev/dvb0.frontend0
>
>
> Then when I ran ./dvbscan -c and get a segmentation fault as follows:
>
> Dec 22 16:03:40 pvr Unable to handle kernel NULL pointer dereference at
> virtual address 000001ec
> Dec 22 16:03:40 pvr printing eip:
> Dec 22 16:03:40 pvr c02a7bed
> Dec 22 16:03:40 pvr *pde = 00000000
> Dec 22 16:03:40 pvr Oops: 0000 [#1]
> Dec 22 16:03:40 pvr PREEMPT SMP
> Dec 22 16:03:40 pvr Modules linked in: dvb_bt8xx nxt6000 mt352 sp887x
> dst_ca dst tulip bt878 tuner bttv video_buf firmware_cl$
> Dec 22 16:03:40 pvr CPU:    0
> Dec 22 16:03:40 pvr EIP:    0060:[<c02a7bed>]    Tainted: G S    VLI
> Dec 22 16:03:40 pvr EFLAGS: 00010286   (2.6.10-rc3-ARCH)
> Dec 22 16:03:40 pvr EIP is at dvb_frontend_ioctl+0x4d/0x6a0
> Dec 22 16:03:40 pvr eax: 00000000   ebx: 80a86f3d   ecx: 00000000   edx:
> 00000000
> Dec 22 16:03:40 pvr esi: cfd07b00   edi: 80a86f3d   ebp: cf7efba0   esp:
> c9b10e88 Dec 22 16:03:40 pvr ds: 007b   es: 007b   ss: 0068
> Dec 22 16:03:40 pvr Process dvbscan (pid: 2941, threadinfo=c9b10000
> task=cf1440e0)
> Dec 22 16:03:40 pvr Stack: c0513a80 c9a1bb7c cfb9407c ffffffa1 00000000
> c014f19b 00000000 cfd53dd8
> Dec 22 16:03:40 pvr 00000001 c9a1bb7c cfb9407c cfb94040 00000000 cfd10760
> c02162d2 cfd10760
> Dec 22 16:03:40 pvr 08050260 80a86f3d fffffff2 cfd10760 cfd10760 c029f77c
> cf4527a0 cf7efba0
> Dec 22 16:03:40 pvr Call Trace:
> Dec 22 16:03:40 pvr [<c014f19b>] pte_alloc_map+0xab/0xe0
> Dec 22 16:03:40 pvr [<c02162d2>] copy_from_user+0x42/0x70
> Dec 22 16:03:40 pvr [<c029f77c>] dvb_usercopy+0xdc/0x156
> Dec 22 16:03:40 pvr [<c016a990>] chrdev_open+0x0/0x1d0
> Dec 22 16:03:40 pvr [<c01601a6>] dentry_open+0xc6/0x270
> Dec 22 16:03:40 pvr [<c01600cc>] filp_open+0x5c/0x70
> Dec 22 16:03:40 pvr [<c01611a4>] vfs_write+0xb4/0x160
> Dec 22 16:03:40 pvr [<c029f226>] dvb_generic_ioctl+0x46/0x50
> Dec 22 16:03:40 pvr [<c02a7ba0>] dvb_frontend_ioctl+0x0/0x6a0
> Dec 22 16:03:40 pvr [<c01747de>] sys_ioctl+0x1ee/0x250
> Dec 22 16:03:40 pvr [<c01031f9>] sysenter_past_esp+0x52/0x71
> Dec 22 16:03:40 pvr Code: 70 28 8b 46 0c 89 44 24 10 b8 a1 ff ff ff 89 44
> 24 0c a1 f0 c1 58 c0 85 c0 0f 85 00 01 00 00 85 f6 $
>
>
> Now obviously idiocy on my part can't be excluded, but I wondered if anyone
> had any thoughts?
I think that would solve your problem ..

Manu
>
> Kind regards
>
>
> Benedict White