Skip to contentSkip to conversation

mantis crash...

linux-dvb Roland Scheidegger 2 participants 3 messages May 2, 2008 – May 5, 2008 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

This was reported before, the current mantis driver will cause a page fault in mantis_dvb_start_feed.
The reason for this is commit f5b1f9d491bfabbd23ec415e647f3d65ea1930eb "Implement HIF Mem Read/Write operations". I don't know how HIF memory reads/writes are supposed to work, but there seems to be some mixup between register contents and register addresses. Clearly, 0xfffffff is not a valid mmaped reg address and as such writing to it blows up accordingly.
The attached patch fixes that (reverts part of the above commit). The same bug also seems to be present in the hif.c file, though I don't know how it should work there (and it looks like that code won't get touched here).

Roland

linux/drivers/media/dvb/mantis/mantis_dma.c +2 -2
@@ -190,7 +190,7 @@ void mantis_dma_start(struct mantis_pci 
 
 	mantis_risc_program(mantis);
 	mmwrite(mantis->risc_dma, MANTIS_RISC_START);
-	mmwrite(mmread(MANTIS_GPIF_HIFADDR) | MANTIS_GPIF_HIFRDWRN, MANTIS_GPIF_HIFADDR);
+	mmwrite(mmread(MANTIS_GPIF_ADDR) | MANTIS_GPIF_HIFRDWRN, MANTIS_GPIF_ADDR);
 
 	mmwrite(0, MANTIS_DMA_CTL);
 	mantis->last_block = mantis->finished_block = 0;
@@ -210,7 +210,7 @@ void mantis_dma_stop(struct mantis_pci *
 	mask = mmread(MANTIS_INT_MASK);
 	dprintk(verbose, MANTIS_DEBUG, 1, "Mantis Stop DMA engine");
 
-	mmwrite((mmread(MANTIS_GPIF_HIFADDR) & (~(MANTIS_GPIF_HIFRDWRN))), MANTIS_GPIF_HIFADDR);
+	mmwrite((mmread(MANTIS_GPIF_ADDR) & (~(MANTIS_GPIF_HIFRDWRN))), MANTIS_GPIF_ADDR);
 
 	mmwrite((mmread(MANTIS_DMA_CTL) & ~(MANTIS_FIFO_EN |
 					    MANTIS_DCAP_EN |

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#1 lore raw
Quoted 3 lines · Roland Scheidegger

This was reported before, the current mantis driver will cause a page fault in mantis_dvb_start_feed.

Dear Roland,

I applied your patch to the code I got from

http://jusst.de/hg/mantis

Now the mantis driver (for 2033) works fine for me.

Setup: 2.6.22.19

             vdr-1.5.18/xineliboutput

Unfortunately, as soon as I insert the CAM module, the driver crashes. According to the logfile, it looks that "vdr" still gets the information about the CAM and tries to access it.
Then the driver crashes. Maybe someone still has an idea how to dig into this.

May  3 22:34:34 linux-sh8m vdr: [7645] changing pids of channel 58 from 
901+901:902:0:204 to 701+701:702:0:204
May  3 22:34:51 linux-sh8m vdr: [7643] CAM 1: module present
May  3 22:34:54 linux-sh8m kernel: Unable to handle kernel paging 
request at ffffc20010681fff RIP:
May  3 22:34:54 linux-sh8m kernel:  [<ffffffff88132bfc>] 
:mantis:mantis_hif_read_mem+0x6c/0x250
May  3 22:34:54 linux-sh8m kernel: PGD 37ce5067 PUD 37ce4067 PMD 0
May  3 22:34:54 linux-sh8m kernel: Oops: 0002 [1] PREEMPT
May  3 22:34:54 linux-sh8m kernel: CPU 0
May  3 22:34:54 linux-sh8m kernel: Modules linked in: snd_ice1724 

snd_ice17xx_ak4xxx snd_ac97_codec snd_ak4114 snd_pcm snd_timer snd_pt2258
snd_i2c snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore button mantis mb86a16 tda10021 stv0299 ip6t_LOG nf_conntr ack_ipv6 xt_pkttype ipt_LOG xt_limit kqemu(P) af_packet cpufreq_conservative cpufreq_ondemand cpufreq_performance cpufreq_powersave thermal
fan evdev battery ac isofs nls_iso8859_1 nls_cp437 vfat fat nls_utf8
ntfs loop md_mod dm_mod ip6t_REJECT xt_tcpudp ipt_REJECT xt_state ipt able_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables
x_tables ipv6 vboxdrv rtc w83627hf hwmon_vid powernow_k8 freq_table
processor usbhid lirc_mceusb2(F) nvidia(P) lirc_dev ide_cd cdrom ac97_ bus snd_page_alloc ohci1394 lnbp21 stb6100 tda10023 stb0899 ieee1394 8139too dvb_core ohci_hcd ehci_hcd usbcore k8temp i2c_piix4 lp bttv ir _common compat_ioctl32 videodev v4l1_compat i2c_algo_bit v

May  3 22:34:54 linux-sh8m kernel: 4l2_common videobuf_dma_sg 
videobuf_core btcx_risc tveeprom i2c_core sg
May  3 22:34:54 linux-sh8m kernel: Pid: 7340, comm: kdvb-ca-0:0 Tainted: 
PF      2.6.22.19 #6
May  3 22:34:54 linux-sh8m kernel: RIP: 0010:[<ffffffff88132bfc>]  
[<ffffffff88132bfc>] :mantis:mantis_hif_read_mem+0x6c/0x250
May  3 22:34:54 linux-sh8m kernel: RSP: 0018:ffff810059a7fcd0  EFLAGS: 
00010216
May  3 22:34:54 linux-sh8m kernel: RAX: ffffc20000682000 RBX: 
0000000080000000 RCX: 0000000032382dd0
May  3 22:34:54 linux-sh8m kernel: RDX: 0000000000000ab6 RSI: 
0000000000000000 RDI: 00000000000001f4
May  3 22:34:54 linux-sh8m kernel: RBP: ffff81007c2df480 R08: 
ffff810059a7fee8 R09: ffff810059a7fde0
May  3 22:34:54 linux-sh8m kernel: R10: 0000000000000000 R11: 
ffffffff80460050 R12: ffff810059a7fde0
May  3 22:34:54 linux-sh8m kernel: R13: 0000000000000000 R14: 
ffff8100402c8000 R15: 0000000000000000
May  3 22:34:54 linux-sh8m kernel: FS:  00002b5a665b7d00(0000) 
GS:ffffffff80604000(0000) knlGS:00000000f7d0f6c0
May  3 22:34:54 linux-sh8m kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 
000000008005003b
May  3 22:34:54 linux-sh8m kernel: CR2: ffffc20010681fff CR3: 
0000000077a14000 CR4: 00000000000006e0
May  3 22:34:54 linux-sh8m kernel: Process kdvb-ca-0:0 (pid: 7340, 
threadinfo ffff810059a7e000, task ffff81005aacf750)
May  3 22:34:54 linux-sh8m kernel: Stack:  ffff810059a7fd50 
ffff81005aacf750 ffff81005a1370e0 000000000000083e
May  3 22:34:54 linux-sh8m kernel:  ffffffff80656560 ffffffff805c6360 
0000000000000058 0000000000000000
May  3 22:34:54 linux-sh8m kernel:  0000000000000000 ffff810059a7fde0 
0000000000000000 ffff810059a7fee4
May  3 22:34:54 linux-sh8m kernel: Call Trace:
May  3 22:34:55 linux-sh8m vdr: [7644] frontend 0 lost lock on channel 
25, tp 113
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff880d1bc4>] 
:dvb_core:dvb_ca_en50221_read_tuple+0x34/0x190
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff880d31db>] 
:dvb_core:dvb_ca_en50221_thread+0x49b/0xa10
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff80223e07>] 
__wake_up_common+0x47/0x70
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff80223f8f>] 
__activate_task+0x2f/0x50
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff804d6b59>] 
thread_return+0x0/0x3d7
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff880d2d40>] 
:dvb_core:dvb_ca_en50221_thread+0x0/0xa10
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff880d2d40>] 
:dvb_core:dvb_ca_en50221_thread+0x0/0xa10
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff8023eceb>] kthread+0x4b/0x80
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff8020a3c8>] child_rip+0xa/0x12
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff8023eca0>] kthread+0x0/0x80
May  3 22:34:55 linux-sh8m kernel:  [<ffffffff8020a3be>] child_rip+0x0/0x12
May  3 22:34:55 linux-sh8m kernel:
May  3 22:34:55 linux-sh8m kernel:
May  3 22:34:55 linux-sh8m kernel: Code: 89 98 ff ff ff 0f 4c 8b bd 98 
00 00 00 e8 d2 b6 0f f8 f6 85
May  3 22:34:56 linux-sh8m kernel: RIP  [<ffffffff88132bfc>] 
:mantis:mantis_hif_read_mem+0x6c/0x250
May  3 22:34:56 linux-sh8m kernel:  RSP <ffff810059a7fcd0>
May  3 22:34:56 linux-sh8m kernel: CR2: ffffc20010681fff
May  3 22:34:58 linux-sh8m vdr: [7644] frontend 0 timed out while tuning 

to channel 25, tp 113

~

~

~

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#2 lore raw
Quoted 10 lines · Ruediger Dohmhardt
Quoted 3 lines · Roland Scheidegger

This was reported before, the current mantis driver will cause a page fault in mantis_dvb_start_feed.

Dear Roland,

I applied your patch to the code I got from

http://jusst.de/hg/mantis

Quoted 8 lines

Now the mantis driver (for 2033) works fine for me.

Setup: 2.6.22.19 vdr-1.5.18/xineliboutput

Unfortunately, as soon as I insert the CAM module, the driver crashes. According to the logfile, it looks that "vdr" still gets the information about the CAM and tries to access it. Then the driver crashes. Maybe someone still has an idea how to dig into this.

Yes, the crash is due to the same (or similar) bogus hif reads/writes as that fixed in the patch obviously - that code gets only used with a CAM. There are mmreads/mmwrites to MANTIS_GPIF_HIFADDR, MANTIS_GPIF_HIFDIN and MANTIS_GPIF_HIFDOUT - I'm sure all of them will blow up (they are all the exact same value anyway).
But I wouldn't know how to fix this - I suspect those values are actually masks which you'd or with some other values for accessing values not directly accessible in registers. That's just speculation however, I don't even have a clue what "HIF" stands for (well I guess something with interface?). Fixing it would require a chip datasheet at least (or (working) example code), or reverse engeneering or whatever. Even if this particular hif read/write issue was fixed I'd highly doubt though the cam code would actually work in its current state - apparently it was never tested nor working. So Manu Abraham needs to fix it I suspect - unfortunately there were no updates for over two weeks now.

Roland

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb