Re: debug rsdl 0.33

[Con Kolivas <kernel@kolivas.org>]

On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
> On 3/24/07, Con Kolivas <kernel@kolivas.org> wrote:
> >  kernel/sched.c |   51
> > +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51
> > insertions(+)
>
> 2.6.21-rc4-mm1 also fails for me.
>
> I tried pure 2.6.21-rc4-mm1, +hotfixes, +hotfixes+rsdl33 and at last
> also added above debug patch.

Thank you very much for the effort!
>
> The oops from with the debug-patch added:
> [   65.426126] Freeing unused kernel memory: 312k freed
> (on the console the system is starting up, getting until "Letting udev
> process events ...")
> [   66.665611] Unable to handle kernel NULL pointer dereference at
> 0000000000000020 RIP:
> [   66.682030]  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e

The debug patch didn't do anything. This means it is not an unset bitmap 
problem at all otherwise it should have self corrected itself.

> The system in x86_64, two 2218 on a MCP55 nvidia chipset.
>
> 2.6.21-rc3-mm1 works fine.
>
> (gdb) list *0xffffffff8026167c
> 0xffffffff8026167c is in schedule (kernel/sched.c:3619).

	next = list_entry(queue->next, struct task_struct, run_list);
	rq->prio_level = idx;

> 3614            /*
> 3615             * When the task is chosen it is checked to see if its
> quota has been
> 3616             * added to this runqueue level which is only performed
> once per 3617             * level per major rotation for each running task.
> 3618             */
> 3619            if (next->rotation != rq->prio_rotation) {

Urgh. Dereferencing there? That can only be next that's deferencing meaning 
the run_list entry is bogus. That should only ever be done under runqueue 
lock so I have a race somewhere where it's not. Time for more looking.

> Torsten

Thanks!

-- 
-ck