> I found this same problem in while trying to run down timer bh issues.
> With out looking at the keyboard driver (since this is IMHO a tasklet
> issue), I recommend that we not set the "pending" bit
> (__cpu_raise_softirq()) if the tasklet fails because of count !=0, and
> then modify the enable macro to, if the count is now 0, do the
> __cpu_raise_softirq(). This still leaves the issue of the
> tasklet_trylock(t), which will fail in the same way, but there we are
> contending with another cpu and the rules say it can only run on one cpu
> at a time.
hmm.. interesting. I agree with you that this is a softirq tasklet
scheduling problem, not just related to the keyboard tasklet. According
to the rules you stated, the tasklet_trylock(t) is bogus and can be
removed. So what you suggest is to reschedule the tasklet, but not
raise the pending bit if the tasklet is disabled. I can live with that
:)
I will produce and test a patch based on this tonight.
> On the other hand, why is this bothering you? You don't say what kernel
> version you are on, but the later versions push this sort of thing off
> to ksoftirqd (a kernel thread) which allows the system to boot (even if
> the thread doesn't exist yet, and it doesn't at this point).
Sorry, I am running (available from cvs.parisc-linux.org)
Linux vega 2.4.16-pa5 #2 SMP Thu Nov 29 21:35:27 MST 2001 parisc unknown
Since this code is arch independent, it is very similar to the 2.4.16
kernel. (Before posting to the list, I did verify that this problem
existed in the 2.4.16 kernel, and the code paths were the same.)
The reason I tracked this problem down was, if I enabled CONFIG_SMP
(C200+ is a single processor system), the system would "hang" after the
following bootup message:
Based upon Swansea University Computer Society NET3.039
UP kernels worked fine, but SMP kernels would "hang" every time. I
still do not understand why toggling CONFIG_SMP triggered this "hang",
but it did. Looks I need to keep digging further and try to understand
why CONFIG_SMP "hangs" the system.
> The tasklet info suggests that it is ok for a tasklet to reschedule
> itself, however, in the current system, this means that it will run each
> interrupt. Surly a timer would be a better answer, except we don't have
> sub jiffie timers... yet.
> --
> George george@mvista.com
> High-res-timers: http://sourceforge.net/projects/high-res-timers/
> Real time sched: http://sourceforge.net/projects/rtsched/
>
Thanks for your feedback George!
- Ryan
parisc-linux newbie kernel hacker.
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:39 EST