[mythtv-users] Mythbackend Segfault on Delete -- It's Baaaa-aaak!!
Kirk Bocek
t004 at kbocek.com
Fri Jan 26 22:24:25 UTC 2007
I *thought* I had it solved. Yes, mythlib did need to be updated. But now when
I start a recording on the HD-5500 I get:
cx88[0]: irq aud [0x201001] dn_risci1* dn_sync* mchg_irq
cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
Unable to handle kernel paging request at ffff80ff05698508 RIP:
[<ffffffff802fb6d6>] sync_single+0x1d/0x7e
PGD 0
Oops: 0000 [1] SMP
CPU 1
Modules linked in: cx88_dvb cx88_vp3054_i2c mt352 dvb_pll or51132
video_buf_dvb dvb_core nxt200x isl6421 zl10353 cx24123 lgdt330x cx22702 nfsd
exportfs lockd nfs_acl parport_pc lp parport autofs4 tun sunrpc ipmi_devintf
ipmi_si ipmi_msghandler xt_state xt_tcpudp iptable_filter iptable_nat ip_nat
ip_conntrack nfnetlink ip_tables x_tables xfs tsdev joydev video usb_storage
button battery asus_acpi ac uhci_hcd ehci_hcd cx88_alsa snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc cx88_blackbird
cx8802 cx2341x tuner cx8800 cx88xx ir_common i2c_algo_bit video_buf tveeprom
compat_ioctl32 btcx_risc videodev v4l1_compat v4l2_common i2c_i801 i2c_core
shpchp via_rhine e1000 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx sd_mod scsi_mod
Pid: 22680, comm: mythbackend Not tainted 2.6.18.6smp-beryl-04 #1
RIP: 0010:[<ffffffff802fb6d6>] [<ffffffff802fb6d6>] sync_single+0x1d/0x7e
RSP: 0018:ffff8101103dbcc0 EFLAGS: 00010246
RAX: ffffffffe00032a1 RBX: ffff810111c21000 RCX: 0000000000000002
RDX: ffff81000567f000 RSI: 0000000002faf800 RDI: ffff81013ae1c070
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000001000
R10: 0000000100000000 R11: ffffffff802fbeb9 R12: 0000000000000002
R13: 0000000000000071 R14: ffff81013ae1c070 R15: 0000000000000000
FS: 0000000048810960(0063) GS:ffff81013ac8dac0(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff80ff05698508 CR3: 0000000114e45000 CR4: 00000000000006e0
Process mythbackend (pid: 22680, threadinfo ffff8101103da000, task
ffff8101131aa080)
Stack: ffffffff802fbf41 ffff810139858c30 ffff810134cf2868 ffff81013ae1c000
0000000000000000 ffff8101103dbdf8 ffffffff880fe609 ffff810139858c00
ffff810139858c68 ffff810134cf2868 ffffffff880ff224 0000000000000000
Call Trace:
[<ffffffff802fbf41>] swiotlb_sync_sg_for_cpu+0x88/0x99
[<ffffffff880fe609>] :video_buf:videobuf_dma_sync+0x6b/0x72
[<ffffffff880ff224>] :video_buf:videobuf_dqbuf+0x144/0x1a4
[<ffffffff88126b44>] :cx8800:video_do_ioctl+0x3a6/0x443
[<ffffffff80222de7>] task_rq_lock+0x3d/0x6f
[<ffffffff8022303b>] __activate_task+0x2a/0x3c
[<ffffffff80223870>] try_to_wake_up+0x350/0x362
[<ffffffff880e93bf>] :videodev:video_usercopy+0x131/0x1c8
[<ffffffff8812679e>] :cx8800:video_do_ioctl+0x0/0x443
[<ffffffff8043079a>] __up_wakeup+0x35/0x67
[<ffffffff88126bf6>] :cx8800:video_ioctl+0x15/0x6e
[<ffffffff80286591>] do_ioctl+0x5d/0x6f
[<ffffffff8028680f>] vfs_ioctl+0x26c/0x27d
[<ffffffff80286879>] sys_ioctl+0x59/0x7c
[<ffffffff80209622>] system_call+0x7e/0x83
Code: 4c 8b 14 c2 74 07 41 ff c8 74 29 eb 49 83 f9 02 0f 94 c2 85
RIP [<ffffffff802fb6d6>] sync_single+0x1d/0x7e
RSP <ffff8101103dbcc0>
CR2: ffff80ff05698508
<3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
Call Trace:
[<ffffffff80222d67>] __might_sleep+0xb3/0xb5
[<ffffffff8023fc31>] down_read+0x15/0x1e
[<ffffffff8023752b>] blocking_notifier_call_chain+0x13/0x36
[<ffffffff8022d52e>] do_exit+0x22/0x8d5
[<ffffffff80430af1>] _spin_lock_irqsave+0x9/0xe
[<ffffffff8030cad2>] vgacon_set_cursor_size+0x33/0xd0
[<ffffffff80432c71>] do_page_fault+0x71d/0x78b
[<ffffffff802251bb>] default_wake_function+0x0/0xe
[<ffffffff80256247>] __alloc_pages+0x66/0x2b1
[<ffffffff8020a2f1>] error_exit+0x0/0x84
[<ffffffff802fbeb9>] swiotlb_sync_sg_for_cpu+0x0/0x99
[<ffffffff802fb6d6>] sync_single+0x1d/0x7e
[<ffffffff802fbf41>] swiotlb_sync_sg_for_cpu+0x88/0x99
[<ffffffff880fe609>] :video_buf:videobuf_dma_sync+0x6b/0x72
[<ffffffff880ff224>] :video_buf:videobuf_dqbuf+0x144/0x1a4
[<ffffffff88126b44>] :cx8800:video_do_ioctl+0x3a6/0x443
[<ffffffff80222de7>] task_rq_lock+0x3d/0x6f
[<ffffffff8022303b>] __activate_task+0x2a/0x3c
[<ffffffff80223870>] try_to_wake_up+0x350/0x362
[<ffffffff880e93bf>] :videodev:video_usercopy+0x131/0x1c8
[<ffffffff8812679e>] :cx8800:video_do_ioctl+0x0/0x443
[<ffffffff8043079a>] __up_wakeup+0x35/0x67
[<ffffffff88126bf6>] :cx8800:video_ioctl+0x15/0x6e
[<ffffffff80286591>] do_ioctl+0x5d/0x6f
[<ffffffff8028680f>] vfs_ioctl+0x26c/0x27d
[<ffffffff80286879>] sys_ioctl+0x59/0x7c
[<ffffffff80209622>] system_call+0x7e/0x83
Then when I tried to access mythbackend via mythweb:
mythbackend[22681]: segfault at 00002aaaaaf25210 rip 000000317f67f357 rsp
0000000049010f60 error 4
And then I have a '[mythbackend] <defunct>' in my 'ps -ef' listing. The
zombied mythbackend cannot be removed by anything other than a reboot.
This is a stock 2.6.18.6 kernel on an x86_64 SMP host using the kernel cx8800
drivers.
Can anyone provide any suggestions?
===================
My problem was a libmyth package that was older than the mythbackend package.
I was accidentally entering 'yum update myth\*' to update instead of 'yum
update \*myth\*' when updating from atrpms.
Hey, Axel, I thought yum was supposed to at least warn about dependencies like
this?
Kirk Bocek
Kirk Bocek wrote:
> After I let all the startup messages settle down, as usual, I went into
> mythweb and attempted to delete one recording. the results:
>
> 2007-01-18 15:46:58.309 MainServer::HandleAnnounce Monitor
> 2007-01-18 15:46:58.310 adding: beryl as a client (events: 0)
> 2007-01-18 15:47:01.020 MainServer::HandleAnnounce Monitor
> 2007-01-18 15:47:01.020 adding: beryl as a client (events: 0)
> 2007-01-18 15:47:01.051 Preview Error: Previewer file
> '/mnt/mythtv/12282_20070118113500.mpg' is not valid.
> 2007-01-18 15:47:01.051 MainServer: Failed to make preview image.
> 2007-01-18 15:47:01.052 MainServer::HandleAnnounce FileTransfer
> 2007-01-18 15:47:01.052 adding: beryl as a remote file transfer
> 2007-01-18 15:47:07.554 RingBuf(/mnt/mythtv/12282_20070118113500.mpg.png):
> Could not open /mnt/mythtv/12282_20070118113500.mpg.png.
> 2007-01-18 15:47:11.574 MainServer::HandleAnnounce Monitor
> 2007-01-18 15:47:11.574 adding: beryl as a client (events: 0)
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1191237984 (LWP 7538)]
> 0x0000000000000000 in ?? ()
>
> So I tried touching the missing /mnt/mythtv/12282_20070118113500.mpg.png. I
> restarted mythbackend and tried again. Same segfault.
>
> So I tried manually deleting both files. I reran mythbackend. Same segfault.
>
> Do you think the issue might be with:
> adding: beryl as a remote file transfer
>
> This is a master server and everything is local.
>
> Gareth Glaccum wrote:
>> I think unfortunately that mine might be different. It seems that very
>> recently a patch for generating previews was applied. I think that this
>> should fix my issue. If one of you could perform the following:
>> (stop mythbackend)
>> in a terminal:
>> gdb mythbackend
>> ->run
>>
>> Then cause the segfault
>>
>> -> where
>>
>> and submit the output (and last couple of lines) that may help in
>> determining where the issue is.
>> Gareth
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
More information about the mythtv-users
mailing list