In our lower tty driver we have some data (queues) which can be accessed by
both outgoing and incoming 'events' i.e. requests from the upper tty and
interrupts from the lower hardware driver can both access these queues. We
need critical sections to manage the accessing of these queues. We are
porting the driver from NT (which used spinlocks). We need to implement
initialise lock, acquire lock and release lock routines. If we don't have
anything in those routines you can see strange things happening. There is
one lock required (which makes things simple). At the moment (without any
code filled in to these routines) we see things like
AcquireLock(A)
ReleaseLock(A)
AcquireLock(A)
AcquireLock(A)
which is understandable. Because there is nothing there to stop a second
attempt to lock when the lock is already active. We need the second acquire
request to wait until the release is called.
First thing we tried was to use a wait queue with
interruptible_sleep_on/wake_up_interruptible but that results in large oops
that freezes the machine - nothing in /var/log/messages. We thought then
that it could be when a second sleep request was made on the wait queue
(i.e. when struct wait_queue != NULL) so we set up a FIFO of wait queues. No
dice. We tried going back to basics and just having a loop which watched a
lock state variable:
while (locked)
schedule_timeout(50);
This, too, resulted in an oops freeze. When we read Rubini a bit closer we
saw that schedule() is not re-entrant. So we have the situation when the
first acquire lock passes through, we set a variable. When the second
acquire comes in, we put it to sleep/go into an idle loop. However, when the
third one comes along we may be calling schedule() repeatedly.
What we're after is critical sections. Does anyone have any suggestions?
Thanks again,
L
-
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/