2002-09-22 13:00:19

by Scott Hoffman

[permalink] [raw]
Subject: 2.5.38 scheduling oops? at boot

Hi,
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!

And after the oops came this:
CPUs done 4294967295

The kernel was compiled with gcc 2.95.3, but under RedHat's 7.3.94 beta.

--
Scott M. Hoffman
[email protected]
Running Linux 2.4.18-11smp, up 0 days 0 hours 4 minutes


Attachments:
oops.txt (2.42 kB)

2002-09-22 18:25:36

by Robert Love

[permalink] [raw]
Subject: Re: 2.5.38 scheduling oops? at boot

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