RE: schedule_work returns FAILURE (0)

["Ravi Dubey" <ravi.dubey@conexant.com>]

Hi Andrew,

Thanks for your response.

In 2.4 series there were three different kind of task queues: Timer,
Scheduler and Immediate. It is said that "work queue" is basically the
old Scheduler type. Is there any way I can make it work the "Immediate"
way.

I have gone through many of the LINUX sample 2.6 drivers, but all these
have just replaced tqueue by work_queue and mark_bh(IMMEDIATE_BH) by
schedule_work, but they are not using their own queues. Is it because my
driver has a very heavy / time intensive bottom half function?

Ravi

-----Original Message-----




********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************

From: Andrew Morton [mailto:akpm@osdl.org] 
Sent: Monday, September 26, 2005 11:08 AM
To: Ravi Dubey
Cc: linux-kernel@vger.kernel.org
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/