Hello Johannes!
You don't give the scheduler a chance to run. If you sleep, the
scheduler will run and be able to deliver the signal and this is why it
works then.
Spinning like this is bad. That should actually freeze a UP machine if
I do not miss something.
The driver is _only_ for systems with many CPUs otherwise polling
wouldn't be a good idea at all...
O.K. the scheduler can't deliver the signal - that's reasonable. But why
can one kernel thread make a system unstable even if there are several CPUs?
Could the system instability appear (for example), because the "events"
thread which runs on the same CPU like my kernel thread, doesn't process
the works which are in its work queue? Or are all works of the "default"
queue delivered to other "events" threads on the free CPUs?
I would do the following (might be wrong):
while (!signal_pending(current))
schedule();
Thanks for this good idea.
Now I try to use the driver with a kernel where preemption is enabled
but it could be a solution for non-preempt kernels...
Regards and Many Thanks!
Lukas
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
