On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
> On 3/24/07, Con Kolivas <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
