https://github.com/torvalds/linux
Revision 9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 authored by David S. Miller on 13 April 2012, 18:56:22 UTC, committed by David S. Miller on 13 April 2012, 18:56:22 UTC
The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().

Register DS using device_initcall() insteal.

Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: stable@vger.kernel.org
1 parent 4166fb6
Raw File
Tip revision: 9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 authored by David S. Miller on 13 April 2012, 18:56:22 UTC
sparc64: Fix bootup crash on sun4v.
Tip revision: 9e0daff
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