Messages in this thread | | | Date | Thu, 21 Oct 1999 09:54:31 +0200 | From | Karsten Keil <> | Subject | Re: schedule_timeout() semantics/usage? |
| |
On Thu, Oct 21, 1999 at 02:34:30AM +0200, Andrea Arcangeli wrote: > On Wed, 20 Oct 1999, David Hinds wrote: > > >Look at net/irda/*.c [..] > > /* Make sure nobody tries to transmit during the speed change */ > while (irda_lock((void *) &self->netdev.tbusy) == FALSE) { > WARNING(__FUNCTION__ "(), device locked!\n"); > current->state = TASK_INTERRUPTIBLE; > schedule_timeout(MSECS_TO_JIFFIES(10)); > > if (n++ > 10) { > WARNING(__FUNCTION__ "(), breaking loop!\n"); > break; > } > } > > The above looks a bug. It should be using > __set_current_state(TASK_UNINTERRUPTIBLE). > > > [..] or isdn/hisax/*.c, for example. > > Yes, it should be using UNINTERRUPTIBLE as well. > > This is a case where most people say "Oh well..." ;).
For hisax not true, or I missunderstand it. In HiSax, the schedule_timeout are use allways on init stage (during insmod) for 3 purposes:
1.) To do delay (value is not important) for asserting reset on isdn chips.
2.) To wait for an IRQ to test the IRQ path (I send a command to the isdn chip which 'll cause an IRQ, then I wait with schedule_timeout().
3.) Timer test, some cards have a onboard timer which e.g 8ms, so I enable this timer IRQ and wait with schedule_timeout(), after that I test how many time the interrupt function was called.
Is this a right use of current->state = TASK_INTERRUPTIBLE; schedule_timeout(delay);
, what is a better way to do point 2 or 3, 1. can be also a simple delay loop.
Karsten
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |