I wanted to pass on along my /var/log/messages dump after a kernel panic I
was not able to resolve.

 

As background, several months ago, Hans Verkuil tried to help me debug the
IVTV driver which was crashing on load when I would try to load the driver
with a PVR-500 installed.  I never got it to load consistently, but was able
to get it to load a couple of times after putting a "sleep" in a certain
spot in the driver.   I had to put the server into production, so I was not
able to debug this any further, and resorted to using PVR-250s, which have
worked flawlessly for months now.

 

Fast-forward to now, I noticed recent driver release notes show fixes to the
kind of problem I was having, and sure enough, the new driver appears to
load just fine with my PVR-500s.  I put 3 PVR-500s in my system, rebooted 4
times, and it appeared to work.

 

I launched my application which reads VBI data (from /dev/vbi) from all 6
tuners, and simultaneously reads video from at least one of those cards as
well.  (The updated drivers also fixed a bug allowing me to use a tuner for
both VBI and video without the audio going out of sync, which was a problem
with the old driver.)

 

At first I tried to read video from 2 of the tuners.  The kernel panicked
within 20 minutes.  I then dropped down to just 1 tuner reading video, and
it panicked again after about 8 hours.  Below is the kernel log from the
first panic.

 

The crashes are happening on a Dell 2850 (Intel Pentium D dual core 2.8Ghz,
4G memory) server on CentOS 4.3.  The kernel is 2.6.9-34.0.1.ELsmp.  The
Dell has only PCI-X slots, so Hauppauge had to modify the PVR-250's for this
configuration (not required for the PVR-500s).  The 2850 appears to work OK
with 3 PVR-250's, but of course, I am limited to only 3 tuners, thus 3 VBI
streams, and at the moment, only one doing video.

 

Notably, this same configuration, with the PVR-500's works fine in my
desktop PC (HP m7360n).  Both systems are dual core, same kernel, same OS,
same CPU.

 

Because the Dell 2850 is a production server, I can't do a lot of
experimenting, but I thought I'd send this log in case this is of any
benefit in making the driver more robust.

 

I appreciate the work on this driver and the progress, and hope this helps.

 

Jan 25 17:06:34 server1 kernel: Unable to handle kernel paging request at
virtual address 78e6140d Jan 25 17:06:34 server1 kernel:  printing eip:

Jan 25 17:06:34 server1 kernel: f491447d Jan 25 17:06:34 server1 kernel:
*pde = 00000000 Jan 25 17:06:34 server1 kernel: Oops: 0000 [#1] Jan 25
17:06:34 server1 kernel: SMP Jan 25 17:06:34 server1 kernel: Modules linked
in: 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 tda9887(U) wm8775(U) cx25840(U)

tuner(U) tveeprom(U) ivtv(U) 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 25 17:06:34 server1 kernel: CPU:    2

Jan 25 17:06:34 server1 kernel: EIP:    0060:[<f491447d>]    Not tainted VLI

Jan 25 17:06:34 server1 kernel: EFLAGS: 00010246   (2.6.9-34.0.1.ELsmp)

Jan 25 17:06:34 server1 kernel: EIP is at ivtv_sched_VBI+0x16a/0x643 [ivtv]

Jan 25 17:06:34 server1 kernel: eax: f9f00000   ebx: eda60000   ecx: 

7ef61411 edx: 00000000

Jan 25 17:06:34 server1 kernel: esi: eda60000   edi: 00000000   ebp: 

eda5f9a8 esp: f3974f10

Jan 25 17:06:34 server1 kernel: ds: 007b   es: 007b   ss: 0068

Jan 25 17:06:34 server1 kernel: Process ivtv-enc-vbi (pid: 2647,
threadinfo=f3974000 task=f39eb2b0) Jan 25 17:06:34 server1 kernel: Stack:
f3974f3c c011e115 00000000 00000000 dffb0d80 00000000 78e61411 f3893980

Jan 25 17:06:34 server1 kernel:        7ef61411 00008880 00000002 

eda60000 f3974f40 f3974f40 00000000 f39eb2b0

Jan 25 17:06:34 server1 kernel:        c011e71b 00000000 00000000 

f29ea7b0 00000000 c394f740 00000000 f39eb2b0 Jan 25 17:06:34 server1 kernel:
Call Trace:

Jan 25 17:06:34 server1 kernel:  [<c011e115>] load_balance_newidle+0x56/0x82
Jan 25 17:06:34 server1 kernel:  [<c011e71b>] default_wake_function+0x0/0xc
Jan 25 17:06:34 server1 kernel:  [<c011e71b>] default_wake_function+0x0/0xc
Jan 25 17:06:34 server1 kernel:  [<f4916fb5>]

enc_vbi_work_handler+0x27/0x32 [ivtv]

Jan 25 17:06:34 server1 kernel:  [<f49184d8>]
ivtv_enc_vbi_thread+0x1a8/0x1c0 [ivtv] Jan 25 17:06:34 server1 kernel:
[<c0120291>] autoremove_wake_function+0x0/0x2d Jan 25 17:06:34 server1
kernel:  [<c02d25ae>] ret_from_fork+0x6/0x14 Jan 25 17:06:34 server1 kernel:
[<c0120291>] autoremove_wake_function+0x0/0x2d Jan 25 17:06:34 server1
kernel:  [<f4918330>] ivtv_enc_vbi_thread+0x0/0x1c0 [ivtv] Jan 25 17:06:34
server1 kernel:  [<c01041f5>] kernel_thread_helper+0x5/0xb Jan 25 17:06:34
server1 kernel: Code: 74 17 50 51 51 50 ff b3 d0 00 00 00 68 ec 61 92 f4 e8
d2 e1 80 cb 83 c4 18 8b 54 24 2c 31 ff 8b 4c 24 20 8b 82 40 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 a8 Jan 25
17:06:34 server1 kernel:  <0>Fatal exception: panic in 5 seconds

 

 

 

--

 

Rich Kadel

Appeligo, Inc.

(858) 433-1747

 <http://www.appeligo.com/> www.appeligo.com

 

_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to