Hi!
Is it safe to sleep in tx_timeout (in the networking code), i.e. to call
schedule_timeout and friends from that routine?
--
Regards
Abraham
: How would you disambiguate these situations?
By shooting the person who did the latter.
-- Larry Wall in <[email protected]>
___________________________________________________
Abraham vd Merwe - Frogfoot Networks CC
9 Kinnaird Court, 33 Main Street, Newlands, 7700
Phone: +27 21 686 1665 Cell: +27 82 565 4451
Http: http://www.frogfoot.net/ Email: [email protected]
On Sun, 3 Aug 2003, Abraham van der Merwe wrote:
> Hi!
>
> Is it safe to sleep in tx_timeout (in the networking code), i.e. to call
> schedule_timeout and friends from that routine?
No it's called from softirq context and with the dev->xmit_lock held in
places.
--
function.linuxpower.ca
Hi Zwane >@2003.08.03_21:10:56_+0200
> > Is it safe to sleep in tx_timeout (in the networking code), i.e. to call
> > schedule_timeout and friends from that routine?
>
> No it's called from softirq context and with the dev->xmit_lock held in
> places.
That's what I thought. How are you supposed to wait for long periods from
tx_timeout? My problem is that I have a chip reset which takes around 10ms
(i.e. too long to use mdelay())
--
Regards
Abraham
No problem is insoluble in all conceivable circumstances.
___________________________________________________
Abraham vd Merwe - Frogfoot Networks CC
9 Kinnaird Court, 33 Main Street, Newlands, 7700
Phone: +27 21 686 1665 Cell: +27 82 565 4451
Http: http://www.frogfoot.net/ Email: [email protected]
Abraham van der Merwe wrote:
> Hi Zwane >@2003.08.03_21:10:56_+0200
>
>
>>>Is it safe to sleep in tx_timeout (in the networking code), i.e. to call
>>>schedule_timeout and friends from that routine?
>>
>>No it's called from softirq context and with the dev->xmit_lock held in
>>places.
>
>
> That's what I thought. How are you supposed to wait for long periods from
> tx_timeout? My problem is that I have a chip reset which takes around 10ms
> (i.e. too long to use mdelay())
Simple answer, don't wait in tx_timeout :)
These days drivers often need quite a while for hardware reset. I am
pushing to move this code, long term, into process context. So, in
tx_timeout:
* disable NIC and interrupts as best you can, quickly
* schedule_task/schedule_work to schedule the full hardware reset
Jeff
On Sul, 2003-08-03 at 20:48, Jeff Garzik wrote:
> These days drivers often need quite a while for hardware reset. I am
> pushing to move this code, long term, into process context. So, in
> tx_timeout:
> * disable NIC and interrupts as best you can, quickly
> * schedule_task/schedule_work to schedule the full hardware reset
And if the hardware is hard to recover or needs messy recovery code take
a look at the PCI layer tricks in -ac