Re: "However, if you don't want to lose your freedom, you had better not follow him." (Re: Videotext application crashes the kernel due to DVB-demux patch)

[Chicken Shack <chicken.shack@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

Am Sonntag, den 07.02.2010, 09:43 -0500 schrieb Andy Walls:
> On Sun, 2010-02-07 at 04:58 +0100, hermann pitton wrote:
> > Am Samstag, den 06.02.2010, 09:55 +0100 schrieb Chicken Shack:
> > > Am Samstag, den 06.02.2010, 01:25 +0100 schrieb hermann pitton:
> 
> > 3.
> > Also confirmed, your 1.7.0 version did work on a latest unpatched F11
> > 2.6.30 without setting the teletext pid explicitly, providing the
> > information what else is around there, and next should allow switching
> > through all teletext stuff with the UI I guess.
> > 
> > Taking the oopses now, you are likely right, that we have a backward
> > compat regression here and should try to fix it.
> 
> 
> I'm looking at this still, just not quickly.
> 
> The over-abundance of the use of the words "demux", "dmx", "dvb",
> "feed", "ts", and "sec" in the dvb-core make code analysis difficult.
> I'm putting the dvb-core data structures into a UML tool, so I can get
> some decent class and collaboration diagrams to have a good picture of
> the relationships.
> 
> I can say that the easiest fix will most likely be that in dmxdev.h:
> 
> struct dmxdev_filter {
> 	...
>         union {
>                 /* list of TS and PES feeds (struct dmxdev_feed) */
>                 struct list_head ts;
>                 struct dmx_section_feed *sec;
>         } feed;
> 	....
> 
> "feed" should no longer be a union, or that "feed.sec" should be
> converted to a list as well.
> 
> It appears under certain circumstances "feed.sec" is being set to NULL,
> which corrupts the "feed.ts" list head.   The "feed.ts" list head is
> being properly intiialized in dvb_demux_open(), so that's not the
> problem.
> 
> 
> Regards,
> Andy
> 
> 
> 
> > I'm at least still available for reproducing oopses ;)
> > 
> > And, an app, which ever, should not to be able to get all down.
> > 
> > Cheers,
> > Hermann

Hi everybody,

Although quite effectless in the end I do not want to forget about
politeness and thank you for your investigation - especially Andy for
sure.

An outsider that I found by a google research, an Italian called
Francesco Lavra already resolved the kernel crash issue by a simple
one-liner that you can find easily on this today's list.

So please stop your investigation as the problem is solved already.
Alevt works without kernel crash - fantastic!
So do everything please to make this one-liner part of 2.6.33 main line
final.


However I am still alone with the other problem I always stressed:

When using alevt-dvb (I attached my overworked version 1.7.0 in earlier
mails - please do have a look at it!) the application hangs when you
decide to switch to a channel that is part of a new transponder.
The program hangs then. That means the way alevt-dvb is dealing with the
PMT (program map table) is highly incomplete.
It needs a reset function to read the new PMT when the transponder is
being changed...

I do not know how to program that simple reset function. But I know that
thsi is the definite key to resolve the issue.
PMT reading, PMT opening, PMT parsing.......
Everything is already inside of the source code of alevt-dvb.

But as soon as the transponder is being changed the program is quite
helpless - it simply does not know what to do and hangs......

This behaviour is not being shown when alevt-dvb shows teletext
addressing analogue cards (which seems to be technically something
completely different). Only the DVB part of the program behaves buggy in
that context.


And this goes to Francesco Lavra:

God bless you, Francesco!
You got it!
With a simple one-liner!
I'm breathless!

Mille grazie per questa contribuzione, Francesco! :) :) :)


[-- Attachment #2: alevt-1.7.0.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 85333 bytes --]