On 3/29/07, Tom Chen <[EMAIL PROTECTED]> wrote:
Hi Paul,
Could you give more explanation on your previous reply? Do you mean that I
should release all locks before re-scheduling timer in the timeout handler?
[b]"Don't take a lock within your timeout function that's held across
schedulng it. That can lead to precisely the sort of cycle you're
experiencing...."[/b]
In my 1 second timer handler, after job is done, it calls timeout( ) to
re-schedule itself, so the qla_timer( ) can be called again at next second, but
I did not release mutex before calling timeout( ). Is this the true origin of
the deadlock?
Like Jim said in his reply, I was slightly wrong. The problem is with
untimeout, so self-rescheduling is ok until you come to try to stop
things using untimeout().
With more thought, I wonder if your cycle is caused by holding locks
across calls into gld which your gldm entry points also take. Check
out the gld manpages in sections 9e and 9f as I recall they have quite
detailed info. on when you can hold locks and when you can't.
Paul
--
Paul Durrant
http://www.linkedin.com/in/pdurrant
_______________________________________________
networking-discuss mailing list
[email protected]
