Hi,
i had some loops on the annoying "bug in get_wchan" and after i hopefully
understood whats going on
arch/mips/kernel/process.c
196 unsigned long get_wchan(struct task_struct *p)
197 {
198 unsigned long schedule_frame;
199 unsigned long pc;
200
201 if (!p || p == current || p->state == TASK_RUNNING)
202 return 0;
203
204 pc = thread_saved_pc(&p->thread);
205 if (pc == (unsigned long) interruptible_sleep_on
206 || pc == (unsigned long) sleep_on) {
207 schedule_frame = ((unsigned long *)p->thread.reg30)[9];
208 return ((unsigned long *)schedule_frame)[15];
209 }
210 if (pc == (unsigned long) interruptible_sleep_on_timeout
211 || pc == (unsigned long) sleep_on_timeout) {
212 schedule_frame = ((unsigned long *)p->thread.reg30)[9];
213 return ((unsigned long *)schedule_frame)[16];
214 }
215 if (pc >= first_sched && pc < last_sched) {
216 printk(KERN_DEBUG "Bug in %s\n", __FUNCTION__);
217 }
218
219 return pc;
220 }
What does "thread_saved_pc(&p->thread);" return ? Does it really
return the exact address of the schedule functions as assumed in
205-214 ?
Most other architectures search the stack page for the calling function
but it seems their asmlinkage is more strict in the means of
location of the return address on the stack.
The current implementation is buggy not only in the means of
the printk but also in the wchan - Most of the output
is "schedule" itself which means none of the statements above
had been true but when extending the printk with the pc
it never exactly matches &schedule so a == schedule wont help.
Flo
--
Florian Lohoff flo@rfc822.org +49-subject-2-change
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."
|