[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-atm
Subject:    Re: schedule_timeout in xmit path dangerous???
From:       Chas Williams <chas () cmf ! nrl ! navy ! mil>
Date:       2000-10-24 22:42:18
[Download RAW message or body]

In message <39F6043C.68444F20@cs.clemson.edu>,Mike Westall writes:
>fact that in the IP over ATM environment, the transmit path
>is typically invoked within the context of an interrupt (or
>at least in_interrupt() is typically TRUE.), and that calling
>schedule_timeout from within an interrupt is a no-no (like 
>sleeping.)   

that seems to make sense.  forgot that _send() can be called
from interrupts (but it should be obvious to me -- kmalloc()
complained enough times when i forgot GFP_KERNEL

>So... Chas you may want to try this out and see if it happens
>to you too, and if it does go back and adopt either the queueing
>or dropping strategy. (The previous version of the 

i really dont see this problem -- i suppose my processor isnt fast
enough to push the card that hard.  i dont want to queue the 
data since the he already has a queue really.  possibly the
transmit queue should be tuned to a larger value.  i guess
just dropping is the only answer.  perhaps a very short udelay(),
retry, and drop the packet if that doesnt work.

>HE driver just had a  printk(..."FIX ME") where the schedule_timeout()
>now occurs.  

thanks for the report -- i did mean to get back to you i have just been
busy elsewhere

[prev in list] [next in list] [prev in thread] [next in thread]