scheduler problems
Quoted 2 lines
(given that the current 2.2 kernel is 2.2.21, the first thing would
be to
Quoted 2 lines
test it there too.)
Thanks, I 'll do that.
Quoted 1 line
Quoted 1 line
[...] It is due to the fact that the
schedule()function does not
find
Quoted 3 lines
Quoted 1 line
the 'current' process in the runqueue. [...]
a crash in line 384 means that the runqueue got corrupted by
something,
Quoted 1 line
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?
Quoted 1 line
Quoted 1 line
Can anyone tell me what's happening here? My kernel module is no
way the
Quoted 3 lines
Quoted 1 line
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
Quoted 4 lines
Ingo
Anjali Kulkarni
Software Engineer
Indra Networks
~Living Well is the best Revenge~
Quoted 12 lines · Anjali Kulkarni
Quoted 2 lines
(given that the current 2.2 kernel is 2.2.21, the first thing would
be to
Quoted 2 lines
test it there too.)
Thanks, I 'll do that.
Quoted 1 line
Quoted 1 line
[...] It is due to the fact that the
schedule()function does notfind
Quoted 2 lines
Quoted 1 line
the 'current' process in the runqueue. [...]
Quoted 8 lines
Quoted 1 line
a crash in line 384 means that the runqueue got corrupted by
something,
Quoted 1 line
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_structof 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've had similar problems when some code invalidated CPU cache and an interrupt came in at the wrong time.
Richard