lkml.org 
[lkml]   [2003]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectVBI capture dying in 2.6.0-test7/8?
Hi,
since kernel update last thursday VBI capture is dying after (at most)
6 hours of grabbing. Grabbing process looks like if there is no input signal:

t2 S D6EE7E78 0 29539 27884 (NOTLB)
d6ee7eb0 00000082 c0130a24 d6ee7e78 00942fc6 00000000 00100100 00200200
00942fc6 1d244b3c 00000246 00000005 d6f66960 00001adf 2031f544 0000091e
d6fa9960 d8238ef8 00000001 d6ee6000 d8238f58 e299a942 e2aeae94 00000000
Call Trace:
[<c0130a24>] schedule_timeout+0x9b/0xdf
[<e299a942>] videobuf_waiton+0x92/0xee [video_buf]
[<c012029c>] default_wake_function+0x0/0x2e
[<e299bf5d>] videobuf_read_stream+0xc1/0x382 [video_buf]
[<e2acf43c>] bttv_reinit_bt848+0x116/0x1cd [bttv] << stale entry due to large videobuf_read_stream stack?
[<e2ad2e65>] bttv_read+0xb8/0x13a [bttv]
[<c016e911>] vfs_read+0xb0/0x119
[<c016eb8c>] sys_read+0x42/0x63
[<c0109ba7>] syscall_call+0x7/0xb

When I attempt to attach strace to the process, I get (my program does not handle interrupted
vbi read()):

Process 29539 attached - interrupt to quit
time([1066669984]) = 1066669984
rt_sigaction(SIGTSTP, {SIG_IGN}, {0x40045530, [], SA_RESTORER|SA_RESTART, 0x40091578}, 8) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
write(1, "\33[2;46H\33[31m\33[40m04:57:06\33[0;10m"..., 144) = 144
rt_sigaction(SIGTSTP, {0x40045530, [], SA_RESTORER|SA_RESTART, 0x40091578}, NULL, 8) = 0
open("ct2", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
write(4, "TTXDATA 1.0\32\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 16
_llseek(4, 0, [8208], SEEK_CUR) = 0
close(4) = 0
munmap(0x40016000, 4096) = 0
close(3

t2 D C10524E0 0 29539 26630 (NOTLB)
d6ee7e80 00000082 00000000 c10524e0 000001ef 00000286 00000000 c10b1c60
00001000 c10b1c60 00000246 c10b1c60 c9720960 0000293d 0c2f2d29 00001953
d6fa9960 d8238ef8 00000000 d6ee6000 d8238f58 e299a942 c9720abc 00000000
Call Trace:
[<e299a942>] videobuf_waiton+0x92/0xee [video_buf]
[<c012029c>] default_wake_function+0x0/0x2e
[<c012029c>] default_wake_function+0x0/0x2e
[<e2adadcc>] bttv_dma_free+0x4a/0x9f [bttv]
[<e299acf7>] videobuf_queue_cancel+0x10a/0x1c6 [video_buf]
[<c01303de>] update_process_times+0x46/0x52
[<e299be4e>] videobuf_read_stop+0x1b/0x69 [video_buf]
[<e2ad3344>] bttv_release+0xc2/0x138 [bttv]
[<c016fbc2>] __fput+0xdd/0xef
[<c016e069>] filp_close+0x59/0x86
[<c016e181>] sys_close+0xeb/0x1ed
[<c010fec7>] do_syscall_trace+0x35/0x6a
[<c0109ba7>] syscall_call+0x7/0xb


and it stops here, forever. FD 3 is /dev/vbi1. Do you have any idea what can be wrong?
Stacktrace suggests that bttv_reinit_bt848 was invoked before thing stopped working,
but here my expertise ends :-( Kernel is UP, with spinlock debugging enabled.
Last kernel known to work correctly is 2.6.0-test5-c1342 from Sep 25th.
Thanks,
Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.562 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site