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

[Ralph Metzler <rjkm@metzlerbros.de>]

Holger Waechtler writes:
 > 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.

I don't know what you are answering to. The question was what causes 
this crash and using tasklets would not fix this (even it it were the
real cause) because they are also running in interrupt context as 
Johannes correctly stated.
schedule() calls will crash regardless of from where they were called
(tasklet or hard interrupt). The network layer does not sleep and 
can handle to be called from both. So, it is correct that using
tasklets or not has nothing to do with the problem. 

That's also independent of any discussion about what should be in hard
interrupts and what in tasklets.
E.g. handling of interrupt hardware registers also should be done 
in the hard interrupts and not in tasklets.


 > >  > 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;)

Well, I did explain how to do it last February and that's how we did it. 

 
 > 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 - )

You do not need a completely new thread. Just use existing task queues/work queues.
 
 > or we could try to make the demux start/stop-feed and filter allocation 
 > code interrupt-context safe (pretty hard, maybe even not possible).

Then you would have to do the same as in the network driver but much 
more general.

 
Ralph


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