Hi,
after my post(1) talking about the GPF caused by an incorrect mem= option
I see another post+patch(2) from Pavel Machek with similar problem.
I really _like_ this patch that move the bad GPF early on boot in a safe
place where filesystem are still a dream ;)
I started to play with it and now looks better:
o No more GPF but "controlled" panic
o faster
o cleaner :?
To give a try simply boot your 32Mbytes machine with mem=64M option
with and without the patch.
Follow the diff over a clean 2.3.24:
------------------------------------
diff -urN linux-2.3.24.ori/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.3.24.ori/Documentation/Configure.help Sat Oct 30 18:53:41 1999
+++ linux/Documentation/Configure.help Sun Oct 31 01:54:24 1999
@@ -175,6 +175,16 @@
on the Alpha. The only time you would ever not say Y is to say M in
order to debug the code. Say Y unless you know what you are doing.
+Check memory on boot
+CONFIG_MEM_CHECK
+ If you say Y here, a simple memory check will be done early on boot.
+ This can be useful in the follow situations:
+ o mem=xxx option greater than installed physical memory
+ o wrong memory size detection
+ o fault memory
+ If the check fail, kernel react with a "controlled" panic asking to
+ check memory configuration, instead of a bad and crude GPF.
+
High Memory support
CONFIG_NOHIGHMEM
If you are compiling a kernel which will never run on a machine
diff -urN linux-2.3.24.ori/arch/i386/config.in linux/arch/i386/config.in
--- linux-2.3.24.ori/arch/i386/config.in Sat Oct 30 19:39:57 1999
+++ linux/arch/i386/config.in Sat Oct 30 19:49:32 1999
@@ -54,6 +54,7 @@
define_bool CONFIG_X86_PAE y
fi
+bool 'Boot memory check' CONFIG_MEM_CHECK
bool 'Math emulation' CONFIG_MATH_EMULATION
bool 'MTRR (Memory Type Range Register) support' CONFIG_MTRR
bool 'Symmetric multi-processing support' CONFIG_SMP
diff -urN linux-2.3.24.ori/init/main.c linux/init/main.c
--- linux-2.3.24.ori/init/main.c Sat Oct 30 00:10:55 1999
+++ linux/init/main.c Sun Oct 31 02:29:31 1999
@@ -7,6 +7,8 @@
* Added initrd & change_root: Werner Almesberger & Hans Lermen, Feb '96
* Moan early if gcc is old, avoiding bogus kernels - Paul Gortmaker, May '96
* Simplified starting of init: Michael A. Griffith <grif@acm.org>
+ * Simple memory check: Luca Montecchiani <m.luca@iname.com>
+ * Pavel Machek <pavel@suse.cz>, Oct '99
*/
#define __KERNEL_SYSCALLS__
@@ -440,6 +442,33 @@
#endif
+#ifdef CONFIG_MEM_CHECK
+/*
+ * Perform simple memory check
+ */
+static void memory_check(void)
+{
+ void **p_current = NULL, **p_previous = NULL;
+
+ printk( "Memory: checking memory... " );
+ while ( (p_current = (void *) get_free_page(GFP_ATOMIC)) ) {
+ *p_current = p_previous;
+ p_previous = p_current;
+ }
+ printk( "OK.\n" );
+
+ printk( "Memory: releasing checked memory... " );
+ /* we do it in reversed order to be more suspicious ;) */
+ while ( p_previous ) {
+ p_current = *p_previous;
+ p_previous = *p_previous;
+ if ( ( p_current ) && ( !free_page( (unsigned long)p_current ) ) )
+ panic("Bad Memory: Check your mem= option or your hardware !");
+ }
+ printk( "OK.\n" );
+}
+#endif
+
/*
* Activate the first processor.
*/
@@ -499,6 +528,11 @@
proc_root_init();
#endif
mempages = num_physpages;
+
+#ifdef CONFIG_MEM_CHECK
+ /* Before mounting root so that we don't damage it */
+ memory_check();
+#endif
fork_init(mempages);
filescache_init();
------------------------------------
References:
(1) http://boudicca.tux.org/hypermail/linux-kernel/1999week44/0905.html
(2) http://boudicca.tux.org/hypermail/linux-kernel/1999week44/0878.html
thanks Pavel,
luca
-- ------------------------------------------------------------------ E-mail......: Luca Montecchiani <m.luca@iname.com> W.W.W.......: http://i.am/m.luca - http://luca.myip.org Speakfreely.: sflwl -hlwl.fourmilab.ch luca@ I.C.Q.......: 17655604 -----------------------=(Linux since 1995)=-----------------------Non esiste vento favorevole per il marinaio che non sa dove andare Seneca --------------15548041F34F17DFB100AEF8 Content-Type: application/octet-stream; name="mem_check.diff.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mem_check.diff.gz"
H4sICJSRGzgCA21lbV9jaGVjay5kaWZmAJVW+2/iOBD+Gf6K2a7UQoFQXm3JPgTb60sLLSqs 7lY6KTKOk1gkduQkpezp/vcbO+HVZXt3rQTBnhl/M99847jc86CRqQcIucheGm2rY7W7llS8 +ZukWcRESlIuRfNKCo/7mWJWwMI4t37TpNxoNP5f0NKUpPBIU+icQevS7nXsbgta/X6/XKvV /sOJpWkmcv8WnLXsXtdud3P/wQAarYte/Rxq+qt1DoNBGQCkgDRgMAzjgFgww0cpwhWkPGKw khksZRa6wJ6ZAiFTSMgKvgNPIJXmeQxcmDDKRQtcdNk8801IKl1mwdQ4ZCJkSWICLoRcwjLA PPUvohi4kgvfKkO5dhUwuoCIRVKtNLK5lCmuPj7c3N864+uxc3V3ffW1XAO494x7DidgitWB QMKjOGRrf2qCLXkYwlwfIhgwosJNYEvHmQWYCyVCm2QJ87IQEzLwPRmGiDThaWYqndjlWgkT 1eE/vby8gIz1MviKkVTnHmAULpKUhCFzIQ5WCackLNAUvkslhb8GmPAfiIuljOpAhYVHsjDd OJlETTFNMh7hYR0WTAkWAp6LRC95GmDqR1SKVEl99BHERHAKJFlgXZETHYbuVpYWPWPyqhvQ jLggPQw0xwciXKAqcxncTm6wTGW4434A4wJ2FsdSpWUoeHl4vLu/vUN2dB8UvGhaqYxiHmoI ZA15GXAa5JQI01IK2xVrSCAiNOCCld1fi5EoGjR55/K8meO3kKhcEQd2DkvvgOGe4vp2p2/3 Ll4r7t/duujZ3gqt19U6w8+LQmVIs4fpOdh34bpuf1yeO5PhNazK4HHd/Wbz5Au25l4Ln8BP AoDcdEyQexZloSFyazec3TnX42+j4ez+8WFjPHt6gkrB4WwVM3giwsdP5nPkX1XXxG7joMfa e7qKIpYqbCs8LuWNWEmKitbsvnabjidv0cgFT5sR4cKiRXl3Vg7TtmOwW/ezM7t1Zvd6r+na M9+Zh227jTS1tjRdaJYu6pc5SacAQ9dF6Wp/5cIxll9XyFHIiA2/6xZWOCgjlsyZ8vH5GO6I SGDEFM7jOtywOZz0z/NQY4njIJ833AOfUj00ZejinHqW3NWFm0s/SwppJNCACUofbrGUEcHF OoxxuG3iTfVs4x5HfDhiVKoDoGA1VhtPQ10RFNjQgluFtddD4aOPTwNCI6yh/xn7axNmf0Ta MMooQcACJxGqEIcHfIysEBcHXJCIWajkz7n7wb8Jecajx6hgtoCPsf41SHCYWvTH57qp/gkW HLNoYpfD+1wK4Dhfr58erkfO9Pv0ajgaTR3HkNLtnmlaut12vdMxzKAPE9hRWiPvuYf+Pyui 1jw1CCdMeVJFh64Cvd8s1xJ9cVLQJBTbjtmu6JVqufYXDmKzeXoaOzRTCq9a+AQP30ajulmL FXvmEpnLFz/gfKyVYsVFuqjAUS4wOz+Sb4a9ZVlwBFU0LuEQRGQVqOyGr+RHVsFnqeMpxpyY +KxyezNxhrPH8f1VtQpV0NhKe7C2cHTo0h66jZ3Z+nsX5eNX60+h8cBh9IqFjBh1mzyY+3Ma zVNY6msVeKqvTKXneYKGmzcBvFHRheF8SGJODaYPVUPBpgQ7cIvktrlhAqdvZfd6E1VWMSHX AapwfIwL77bVhEomEu4LRBniPVzdtcV/HaVk7s7K0Re8BtfFyN9K8FpT5u5fX/xS5WsBUe5S X3jvjqpvVxo3ik7GKxUbFiVRGuLl/4wvEPk7B1dJCsVslcrKRWNU0e+bK6V9WW+1jCpK2szM JkcPgQqevdFJCXHqjHWdRBY5+mXE/DbN+ksNaU6/ME+TFslMmBmjD4BE6tebNCdcnKTgkgjD aeoNn3s6MqluFAsljLfIIa5RaaglD1sgoXpobPD/A/HZV9iKCwAA
--------------15548041F34F17DFB100AEF8--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/