2.4.6 possible problem
Guys,
does anybody use interruptible_sleep_on_timeout(&wqhead, jiffies); under 2.4.6 ? It seems that after this call sleeping process is never rescheduled again. Am I doing something wrong in my driver?
<10716>
Knowing that wait queue was reorganized in 2.4 I declared queue head as:
static DECLARE_WAIT_QUEUE_HEAD(wqhead);
and then in ioctl routine
Quoted 8 lines · Alex Ivchenko
Guys,
does anybody use
interruptible_sleep_on_timeout(&wqhead, jiffies); under 2.4.6 ?
It seems that after this call sleeping process is never rescheduled again. Am I doing something wrong in my driver?
Quoted 6 lines
<10716>
Knowing that wait queue was reorganized in 2.4 I declared queue head as:static
DECLARE_WAIT_QUEUE_HEAD(wqhead);and then in ioctl routine
^^^^^^^^^^^^^^^^^^^^^^^^^ Hmm. Don't decare it again.
funct()
{
size_t ticks;
wait_queue_head_t wqhead;
init_waitqueue_head(&wqhead);
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
;
}That'd oughtta do it. You can skip the loop if you can stand a short timeout.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.
Well,
Quoted 10 lines
funct(){ size_t ticks; wait_queue_head_t wqhead; init_waitqueue_head(&wqhead); ticks = 1 * HZ; /* For 1 second */ while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0) ; }
Well, this works.
The question is: should I call init_waitqueue_head() every time I call interruptible_sleep_on_timeout() or is it enough to call it once in init_module() ?
Another one: should I call wake_up_interruptible() to release pending request?
Signature · 12 lines
Regards, Alex -- Alex Ivchenko, Ph.D. United Electronic Industries, Inc. "The High-Performance Alternative (tm)" -- 10 Dexter Avenue Watertown, Massachusetts 02472 Tel: (617) 924-1155 x 222 Fax: (617) 924-1441 http://www.ueidaq.com
Quoted 8 lines · Alex Ivchenko
Well,
Quoted 6 lines
funct(){ size_t ticks; wait_queue_head_t wqhead; init_waitqueue_head(&wqhead);
Quoted 5 lines
Quoted 4 lines
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0)
;
}Well, this works.
Good.
Quoted 4 lines
The question is: should I call
init_waitqueue_head()every time I callinterruptible_sleep_on_timeout()or is it enough to call it once ininit_module()?
Just once is fine.
Quoted 3 lines
Another one: should I call
wake_up_interruptible()to release pending request?
Nope. If you got control back due to the timeout, it's done. You have been awakened. If somebody else wants to wake up your sleeping giant (like an interrupt), it calls wake_up_interruptible() with the pointer to the wait-queue it wants to affect.
Quoted 10 lines
--
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
"The High-Performance Alternative (tm)"
--
10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.
In article <[email protected]>,
Quoted 4 lines · Richard B. Johnson
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0);
Don't do this.
Imagine what happens if a signal comes in and wakes you up? The signal will continue to be pending, which will make your "sleep loop" be a busy loop as you can never go to sleep interruptibly with a pending signal.
In short: if you have to wait for a certain time or for a certain event, you MUST NOT USE a interruptible sleep.
If it is ok to return early due to signals or similar (which is nice - you can allow people to kill the process), then you use an interruptible sleep, but then you mustn't have the above kind of loop.
Linus
Quoted 13 lines · Linus Torvalds
In article <[email protected]>,
Quoted 4 lines · Richard B. Johnson
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0);Don't do this.
Imagine what happens if a signal comes in and wakes you up? The signal will continue to be pending, which will make your "sleep loop" be a busy loop as you can never go to sleep interruptibly with a pending signal.
Quoted 8 lines
In short: if you have to wait for a certain time or for a certain event, you MUST NOT USE a interruptible sleep.
If it is ok to return early due to signals or similar (which is nice - you can allow people to kill the process), then you use an interruptible sleep, but then you mustn't have the above kind of loop.
Linus
Okay, then ../linux/drivers/net/8139too.c (line 2239) should be fixed because that's where it came from.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.
Quoted 18 lines · Richard B. Johnson
Quoted 16 lines · Linus Torvalds
In article <[email protected]>,
Quoted 4 lines · Richard B. Johnson
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0);Don't do this.
Imagine what happens if a signal comes in and wakes you up? The signal will continue to be pending, which will make your "sleep loop" be a busy loop as you can never go to sleep interruptibly with a pending signal.
In short: if you have to wait for a certain time or for a certain event, you MUST NOT USE a interruptible sleep.
Quoted 9 lines
Quoted 5 lines
If it is ok to return early due to signals or similar (which is nice - you can allow people to kill the process), then you use an interruptible sleep, but then you mustn't have the above kind of loop.
Linus
Okay, then
../linux/drivers/net/8139too.c(line 2239) should be fixed because that's where it came from.
I hate to answer my own questions, but the above may be correct if the task doesn't stay in interruptible_sleep_on_timeout() if there is a signal pending. If true, it will not loop forever because of the test for signal_pending(current).
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.
Dick,
Quoted 10 lines · Richard B. Johnson
Quoted 7 lines · Linus Torvalds
In article <[email protected]>,
Quoted 4 lines · Richard B. Johnson
ticks = 1 * HZ; /* For 1 second */
while((ticks = interruptible_sleep_on_timeout(&wqhead, ticks)) > 0);
Quoted 5 lines
Quoted 5 lines
Don't do this.
Imagine what happens if a signal comes in and wakes you up? The signal will continue to be pending, which will make your "sleep loop" be a busy loop as you can never go to sleep interruptibly with a pending signal.
Sleep like this is useless in real code. You either want your ioctl to unblock when event (or time-out) happens or use sleep function to make driver wait certain amount of time (if you need to access poorly-designed hardware).
Off-topic:
Quoted 3 lines
I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any.
Well, give 'em at least some credit for copycating :-) As a system architect I would say a *good* copycating.
For example:
Win32 events (CreateEvent(), WaitForxxxObject()) are very useful things. The whole reason I was asking my questions is because I want to emulate Win32-like event mechanism it Linux driver. I wouldn't mind to have this mechanism built into Linux kernel.
Say, one of the user process threads calls:
ret = WaitForSingleObject(hObject, dwTimeoutms);
or
ret = WaitForMultipleObjects(nNumber, hObjects[], FALSE, dwTimeoutms);
and waits until time-out or one (or more) objects are set.
Quoted 1 line
From the driver side you call:
KeSetEvent(hNotifyEvent, (KPRIORITY)1, FALSE);
when you want to release object.
It's very useful.
For example, with our hardware I can have up to 16*4 = 64 totally separated subsystems. Each subsystem can fire event asynchronously. It's much easier to control each subsystem in separate thread and Win32 events are very handy.
Signature · 12 lines
Regards, Alex -- Alex Ivchenko, Ph.D. United Electronic Industries, Inc. "The High-Performance Alternative (tm)" -- 10 Dexter Avenue Watertown, Massachusetts 02472 Tel: (617) 924-1155 x 222 Fax: (617) 924-1441 http://www.ueidaq.com