Hans,
The latest ivtv-0.4 branch did not work. It crashed after a couple of
hours. Here's the dump, and I'll send you my IVTV INIT lines in a
separate email. Unfortunately, I'll have to revert back to 0.4.6, which
I know was stable, even though I'll have to use a separate tuner for
video since video and VBI didn't work together well in that version
(audio/video out of sync):
Jan 30 11:59:39 server1 kernel: Unable to handle kernel paging request
at virtual address 05bf0d10
Jan 30 11:59:39 server1 kernel: printing eip:
Jan 30 11:59:39 server1 kernel: f491c361
Jan 30 11:59:39 server1 kernel: *pde = 00007001
Jan 30 11:59:39 server1 kernel: Oops: 0000 [#1]
Jan 30 11:59:39 server1 kernel: SMP
Jan 30 11:59:39 server1 kernel: Modules linked in: tda9887(U) msp3400(U)
saa7115(U) tuner(U) tveeprom(U) ivtv(U) parport_pc lp parport autofs4
sunrpc iptable_nat iptable_mangle ipt_REJECT ipt_multiport ipt_state
ip_conntrack iptable_filter ip_tables dm_multipath button battery ac md5
ipv6 uhci_hcd ehci_hcd i2c_algo_bit i2c_core videodev hw_random e1000
floppy sg dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod megaraid_mbox
megaraid_mm sd_mod scsi_mod
Jan 30 11:59:39 server1 kernel: CPU: 3
Jan 30 11:59:39 server1 kernel: EIP: 0060:[<f491c361>] Not tainted VLI
Jan 30 11:59:39 server1 kernel: EFLAGS: 00010246 (2.6.9-34.0.1.ELsmp)
Jan 30 11:59:39 server1 kernel: EIP is at ivtv_sched_VBI+0x16a/0x643 [ivtv]
Jan 30 11:59:39 server1 kernel: eax: f5b00000 ebx: ed0c0000 ecx:
100f0d14 edx: 00000000
Jan 30 11:59:39 server1 kernel: esi: ed0c0000 edi: 00000000 ebp:
ed0e99a8 esp: eaf0ef10
Jan 30 11:59:39 server1 kernel: ds: 007b es: 007b ss: 0068
Jan 30 11:59:39 server1 kernel: Process ivtv-enc-vbi (pid: 7196,
threadinfo=eaf0e000 task=f2f2d330)
Jan 30 11:59:39 server1 kernel: Stack: c384e780 c384dde0 00000000
00000000 dffb0800 00000000 05bf0d14 e02ed080
Jan 30 11:59:39 server1 kernel: 100f0d14 00008880 00000002
ed0c0000 eaf0ef40 eaf0ef40 00000000 f2f2d330
Jan 30 11:59:39 server1 kernel: c011e71b 00000000 00000000
f2ebf1b0 00000000 c3856740 00000000 f2f2d330
Jan 30 11:59:39 server1 kernel: Call Trace:
Jan 30 11:59:39 server1 kernel: [<c011e71b>] default_wake_function+0x0/0xc
Jan 30 11:59:39 server1 kernel: [<c011e71b>] default_wake_function+0x0/0xc
Jan 30 11:59:39 server1 kernel: [<f491ee99>]
enc_vbi_work_handler+0x27/0x32 [ivtv]
Jan 30 11:59:39 server1 kernel: [<f49203bc>]
ivtv_enc_vbi_thread+0x1a8/0x1c0 [ivtv]
Jan 30 11:59:39 server1 kernel: [<c0120291>]
autoremove_wake_function+0x0/0x2d
Jan 30 11:59:39 server1 kernel: [<c02d25ae>] ret_from_fork+0x6/0x14
Jan 30 11:59:39 server1 kernel: [<c0120291>]
autoremove_wake_function+0x0/0x2d
Jan 30 11:59:39 server1 kernel: [<f4920214>]
ivtv_enc_vbi_thread+0x0/0x1c0 [ivtv]
Jan 30 11:59:39 server1 kernel: [<c01041f5>] kernel_thread_helper+0x5/0xb
Jan 30 11:59:39 server1 kernel: Code: 74 17 50 51 51 50 ff b3 b0 00 00
00 68 e5 e0 92 f4 e8 ee 62 80 cb 83 c4 18 8b 54 24 2c 31 ff 8b 4c 24 20
8b 82 20 19 00 00 89 fa <8b> 74 08 fc 8b 4c 08 f8 89 f0 89 cb 31 c9 09
da 09 c8 f6 05 c8
Jan 30 11:59:39 server1 kernel: <0>Fatal exception: panic in 5 seconds
Rich Kadel wrote:
Hans,
I am trying the latest version from your "viewcvs" link below now.
(Last night 0.4.9 crashed again, even though I was only using two
PVR-250s, so it's not the PVR-500s and it doesn't appear to be the
load, since 0.4.6 was very stable with three PVR-250s.) Hopefully
your latest fixes will solve this stability problem, and I can then
try the PVR-500s again.
FYI, I have to change the Makefile everytime I compile because my
kernel is 2.6.9, and the "version check" fails. The string comparison
between 2.6.9 and 2.6.15 does not return the results expected. Here
is a fix if you want to replace the corresponding line in the Makefile:
@UNAME=`uname -r | sed 's/-.*//;s/\.\([0-9]\)$$/.0\1/' | cut -d . -f
1-3`; \
Thanks,
Rich
Hans Verkuil wrote:
On Monday 29 January 2007 18:11, Rich Kadel wrote:
My newlines keep getting cut off... last attempt:
Thanks,
I recommend trying the latest version of the ivtv-0.4 branch:
http://ivtvdriver.org/viewcvs/ivtv/branches/0.4.tar.gz?view=tar
It may be that ivtv-0.4.9 is still trying to allocate new buffers in
some circumstances. Something that it really shouldn't be doing. This
should be fixed in the latest SVN version.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
