Skip to main content

Browse the archive

Revision 050c6c9b896625d9fa498265be17b82c5fc65257 authored by Ingo Molnar on 19 December 2010, 22:24:27 UTC, committed by Ingo Molnar on 19 December 2010, 22:24:27 UTC 
sched: Remove debugging check
 
Linus reported that the new warning introduced by commit f26f9aff6aaf
"Sched: fix skip_clock_update optimization" triggers. The need_resched
flag can be set by other CPUs asynchronously so this debug check is
bogus - remove it.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <AANLkTinJ8hAG1TpyC+CSYPR47p48+1=E7fiC45hMXT_1@mail.gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
1 parent 8e92c20
Raw File
memory.txt 
There are several classic problems related to memory on Linux
systems.

	1) There are some motherboards that will not cache above
	   a certain quantity of memory.  If you have one of these
	   motherboards, your system will be SLOWER, not faster
	   as you add more memory.  Consider exchanging your 
           motherboard.

All of these problems can be addressed with the "mem=XXXM" boot option
(where XXX is the size of RAM to use in megabytes).  
It can also tell Linux to use less memory than is actually installed.
If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
physical address space collisions.

See the documentation of your boot loader (LILO, grub, loadlin, etc.) about
how to pass options to the kernel.

There are other memory problems which Linux cannot deal with.  Random
corruption of memory is usually a sign of serious hardware trouble.
Try:

	* Reducing memory settings in the BIOS to the most conservative 
          timings.

	* Adding a cooling fan.

	* Not overclocking your CPU.

	* Having the memory tested in a memory tester or exchanged
	  with the vendor. Consider testing it with memtest86 yourself.
	
	* Exchanging your CPU, cache, or motherboard for one that works.
back to top