[linux-dvb] Re: budget hang after EPG scan (Was: Re: cinergyT2:which kernel/usb module to use?)

[Simon <ml_vdr_simon@bigblue.demon.co.uk>]

Andrew de Quincey wrote:

> On Friday 03 Dec 2004 18:22, Jouni Karvo wrote:
>
> > Andrew de Quincey writes:
> > > > kernel: DVB: registering frontend 1 (ST STV0299 DVB-S)... Dec  2
> > > > 20:47:28 x
> > >
> > > Ta.
> > >
> > > OK, does anyone get this problem who is not using an stv0299 in the
> > > *budget* cards?
> >
> > I do.  ves1820 ttpci.
> >
> > The problem has been there for the whole year (2004), but before (I
> > think about sep) it happened less frequently (or was due to some other
> > bug), about every 3-4 days (i.e. several epg scans went on without
> > problems).  I think the situation changed somewhere between sep 6th
> > and oct 24th so that the card just stops working in (probably) the
> > first epg scan.  I do not know whether this was just an old bug and
> > some race conditions trigger it now more often due to other changes
> > (like updating vdr) or is it a new bug.
> >
> > I also have a cvs snapshot from sep 6th and apr 24th on my disk, so I
> > can check during this weekend whether the problem occurs with that,
> > too.
>
> That would be good to know. If you find an old snapshot without the problem, I 
> would be really pleased to know!
>
> Next time it happens, could you try unloading _all_ the drivers and reloading 
> them... I mean including things like dvb-core. I know that reloading the 
> frontend/card driver doesn't help, but I'd like to know for sure that 
> reloading all DVB related stuff doesn't as well.
>
>
> > And, this problem occurs with two budget cards.  I do not think that
> > FF/budget makes any difference for the primary card as long as the epg
> > scan is done on budget ttpci.
>
> Yup, that seems to be what everyone else sees. Only the budget cards break. 
> OK: so its definitely not a frontend bug.
>
> As for updating VDR causing it - it may indeed be something VDR now does a bit 
> differently which makes it happen more often... but VDR isn't at fault here 
> IMO.
>
> Could something in the saa7146 be being tripped up somehow so that a poweron 
> reset is needed to fix it?
>
> Does anyone use VDR with a twinhan or other non-saa7146-based budget card for 
> EPG? And does it have this problem?

My system has been stable since mid/end september. The coincidence of
date is interesting. Anyway, I've not had a driver lockup that required
a reboot since then. More importantly, no problems that I could trace
to a driver issue.

I note that at about this time the UK got 1 week EPGs moving from
now/next only. When the EPG changed to 1 week I reduced the update
interval for vdradmin's auto timers. Prior to this I would get lockups
within 2-3 days of a reboot, most often coincident with vdradmin
initiating a timer check.

Im using vanilla 2.6.8.1 kernel + patch listed at the end.
2xTwinhan DVB-T cards.
Slackware 10, VDR-1.3.12+patches and vdradmin-0.96.

btw Is there a script or something that can list hardware/software
details to help consistent reporting? A script that does it all,
not the individual commands.

Simon

--- dvb_frontend.c.orig 2004-09-08 09:48:37.000000000 +0100
+++ dvb_frontend.c      2004-09-08 09:49:02.000000000 +0100
@@ -519,10 +519,14 @@
                }

                // get the frontend status
-               dvb_frontend_internal_ioctl (&fe->frontend, 
FE_READ_STATUS, &s);
-               if (s != fe->status)
-                       dvb_frontend_add_event (fe, s);
-
+               if (fe->state & FESTATE_RETUNE) {
+                       s = 0;
+               } else {
+                       dvb_frontend_internal_ioctl (&fe->frontend, 
FE_READ_STATUS, &s);
+                       if (s != fe->status) {
+                               dvb_frontend_add_event (fe, s);
+                       }
+               }
                // if we're not tuned, and we have a lock, move to the 
TUNED state
                if ((fe->state & FESTATE_WAITFORLOCK) && (s & 
FE_HAS_LOCK)) {
                        update_delay(&quality, &delay, fe->min_delay, s 
& FE_HAS_LOCK);