Re: 2.5.38 scheduling oops? at boot

[Robert Love]

On Sun, 2002-09-22 at 09:04, Scott M. Hoffman wrote:

>   I booted into 2.5.38 on a dual amd duron system using profile=2 on 
> command line, and the system seemed a bit sluggish just to get bash to 
> complete a filename in /proc.  I found the attached oops after these  
> messages:
> 	Starting migration thread for cpu 1
> 	bad: Scheduling while atomic!
> ...
> Trace; c01186ed <schedule+3d/430>
> Trace; c0118d9c <wait_for_completion+9c/100>
> Trace; c0118b30 <default_wake_function+0/40>
> Trace; c0118b30 <default_wake_function+0/40>
> Trace; c011a2c5 <set_cpus_allowed+145/170>
> Trace; c011a33e <migration_thread+4e/340>
> Trace; c011a2f0 <migration_thread+0/340>
> Trace; c0106f0d <kernel_thread_helper+5/18>
> Trace; c01186ed <schedule+3d/430>
> Trace; c0118d9c <wait_for_completion+9c/100>
> Trace; c0118b30 <default_wake_function+0/40>
> Trace; c0118b30 <default_wake_function+0/40>
> Trace; c011a2c5 <set_cpus_allowed+145/170>
> Trace; c012274f <ksoftirqd+4f/f0>
> Trace; c0122700 <ksoftirqd+0/f0>
> Trace; c0106f0d <kernel_thread_helper+5/18>

This particular occurrence is known; thanks.  The startup of the
migration_threads calls set_cpus_allowed(), and set_cpus_allowed()
sleeps while disabling preemption.

It will not hurt anything, but it needs to be fixed.  Before that, I
need to find out why set_cpus_allowed() dies without the
preempt_disable() in there.

	Robert Love