[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Monday 18 April 2005 17:34, Robin Cornelius wrote:
On Sunday 17 April 2005 22:59, John Daragon wrote:Robin Cornelius wrote:BIG Snip...BIGGER SNIP..So tasklet_schedule() *is* being called. And I presume there's no other invocation of tasklet_disable() anywhere so that the disable count is zero at this stage... Actually, what I'm trying to say is : "Is (0 == adapter->rx_tasklet.count) at this juncture ?" tasklet_schedule just puts it on the head of the per-cpu tasklet list, so if it's called (which it seems to be from your direct call mod...) then this *must* work,
I've got it!
IMHO its a kernel bug, look at these line from softirq.c in the function
tasklet action :-
if (tasklet_trylock(t)) {
if (!atomic_read(&t->count)) {
if (!test_and_clear_bit(TASKLET_STATE_SCHED,
&t->state))
BUG();
t->func(t->data);
tasklet_unlock(t);
continue;
}
tasklet_unlock(t);
}
right in the middle there is
if (!atomic_read(&t->count))
so if the count is non zero then the tasklets DO NOT RUN! and ksoftirqd
deadlocks. If i call tasklet_enable() it DECREMENTS the count by 1 and
tasklet_disable() INCREMENTS the count by one, therefor if you do a
tasklet_enable() your count ends up at -1 which is no good.
Removing the enable line from my code allows the tasklets to run BUT now I
don't have any enables to match disables so the count just gets bigger!, what
a PITA.
--
Robin Cornelius
---------------------------------------------------
robin@xxxxxxxxxxxxxxxxxxxxx
http://www.cornelius.demon.co.uk
http://sourceforge.net/projects/rt2400
GPG Key ID: 0x729A79A23B7EE764
http://www.biglumber.com/x/web?qs=0x729A79A23B7EE764
Attachment:
pgp00017.pgp
Description: PGP signature