Messages in this thread |  | | | Date | Sun, 25 Sep 2005 22:38:24 -0700 | | From | Andrew Morton <> | | Subject | Re: schedule_work returns FAILURE (0) |
"Ravi Dubey" <ravi.dubey@conexant.com> wrote: > > Hi, > > I have ported my USB driver on from Linux Kernel 2.4.20-8 to 2.6.11.12. > As a part of this porting process, I have replaced the bottom halves > with work_queues. Now, I am facing problems in the driver execution. > :-(. > > The schedule_work() function which schedules the work is returning > FAILURE (0) many times (at least 1 out of 4 times it is called). > > My queries: > > 1. When a work is queued using schedule_work (), does the function (that > is to be called as bottom half) run at process context OR Interrupt > context
Process context.
> - The reason why I am getting confused is that in this called > function, if I print the return value of in_interrupt (), I get 0 (which > means that is running at process context),
Yup.
> However, if I print the value > of in_interrupt after I have acquired a spin lock in this function, I > get the value 256 (which means I am running in interrupt context) ?
Not really. Bits 8-19 of preempt_count() count the IRQ depth and bits 0..7 count the inc_preempt_count() depth. If CONFIG_PREEMPT is enabled, spin_lock() does inc_preempt_count(). See the definitions of hardirq_count(), softirq_count() and irq_count().
> 2. Why is the schedule_work () function failing.
umm, look at the implementation of schedule_work()?
if (!test_and_set_bit(0, &work->pending)) { it's already pending (the scheduled work has not run yet). You need to design you schedule_work() caller to queue things up and you need to design your schedule_work() handler to consume all the thus-far-queued work items.
Just ignore the return value of schedule_work(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |