[linux-dvb] Nova-T 500 Channel scanning + EIT + Kernel oops...

Henrik Beckman henrik.list at gmail.com
Sun Mar 11 17:00:01 CET 2007


EIT seems to "trigger" the event, but it will happen even with EIT disabled,
but much less frequent.
EIT forces the adapter to be constantly active.

/Henrik



On 3/11/07, Juha Ruotsalainen <kontza at gmail.com> wrote:
>
> I'm using VDR. Could someone with more understanding tell me, can EIT
> be disabled in VDR? Or, alternatively, give an educated guess why
> enabling EIT causes USB disconnects?
>
> On 3/11/07, Eduard Huguet <eduardhc at gmail.com> wrote:
> > >
> > > From: Antti P Miettinen <ananaza at iki.fi>
> > > To: linux-dvb at linuxtv.org
> > > Date: Sat, 10 Mar 2007 21:44:37 +0200
> > > Subject: [linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel
> > > oops...
> > > "Henrik Beckman" <henrik.list at gmail.com> writes:
> > > > Are there any differences in the windows stream ?
> > >
> > > Well, I've only managed to look at the beginning so far, but there
> > > seem to be at least some minor differences.
> > >
> > > The trace starts (after some descriptor reads) with firmware
> > > loading. The firmware seems to be in more or less Intel hex record [1]
> > > format and checked against that assumption I think what I extracted
> > > from the trace should be more or less OK. At least the record wise
> > > checksums match.
> > >
> > > There are some messages for which I cannot find any counterparts in
> > > the linux driver code. Before the firmware download starts the windows
> > > driver sends a five byte bulk packet to EP1:
> > >
> > >  02 a1 00 00 08
> > >
> > > and receives eight byte bulk packet:
> > >
> > >  d0 40 20 50 99 00 01 05
> > >
> > > Then the firmware is sent just like in linux. Before the jumpram
> > > message, there is one 12 byte read:
> > >
> > >  00 00 00 00 70 00 00 00 06 11 60 d4
> > >
> > > Looks like this contains the start address, maybe some kind of
> > > checksum.
> > >
> > > Then some decsriptor reading, setting configs, and then something that
> > > looks like the GPIO setting in the linux driver, but there's a small
> > > difference from what is done in bristol_frontend_attach(). If I'm
> > > interpreting the log correctly the windows driver is doing the
> > > equivalent of:
> > >
> > >  dib0700_set_gpio(adap->dev, GPIO6,  GPIO_OUT, 1);
> > >  dib0700_set_gpio(adap->dev, GPIO9,  GPIO_OUT, 0);
> > >  dib0700_set_gpio(adap->dev, GPIO10,  GPIO_OUT, 0);
> > >  msleep(10);
> > >  dib0700_set_gpio(adap->dev, GPIO10,  GPIO_OUT, 1);
> > >
> > > And then I got tired :-)
> > >
> > > I'll try deciphering the log more later.
> > >
> > > [1] http://en.wikipedia.org/wiki/Intel_HEX
> > >
> > > --
> > > http://www.iki.fi/~ananaza/ <http://www.iki.fi/%7Eananaza/>
> > >
> >
> >
> >
> > Just as a matter of update, I've reenabled EIT scanning in MythTV just
> for
> > testing. It took less than 5 min to get a kernel oops due to the USB
> > disconnect ("dmesg | grep disconn" was explicit enough...).
> >
> > I don't know if this can help you in any way, but in my case the
> equation is
> > pretty clear:
> >
> >    - EIT = USB disconnect
> >    - No EIT = No USB disconnect
> >
> > :D
> >
> > Cheers, and thank you again for your hard work.
> >   Eduard
> >
>
>
> --
> jussi
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20070311/dd39bfb5/attachment.htm


More information about the linux-dvb mailing list