On Jan 28, 2007, at 4:48 PM, Rich Kadel wrote:
Rick,
No I have not tried that. Is that the solution because I got the
message "Unable to handle kernel paging request"?
Rich,
I would call it a suggestion. I don't have enough experience hacking
the kernel to give you a solution; hopefully someone more qualified
can chime in on this thread as well... But note that Hans has said
the VBI portion of the driver has yet to get looked at, so it doesn't
surprise me that there are problems with it.
I started getting similar kernel OOPS's when I was loading the
driver, and if I kept trying to load the module over and over, I
would eventually get a full on kernel panic. Reading past posts on
the issue, I stumbled upon someone saying that setting
vm.min_free_kbytes to 16MB helped out. I tried it, and sure enough it
worked.
Whether or not it will fix your problem, I can't say for 100%
certain. But it is worth a try since these "unable to handle kernel
paging request" errors plague the ivtv driver in other areas, and can
be fixed with this sysctl setting.
Hope it works,
- Rick
I will try that if I get a chance to take the system out of
production for a little while.
Thanks,
Rich
Ricardo Lugo wrote:
Have you tried setting the sysctl value:
vm.min_free_kbytes=16384
Or higher? Even though you have a ton of ram, for some reason when
the ivtv module requests memory, the kernel refuses to swap out
pages to make room for it. Even if your ram is just full of disk
cache! Forcing the kernel's vm to swap out pages early lets the
modules grab up the RAM they need.
- Rick
On Jan 27, 2007, at 10:59 PM, Rich Kadel wrote:
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
www.appeligo.com
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
