2.5.38 scheduling oops? at boot

2.5.38 scheduling oops? at boot

[Scott M. Hoffman]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 521 bytes --]

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
scott781@attbi.com
Running Linux 2.4.18-11smp, up 0 days 0 hours 4 minutes 


[-- Attachment #2: Type: TEXT/PLAIN, Size: 2473 bytes --]

ksymoops 2.4.5 on i686 2.5.38.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.38/ (default)
     -m /boot/System.map-2.5.38 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Sep 22 07:38:23 Scotts kernel: c1425f00 c01186ed c028ad80 c1424000 c1425f70 c1425f78 00000000 00000000 
Sep 22 07:38:23 Scotts kernel:        00000000 00000000 00000000 00000000 c1424000 c1425f78 c0118d9c 00000000 
Sep 22 07:38:23 Scotts kernel:        c1424000 c035acc0 c1424000 c1425fa4 00000000 c14230c0 c0118b30 00000000 
Sep 22 07:38:23 Scotts kernel: Call Trace: [<c01186ed>] [<c0118d9c>] [<c0118b30>] [<c0118b30>] [<c011a2c5>] 
Sep 22 07:38:23 Scotts kernel:    [<c011a33e>] [<c011a2f0>] [<c0106f0d>] 
Sep 22 07:38:23 Scotts kernel: c1421f1c c01186ed c028ad80 c1420000 c1421f8c c1421f94 00000000 00000000 
Sep 22 07:38:23 Scotts kernel:        00000000 00000000 00000000 00000000 c1420000 c1421f94 c0118d9c 00000000 
Sep 22 07:38:23 Scotts kernel:        c1420000 c035acc0 c1420000 c1421fc0 00000000 c14237c0 c0118b30 00000000 
Sep 22 07:38:23 Scotts kernel: Call Trace: [<c01186ed>] [<c0118d9c>] [<c0118b30>] [<c0118b30>] [<c011a2c5>] 
Sep 22 07:38:23 Scotts kernel:    [<c012274f>] [<c0122700>] [<c0106f0d>] 
Warning (Oops_read): Code line not seen, dumping what data is available


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>


2 warnings issued.  Results may not be reliable.

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