Re: fbtv 3.95 & vdr 1.4.5: closing fbtv causes vdr freeze

On Tue, Aug 18, 2009 at 7:19 PM, Christian Neumair<[email protected]> wrote:
> Am Dienstag, den 18.08.2009, 15:04 -0400 schrieb Devin Heitmueller:
>> On Tue, Aug 18, 2009 at 2:55 PM, Christian Neumair<[email protected]> wrote:
>> > Dear video4linux-list,
>> >
>> > I observed a problem with an ancient easyVDR distribution from 2007 which
>> > uses vdr 1.4.5 (c't vdr), fbtv 3.95, and kernel 2.6.22.5: As soon as I quit
>> > fbtv with ctrl-c, vdr turns into a CPU hog and has to be killed. This is
>> > unfortunate, because in my setup I only want to use the local fbtv frontend
>> > occassionally, while permanently using the remote VOMP plugin. Is this a
>> > known issue? Can you reproduce it with recent vdr and fbtv versions? Can I
>> > do anything to debug the issue?
>> >
>> > Thanks in advance!
>> >
>> > best regards,
>> >  Christian Neumair
>>
>> You're probably not going to find a developer willing to spend the
>> cycles to debug an ancient version of VDR on an ancient kernel.  Your
>> best bet is to update to the latest version and see if the problem
>> still occurs.  Fortunately it seems like the issue is highly
>> reproducible for you, so seeing if it occurs in the latest version
>> should be pretty straightforward.
>>
>> So if you are looking to help debug the issue, answer your own
>> question: "Can you reproduce it with recent vdr and fbtv versions?"
>
> Come on, we are all developers.
>
> In an attempt to keep my running and carefully configured system intact,
> I can not blindly upgrade anything. I prefer to apply a patch for this
> very specific issue. Upgrading the entire system wouldn't help either
> because it does not help me to isolate the cause of the bug.
>
> Unfortunately, I don't have a clue about the precise vdr/fbtv/v4l IPC.
> If anybody could give me an overview over the mechanisms or code paths,
> I could try to grep in the sources myself.
>
> Thanks in advance!
>
> best regards,
>  Christian Neumair
>
> PS: As a Nautilus maintainer, the "please upgrade to the latest
> version(s)" hint is well-known from GNOME bugzilla, and I don't like it
> at all, to say the least. From a developer perspective, it is always
> desirable to find out why and how an issue was fixed because otherwise
> you can't guarantee that it was really fixed, but instead it may have
> been obfuscated by another issue.

You shouldn't interpret the above as some sort of insult.  As a open
source maintainer, I'm sure you are familiar with the notion of being
understaffed and unable to support every version ever released.  If I
opened a bug tomorrow saying that I'm running Fedora 7 on PPC and when
I open Nautilus I get kicked back to the Gnome login prompt, how much
attention do you think it would get from the Gnome dev team?  We all
have to live in the real world and make compromises, which in this
case means we can't burn the cycles to support two year old releases.

People who need *that* level of support usually have commercial
support contracts.

That said, if you really want to debug the issue, the place to start
is probably to get a serial console hooked up, setup the sysrq key and
get a stack dump when the thing hangs.  Then at least we might have
*some* idea where the driver is locking up the system.  You should
probably also figure out what type of card you have, what driver it
uses, and what kernel you are running, so there is some context to how
many thousands of revisions old the v4l-dvb tree you are running is.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list