Bug 807052

I am seeing the same problem. My usb stick is a WideView WT-220U PenType Receiver (based on ZL353) using the dvb-usb-wt220u-zl0353-01.fw firmware.

Can you post the dmesg from this?

Mauro, what else can we gather to debug this?

(In reply to comment #2)
> Can you post the dmesg from this?
> 
> Mauro, what else can we gather to debug this?

In addition to the dmesg, we also need the lsusb for the device.

Created attachment 573250 [details]
Updates after which the error occurred

Unfortunately, I won't have access to the affected computer for a week or so now. I will post the dmesg and lsusb results as soon as I can. For the time being, I think I should mention Bug 806558. The discussion there led to this bug report here. Concluding from the state of discussion at Bug 806558 it seems that either only some specific dvb usb devices are affected or the combination of (at least) one of the updates I mention there and the mentioned kernel versions determine the functionality of kaffeine. For convenience, I attached the updates I performed between the last working kaffeine tv and the first occurrence of the error.

There was a large re-work on Kernel 3.3, fixing the DVB API support. Part of
the issues can be due to that.

In thesis, they shouldn't be visible to users, but regressions might happen.

Also, there is a special case that can be visible by some:

There are a few devices whose the same frontend can work with more than one
different video standard. Those frontends are supported by the drxk and cxd2820
frontend drivers. Both support DVB-T and DVB-C. 

There was a hack on those two specific drivers inside the kernel to expose them
as two separate devices, but this were causing troubles with some applications
that were expecting them to be independent.

This hack were replaced by a proper support at Kernel v3.3. Applications using
DVBv5 API (support added on kernel in 2008) shouldn't have any troubles, but,
unfortunately, most applications are still using the legacy DVBv3 API.

With the new support, there's now just one DVB frontend on those devices, and a
simple ioctl call is enough to switch it between DVB-T, DVB-T2 and DVB-C.

Applications need to either be ported to fully support the DVBv5 API, or at
least, implement the device mode switch.

For applications using the legacy API, there's an userspace tool that allows
changing the device mode. It is part of the v4l-utils development branch.
Fedora
is using the stable branch. I'll open a BZ with regards to either upgrading it
to the development branch or to port the DVB utils there to the stable branch.

AFAIKT, no CinergyT2 or dib0700 devices use those multi-standard frontends.

@Kaffeine maintainers:

A quick fix for Kaffeine would be to do something like this:
    http://linuxtv.org/hg/dvb-apps/rev/0c9932885287

in order to use a multi-standard FE. There is also an enum call that allows detecting what video standards are supported. The code to get a list of the
standards supported by a given frontend should be done with this code:

struct dtv_properties props;
struct dtv_property dvb_prop[1];
dvb_prop[0].cmd = DTV_ENUM_DELSYS;
props.num = 1;
props.props = dvb_prop;
if (ioctl(fd, FE_GET_PROPERTY, &dtv_prop) == -1)
    return -1;

The number of supported standards will be at:
    dvb_prop[0].u.buffer.len

And the standards, in DVBv5 format, will be at:
    parms->dvb_prop[0].u.buffer.data[i]

If you're willing to add such hack at the Kaffeine code, please remember that SYS_ISDBT and SYS_CMMB should be handled on legacy code just like DVB-T, as the Kernel drivers will auto-detect the parameters that are specific to those two terrestrial standards.

Regards,
Mauro

(In reply to comment #7)
> @Kaffeine maintainers:
> 
Sorry, this comment should be at Bug 806558 instead.

(In reply to comment #6)
> For applications using the legacy API, there's an userspace tool that allows
> changing the device mode. It is part of the v4l-utils development branch.
> Fedora is using the stable branch. I'll open a BZ with regards to either
> upgrading it to the development branch or to port the DVB utils there to
> the stable branch.

Bug 807656 opened against v4l-utils.

I have a bit more information about my crash. If I turn debugging up to 2, the problem with xine seems to occur here
input_dvb: DVB GUI enabled
input_dvb: Frontend is <WideView USB DVB-T> TER Card
input_dvb: Card has no hardware decoder
input_dvb: found 111 channels...
input_dvb: searching for channel BBC FOUR
input_dvb: tuner_set_channel failed
whereas with the 3.2 kernel I get
input_dvb: DVB GUI enabled
input_dvb: Frontend is <WideView USB DVB-T> TER Card
input_dvb: Card has no hardware decoder
input_dvb: found 111 channels...
input_dvb: searching for channel BBC FOUR
input_dvb: media.dvb.tuning_timeout is 0
input_dvb: tuner_tune_it - waiting for lock...
input_dvb: status: 0

Created attachment 576005 [details]
dmesg and lsusb results concerning dvb-usb

I attached the dmesg and lsusb results as requested. This time, kernel-3.3.1-2.fc16.x86_64 was used, with the same results as before.

There's a patch submitted upstream that might solve it:
   http://patchwork.linuxtv.org/patch/10599/

I haven't reviewed it yet, but it seems that xine (and xine-lib, used on some versions of kaffeine) has a bad behaviour that could explain this bug.

(In reply to comment #13)
> There's a patch submitted upstream that might solve it:
>    http://patchwork.linuxtv.org/patch/10599/
> 
> I haven't reviewed it yet, but it seems that xine (and xine-lib, used on some
> versions of kaffeine) has a bad behaviour that could explain this bug.

That solved with xine. Scratch-build test Kernels for F16 are available at:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=3977370

Tests with Kaffeine, however, it didn't went well. It is unlikely, however, that the remaining issue has anything to do with the Kernel driver.

I'm using here (from F16/F16 updates repository):
    kaffeine-1.2.2-1.fc16.x86_64
    xine-ui-0.99.6-27.fc16.1.x86_64
    gxine-0.5.907-2.fc16.x86_64
    xine-lib-1.1.20.1-1.fc16.x86_64

From rpmfusion-free-updates repository:
    xine-lib-extras-freeworld-1.1.20.1-1.fc16.x86_64

(the system is updated)

Application: Kaffeine (kaffeine-xbu), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
165	62:	movl	(%rsp), %edi
[Current thread is 1 (Thread 0x7fa969e10840 (LWP 2909))]

Thread 9 (Thread 0x7fa958765700 (LWP 2911)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1  0x000000357bc13451 in ?? () from /usr/lib64/libxine.so.1
#2  0x0000003575807d90 in start_thread (arg=0x7fa958765700) at pthread_create.c:309
#3  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 8 (Thread 0x7fa957d5e700 (LWP 2912)):
#0  0x00000035750e85c3 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x000000358d22c08f in ?? () from /usr/lib64/libpulse.so.0
#2  0x000000358d21df06 in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
#3  0x000000358d21e539 in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
#4  0x000000358d21e5f0 in pa_mainloop_run () from /usr/lib64/libpulse.so.0
#5  0x000000358d22c03f in ?? () from /usr/lib64/libpulse.so.0
#6  0x000000358ce38be8 in ?? () from /usr/lib64/libpulsecommon-0.9.23.so
#7  0x0000003575807d90 in start_thread (arg=0x7fa957d5e700) at pthread_create.c:309
#8  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 7 (Thread 0x7fa95355c700 (LWP 2913)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:143
#1  0x000000358d22c6b0 in pa_threaded_mainloop_wait () from /usr/lib64/libpulse.so.0
#2  0x00007fa957d6115e in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_ao_out_pulseaudio.so
#3  0x000000357bc24c02 in ?? () from /usr/lib64/libxine.so.1
#4  0x0000003575807d90 in start_thread (arg=0x7fa95355c700) at pthread_create.c:309
#5  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 6 (Thread 0x7fa9522f9700 (LWP 2914)):
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x0000003575809f97 in _L_lock_863 () from /lib64/libpthread.so.0
#2  0x0000003575809deb in __pthread_mutex_lock (mutex=0x27636c0) at pthread_mutex_lock.c:65
#3  0x000000357bc16c25 in ?? () from /usr/lib64/libxine.so.1
#4  0x000000357bc20769 in ?? () from /usr/lib64/libxine.so.1
#5  0x0000003575807d90 in start_thread (arg=0x7fa9522f9700) at pthread_create.c:309
#6  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 5 (Thread 0x7fa95170f700 (LWP 2915)):
[KCrash Handler]
#6  0x00007fa95294d13d in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_vo_out_xv.so
#7  0x000000357bc1f292 in ?? () from /usr/lib64/libxine.so.1
#8  0x00007fa958768cff in ?? () from /usr/lib64/xine/plugins/1.30/post/xineplug_post_tvtime.so
#9  0x00007fa9481e6164 in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_decode_mpeg2.so
#10 0x00007fa9481e6bd2 in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_decode_mpeg2.so
#11 0x000000357bc1d319 in ?? () from /usr/lib64/libxine.so.1
#12 0x0000003575807d90 in start_thread (arg=0x7fa95170f700) at pthread_create.c:309
#13 0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 4 (Thread 0x7fa950d41700 (LWP 2916)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
#1  0x000000357bc22878 in ?? () from /usr/lib64/libxine.so.1
#2  0x00007fa933dfe089 in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_decode_mad.so
#3  0x000000357bc1e78f in ?? () from /usr/lib64/libxine.so.1
#4  0x0000003575807d90 in start_thread (arg=0x7fa950d41700) at pthread_create.c:309
#5  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 3 (Thread 0x7fa94bfff700 (LWP 2917)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
#1  0x000000357bc26bdb in ?? () from /usr/lib64/libxine.so.1
#2  0x0000003575807d90 in start_thread (arg=0x7fa94bfff700) at pthread_create.c:309
#3  0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 2 (Thread 0x7fa948e06700 (LWP 2926)):
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x0000003575809fb2 in _L_lock_910 () from /lib64/libpthread.so.0
#2  0x0000003575809e4b in __pthread_mutex_lock (mutex=0x21d9c10) at pthread_mutex_lock.c:86
#3  0x000000357bc22d36 in ?? () from /usr/lib64/libxine.so.1
#4  0x000000357bc250b5 in ?? () from /usr/lib64/libxine.so.1
#5  0x000000357bc0e23f in ?? () from /usr/lib64/libxine.so.1
#6  0x000000357bc102c2 in _x_set_fine_speed () from /usr/lib64/libxine.so.1
#7  0x00007fa94af75ea5 in ?? () from /usr/lib64/xine/plugins/1.30/xineplug_inp_stdin_fifo.so
#8  0x000000357bc16cbc in ?? () from /usr/lib64/libxine.so.1
#9  0x000000357bc2aef0 in ?? () from /usr/lib64/libxine.so.1
#10 0x0000003575807d90 in start_thread (arg=0x7fa948e06700) at pthread_create.c:309
#11 0x00000035750f0f5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 1 (Thread 0x7fa969e10840 (LWP 2909)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
#1  0x0000003578032520 in _XDisplayLockWait (dpy=0x2067fe0) at locking.c:447
#2  0x0000003578032b29 in _XLockDisplay (dpy=0x2067fe0) at locking.c:462
#3  0x00000035780364b7 in XEventsQueued (dpy=0x2067fe0, mode=2) at Pending.c:39
#4  0x0000003585a6c50c in ?? () from /usr/lib64/libQtGui.so.4
#5  0x00000035774447a4 in g_main_context_check () from /lib64/libglib-2.0.so.0
#6  0x0000003577444ff2 in ?? () from /lib64/libglib-2.0.so.0
#7  0x000000357744549c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#8  0x00000035809a7dc6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#9  0x0000003585a6c66e in ?? () from /usr/lib64/libQtGui.so.4
#10 0x0000003580978182 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#11 0x00000035809783d7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#12 0x000000358097cdd5 in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
#13 0x0000000000403d48 in ?? ()
#14 0x000000357502169d in __libc_start_main (main=0x403aa0, argc=2, ubp_av=0x7fffa69867f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optim
ized out>, stack_end=0x7fffa69867e8) at libc-start.c:226
#15 0x0000000000403dd9 in _start ()

*** Bug 806971 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.