> (given that the current 2.2 kernel is 2.2.21, the first thing would
be to
> test it there too.)
>
Thanks, I 'll do that.
> > [...] It is due to the fact that the schedule() function does not
find
> > the 'current' process in the runqueue. [...]
>
> a crash in line 384 means that the runqueue got corrupted by
something,
> most likely caused by buggy kernel code outside of the scheduler.
Right, I thought of that, but how is it that it gets corrupt at exactly
the same offset in task_struct of that process and every time with
different processes? (I have run it atleast 20-30 times). And it just
doesnt come if I kill the process in question? (I couldnt kill kupdate,
and hence it comes anyways). And I have checked the task_struct of that
process, the next_task & prev_task & other fields are not corrupted.
Ofcource, it's still possible, like if the memory allocated & freed by
my code is then used by scheduler for allocating task_struct; and then
it is accessed again by mistake by my code at the same offset.
But you feel sure it's a run queue corruption problem, and not anything
else? If so, is there any particular way to debug this?
> > Can anyone tell me what's happening here? My kernel module is no
way the
> > cause of any of this. [...]
>
> does it happen if you do not run your kernel module after bootup,
ever?
No, it does not:(
Thanks,
Anjali
>
> Ingo
>
>
Anjali Kulkarni
Software Engineer
Indra Networks
~Living Well is the best Revenge~
-
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 : Sat Jun 15 2002 - 22:00:24 EST