The changes to line_size in 2.6.29 now cause
attempts to record from my PVR250 cards (MythTV)
to die with a divide by zero error in ivtv-vbi.c.
The value of "line_size" in compress_sliced_buf() is zero.
divide error: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/block/sr0/removable
CPU 0
Modules linked in: nfsd nfs lockd nfs_acl auth_rpcgss sunrpc ir_kbd_i2c ir_common battery sbs sbshc container ac usbhid tuner msp3400 saa7115 fan ivtv serio_raw nvidia(P) sky2 cx2341x firewire_ohci ehci_hcd thermal sg uhci_hcd intel_agp button processor xc5000 au8522 tea5767 tda9887 tda8290 tea5761 snd_usb_audio snd_usb_lib snd_hwdep au0828 usbcore tveeprom dvb_core snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc firewire_sbp2 firewire_core crc_itu_t fuse
Pid: 18548, comm: mythbackend Tainted: P A 2.6.29 #1 OEM
RIP: 0010:[<ffffffffa09cabc4>] [<ffffffffa09cabc4>] compress_sliced_buf+0x5c/0x14a [ivtv]
RSP: 0018:ffff88004e3b1c58 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88007c1b8300 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88007b5a0000
RBP: ffff88007c1b8000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffffa09c0818 R12: ffff88007b5a0000
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88007b5a0000
FS: 000000004f219950(0063) GS:ffffffff80683040(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fd267365000 CR3: 0000000078dea000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mythbackend (pid: 18548, threadinfo ffff88004e3b0000, task ffff880056895580)
Stack:
0000000000000000 ffff88007d199440 ffff88007e0e4e40 0000000000000202
ffff880001013100 0000000000000000 ffff880001013118 ffffffff80219939
0000000000000002 0000000000000300 ffff88007c1b8000 ffff88007b5a0000
Call Trace:
[<ffffffff80219939>] ? native_flush_tlb_others+0xaa/0xb5
[<ffffffffa09cb4a3>] ? ivtv_process_vbi_data+0x10f/0x51c [ivtv]
[<ffffffff8026de33>] ? __do_fault+0x399/0x3e1
[<ffffffff80223434>] ? ptep_set_access_flags+0x1a/0x1e
[<ffffffff8026e6bd>] ? do_wp_page+0x5d8/0x64d
[<ffffffffa09c0502>] ? ivtv_start_capture+0x54/0x217 [ivtv]
[<ffffffffa09c0d8f>] ? ivtv_v4l2_read+0x577/0xac4 [ivtv]
[<ffffffff80247d42>] ? getnstimeofday+0x56/0xb0
[<ffffffff80244ad7>] ? ktime_get_ts+0x21/0x49
[<ffffffff80241f34>] ? autoremove_wake_function+0x0/0x2e
[<ffffffff802853e3>] ? vfs_read+0xaa/0x133
[<ffffffff80285528>] ? sys_read+0x45/0x6e
[<ffffffff8020b49b>] ? system_call_fastpath+0x16/0x1b
Code: 0f 80 7b 02 00 75 09 8a 54 24 1f 38 53 03 74 09 ff c0 48 ff c3 39 c8 72 dd 29 c1 89 c8 44 39 f1 0f 82 e1 00 00 00 31 d2 45 31 ed <41> f7 f6 45 31 e4 89 44 24 18 31 ed e9 c0 00 00 00 89 e8 48 8d
RIP [<ffffffffa09cabc4>] compress_sliced_buf+0x5c/0x14a [ivtv]
RSP <ffff88004e3b1c58>
---[ end trace a154c5e5843294d8 ]---
On Monday 30 March 2009 04:59:34 Mark Lord wrote:
> The changes to line_size in 2.6.29 now cause
> attempts to record from my PVR250 cards (MythTV)
> to die with a divide by zero error in ivtv-vbi.c.
>
> The value of "line_size" in compress_sliced_buf() is zero.
Weird. That should never be zero. Can you mail me the ivtv initialization
log from dmesg? I need the bit between 'ivtv: Start initialization'
and 'ivtv: End initialization'.
Regards,
Hans
>
> divide error: 0000 [#1] PREEMPT SMP
> last sysfs file: /sys/block/sr0/removable
> CPU 0
> Modules linked in: nfsd nfs lockd nfs_acl auth_rpcgss sunrpc ir_kbd_i2c
> ir_common battery sbs sbshc container ac usbhid tuner msp3400 saa7115 fan
> ivtv serio_raw nvidia(P) sky2 cx2341x firewire_ohci ehci_hcd thermal sg
> uhci_hcd intel_agp button processor xc5000 au8522 tea5767 tda9887 tda8290
> tea5761 snd_usb_audio snd_usb_lib snd_hwdep au0828 usbcore tveeprom
> dvb_core snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss
> snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi
> snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore
> snd_page_alloc firewire_sbp2 firewire_core crc_itu_t fuse Pid: 18548,
> comm: mythbackend Tainted: P A 2.6.29 #1 OEM RIP:
> 0010:[<ffffffffa09cabc4>] [<ffffffffa09cabc4>]
> compress_sliced_buf+0x5c/0x14a [ivtv] RSP: 0018:ffff88004e3b1c58 EFLAGS:
> 00010246
> RAX: 0000000000000000 RBX: ffff88007c1b8300 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88007b5a0000
> RBP: ffff88007c1b8000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: ffffffffa09c0818 R12: ffff88007b5a0000
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88007b5a0000
> FS: 000000004f219950(0063) GS:ffffffff80683040(0000)
> knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fd267365000 CR3: 0000000078dea000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process mythbackend (pid: 18548, threadinfo ffff88004e3b0000, task
> ffff880056895580) Stack:
> 0000000000000000 ffff88007d199440 ffff88007e0e4e40 0000000000000202
> ffff880001013100 0000000000000000 ffff880001013118 ffffffff80219939
> 0000000000000002 0000000000000300 ffff88007c1b8000 ffff88007b5a0000
> Call Trace:
> [<ffffffff80219939>] ? native_flush_tlb_others+0xaa/0xb5
> [<ffffffffa09cb4a3>] ? ivtv_process_vbi_data+0x10f/0x51c [ivtv]
> [<ffffffff8026de33>] ? __do_fault+0x399/0x3e1
> [<ffffffff80223434>] ? ptep_set_access_flags+0x1a/0x1e
> [<ffffffff8026e6bd>] ? do_wp_page+0x5d8/0x64d
> [<ffffffffa09c0502>] ? ivtv_start_capture+0x54/0x217 [ivtv]
> [<ffffffffa09c0d8f>] ? ivtv_v4l2_read+0x577/0xac4 [ivtv]
> [<ffffffff80247d42>] ? getnstimeofday+0x56/0xb0
> [<ffffffff80244ad7>] ? ktime_get_ts+0x21/0x49
> [<ffffffff80241f34>] ? autoremove_wake_function+0x0/0x2e
> [<ffffffff802853e3>] ? vfs_read+0xaa/0x133
> [<ffffffff80285528>] ? sys_read+0x45/0x6e
> [<ffffffff8020b49b>] ? system_call_fastpath+0x16/0x1b
> Code: 0f 80 7b 02 00 75 09 8a 54 24 1f 38 53 03 74 09 ff c0 48 ff c3 39
> c8 72 dd 29 c1 89 c8 44 39 f1 0f 82 e1 00 00 00 31 d2 45 31 ed <41> f7 f6
> 45 31 e4 89 44 24 18 31 ed e9 c0 00 00 00 89 e8 48 8d RIP
> [<ffffffffa09cabc4>] compress_sliced_buf+0x5c/0x14a [ivtv]
> RSP <ffff88004e3b1c58>
> ---[ end trace a154c5e5843294d8 ]---
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
Hans Verkuil wrote:
> On Monday 30 March 2009 04:59:34 Mark Lord wrote:
>> The changes to line_size in 2.6.29 now cause
>> attempts to record from my PVR250 cards (MythTV)
>> to die with a divide by zero error in ivtv-vbi.c.
>>
>> The value of "line_size" in compress_sliced_buf() is zero.
>
> Weird. That should never be zero. Can you mail me the ivtv initialization
> log from dmesg? I need the bit between 'ivtv: Start initialization'
> and 'ivtv: End initialization'.
..
Sent.
Mark Lord wrote:
> Hans Verkuil wrote:
>> On Monday 30 March 2009 04:59:34 Mark Lord wrote:
>>> The changes to line_size in 2.6.29 now cause
>>> attempts to record from my PVR250 cards (MythTV)
>>> to die with a divide by zero error in ivtv-vbi.c.
>>>
>>> The value of "line_size" in compress_sliced_buf() is zero.
>>
>> Weird. That should never be zero. Can you mail me the ivtv
>> initialization log from dmesg? I need the bit between 'ivtv: Start
>> initialization' and 'ivtv: End initialization'.
> ..
>
> Sent.
..
For what it's worth, I did try patching that function to detect
a line_size of zero, and replace it on the fly with a more likely value.
This prevented the crash, but the recorded video was very dark, as if
colour controls had not be initialized. That could be another clue.
Cheers
Hans Verkuil wrote:
> On Monday 30 March 2009 17:50:33 Mark Lord wrote:
>> Hans Verkuil wrote:
..
>>> Hmm, is v4l2_common also a module? There is a bug there that could
>>> explain it, but only if v4l2_common is compiled into the kernel.
>> ..
>> Ah, yes I don't see that in lsmod, and I do appear to have
>> CONFIG_VIDEO_V4L2_COMMON=y in the .config file. I'll rebuild as module
>> and try again. Is there a fix heading upstream (2.6.29.1) for that?
>
> Ah! That's it then. I definitely need to send a fix for that upstream. It is
> in the v4l-dvb repository. I need to wait until the fix is merged in Linus'
> git tree, though, before I can get it in the stable series.
..
> Let me know if building v4l2-common as a module will fix this. I'm positive
> it will.
..
Works like a charm. Thanks so much, Hans!
Cheers