[linux-dvb] Re: Problems with TechnoTrend dec2000-t USB

[Holger Waechtler <holger@convergence.de>]

Ralph Metzler wrote:
> Johannes Stezenbach writes:
>  > Holger Waechtler wrote:
>  > > >If you get a kernel panic, then it's not your fault, but a bug in the 
>  > > >code.  If you don't require a dvb net interface, try playing with tzap 
>  > > >from the linux-dvb pre-release tarball.  Hopefully I'll get a chance to 
>  > > >look at fixing the problem soon.
>  > > 
>  > > The problem is that the software demux feeds the network interface in 
>  > > interrupt context, the network code is then trying to sleep and that's 
>  > > not allowed. Thus the BUG() call.
>  > > 
>  > > The USB DVB drivers need to use tasklets like the PCI DVB drivers too, 
>  > > thenafter you can use the DVB network interface, too.
>  > 
>  > I don't think so. For one, tasklets can't sleep either. And the network
>  > code is explicitely written to pass network packets from interrupt
>  > context to the network layer (because that's how network interface
>  > hardware usually works).
>
> Correct.
nope, it's not. take a look in the network driver code. Usually SKBs are 
queued and then a softirq is raised in order to force highlevel protocol 
processing of network packets. Basically this mechanism works similiar 
like tasklets do.

The approach of processing all data in the interrupt handlers caused 
Linux' high interrupt latency and bad reputation in Realtime and 
Multimedia applications.

Recent 2.5 kernels and the lowlatency patchsets try to improve this 
situation so we should just follow the more modern approach of doing not 
more in the irq handler than scheduling the tasklet and then let it 
perform all the hard work when interrupts are enabled again.

>  > IIRC there is a race condition at ifconfig time, and a solution was described
>
>
> The main problem is that almost all network control calls of a network
> driver (here dvb_net) for setting MAC, multicast filters, etc., are 
> called from the network layer in interrupt context. Any drivers 
> which might sleep when setting filters (av7110, USB) can thus cause
> a schedule to be called during interrupt which will cause BUG() 
> to be called (see schedule() in linux/kernel/sched.c).
>
> This problem can even occur with all drivers because the filter
> handling functions in the software demux layer use semaphores and a
> down()/down_interruptible() can go to sleep. But this does not happen
> often because usually nobody uses other filters when using networking.
> Even if you do the setting or releasing of the filter would have to occur
> at the same time (network layer calls dvb_net while other filter call
> is just "inside semaphore") to trigger the bug.
>
> Also see my posts regarding this last February.
>
>  > by on of the Metzlers here on this list some months ago. Maybe it's even
>  > fixed in their driver.
>
> It is fixed in our CVS but not released yet.
(thanks for your cooperation, this statement helps everybody on this list;)

Basically I see two approaches to solve the problem: we could either 
delay actual DVB filter configuration by running a config thread which 
gets triggered from the network interface handlers (evil, we would again 
have one more housekeeping thread - )

or we could try to make the demux start/stop-feed and filter allocation 
code interrupt-context safe (pretty hard, maybe even not possible).

At the end someone who actually uses the DVB network interface has to do 
this, right?
:)

> We'll have to carefully check first what we can include before 
> making a new release. Some driver parts like e.g. for TDA10021/10046 
> or for KNC CI cannot yet be released by us and we will have to make
> proper adjustments.
one more good point how diverging closed source projects cause doubled 
efforts, here at convergence we did so as well some months ago but can't 
release the drivers due to NDAs with Philips...

Holger



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.