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

[Holger Waechtler <holger@convergence.de>]

Ralph Metzler wrote:
>  
>  > >  > 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.
to the question that network code is written and designed to run in 
interrupt handlers. That's simply not true, the code is only BH-safe.

> 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.
not in hard irq context. It's not allowed to sleep there, but when we 
enter a tasklet all main irq handlers are left and interrupts are 
enabled again.

> 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. 
yep. some ideas for a solution were outlined some lines below, since you 
didn't wanted to tell yours we'll have to think about our own, one, right?

> 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.
that heavily depends on the hardware, when we have to insert significand 
delays between register writes and when we can be sure that a response 
to the hardware is not too time-critical (so that we can wait until the 
tasklets or BH gets processed) then the tasklet/BH approach is better.


>  > >  > 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. 
please reference the mail, I've never seen an outline for the solution. 
I must be blind...

let's stop the flame, ranting helps nobody.

Holger



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