Doing that might indeed help pinpoint the error (and it's easy enough:
just do a NULL dereference there).
The "idle task may not sleep" messages mean that (surprise surprise) the
idle task has called schedule() with current->state != TASK_RUNNING. As
the idle task (pid 0, aka "swapper") is the process that is designed to
run when nothing else runs, the idle task obviously can't sleep (or who
would we choose to run?).
This happens in drivers when they
(a) sleep in an interrupt that happened while the idle task was active.
That's _really_ bad.
(b) sleep during the very early initializations when the idle task is
the only process we have. This is usually true of most "xx_init()"
type routines. The system isn't fully initialized yet, and we
can't sleep.
You probably have a case of (b): the previous scheduler ignored the idle
task trying to sleep (it actually continued running despite asking to
sleep), but the new scheduler gives an error message (the _behaviour_
should be identical, it just warns about it now, as it really is an
error).
The PS/2-mouse driver had this proble, and that should be fixed in
1.3.14. The cdu31a driver also had the problem, and I think that should
be fixed in the (upcoming) 1.3.15 release. What other drivers give the
error?
Linus