Subject: crash in __alloc_bootmem_core on SGI current cvs

From: Florian Lohoff <[email-masked]>
Date: Mon, 15 Jan 2001 18:11:33 +0100

Hi,
the current cvs kernel crashes in __alloc_bootmem_core here:

[...]
        printk("%s, %d memset %p 0 %d\n", __FUNCTION__, __LINE__, ret, size);
        memset(ret, 0, size);
        printk("%s, %d\n", __FUNCTION__, __LINE__);
        return ret;
[...]

Output coming:

__alloc_bootmem_core, 230
__alloc_bootmem_core, 234 memset 81000000 0 36864

I guess this is really bogus as the ARCS MEMORY debug gives:

[0,a8748da0]: base<00000000> pages<00000001> type<Exception Block>              
[1,a8748dbc]: base<00000001> pages<00000001> type<ARCS Romvec Page>             
[2,a8748d84]: base<00008002> pages<00000173> type<Standlong Program Pages>      
[3,a87491cc]: base<00008175> pages<000005cb> type<Generic Free RAM>             
[4,a874919c]: base<00008740> pages<000000c0> type<ARCS Temp Storage Area>       
[5,a8749180]: base<00008800> pages<00007800> type<Generic Free RAM>            

Might this be the sgi/arc bootmem/memory.c doesnt alloc everything
or frees to much ?

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 15 Jan 2001 22:21:27 +0100 (MET)

> Might this be the sgi/arc bootmem/memory.c doesnt alloc everything

 Thanks for a useful report.  I am the responsible person, it would seem,
as I've rewritten the bootmem allocation code recently to make it
consistent across all the subports and more flexible as well.  I could 
only test the DECstation code so it's possible I screwed up things
elsewhere.  I'll look at the code and I'll provide a patch, either a fix,
if I am able to develop it immediately or some debugging code otherwise.

 As I see prink() works for you could you please also check and report the
memory map as found by the kernel, i.e. the lines output after "Determined
physical RAM map:", if any?  The code is executed very early, before an
actual allocation takes place, so it should run regardless.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 06:10:52 -0200

> actual allocation takes place, so it should run regardless.

Apropos printk, could port maintainers look into
arch/mips64/sgi-27/ip27-console.c.  It has some code which enables the
kernel to use printk already during the very early kernel startup.  I
found this capability to be invaluable and think others will also want
to have it without the uglyness of having a separate function for
early printing such as prom_printf.  I already have such a patch for
the Indy but not for other systems.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 16 Jan 2001 15:36:18 +0100

> actual allocation takes place, so it should run regardless.

Ok - when i do this ...

Index: arch/mips/arc/memory.c
===================================================================
RCS file: /cvs/linux/arch/mips/arc/memory.c,v
retrieving revision 1.17
diff -u -r1.17 memory.c
--- arch/mips/arc/memory.c	2001/01/03 18:15:24	1.17
+++ arch/mips/arc/memory.c	2001/01/16 13:53:45
@@ -120,7 +120,7 @@
 		unsigned long base, size;
 		long type;
 
-		base = __pa(p->base << PAGE_SHIFT);	/* Fix up from KSEG0 */
+		base = p->base << PAGE_SHIFT;
 		size = p->pages << PAGE_SHIFT;
 		type = prom_memtype_classify(p->type);

I get further down the road with memory initialisation.

Also the pages no in zone(0) looks much saner:

Before:
	On node 0 totalpages: 589824
	zone(0): 589824 pages.

After:
	On node 0 totalpages: 65536
	zone(0): 65536 pages.

Later on it crashes with:

[...]

start_kernel, 541
start_kernel, 543
Calibrating system timer... 1250000 [250.00 MHz CPU]
Got a bus error IRQ, shouldn't happen yet
$0 : 00000000 1004fc00 00000001 00000000
$4 : 88009cd8 00000000 00000008 00000000
$8 : 1004fc01 1000001f 0000000a 00000001
$12: 00000000 00000004 00000000 00000001
$16: 00000000 00000002 0000000a 880083d8
$20: 00000001 a8746f70 9fc5c2b4 00000000
$24: 00002590 00000001
$28: 88008000 88009cd8 00000001 88010118
epc   : 880127b0
Status: 1004fc03
Cause : 10004000
Status: 1004fc03
Cause : 10004000
Cause : 10004000
Spinning...

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 13:57:37 -0200

> +		base = p->base << PAGE_SHIFT;

This fix looks good.

> 	On node 0 totalpages: 65536

I probably already got used too machines with gigs of memory to notice ;-)

> $0: 00000000 1004fc00 00000001 00000000
> $4: 88009cd8 00000000 00000008 00000000
> $8: 1004fc01 1000001f 0000000a 00000001
> epc: 880127b0
> Cause: 10004000
> Cause: 10004000
> Cause: 10004000

Can you decode the addresses in $epc and $31 for me?

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 17:01:15 +0100 (MET)

> +++ arch/mips/arc/memory.c	2001/01/16 13:53:45

 That's about the correct fix.

> $8 : 1004fc01 1000001f 0000000a 00000001

 It looks like an unoccupied location access in mem_init().  Weird.  Here
is a preliminary patch that fixes a few memory map problems I discovered
till far.  It incorporates a fix like yours as well as a few others.  It
won't fix the above crash, I'm afraid.  It was not sufficiently tested,
either.  I'll prepare a few debugging changes to mem_init() so we can
track the fatal access down.

 Meanwhile, could you please try to boot with "mem=0x07800000@0x08800000"
command line option?  This will show if the non-contiguous memory is the
problem or not -- you have a relatively small block at the beginning.

  Maciej

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 17:06:29 +0100 (MET)

> I probably already got used too machines with gigs of memory to notice ;-)

 The number actually denotes the highest page, regardless of the number of
pages, so you only need a single page placed far away from address zero to
observe such large counts.

> Can you decode the addresses in $epc and $31 for me?

 Probably a memory access in free_all_bootmem() or so.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 17:08:26 +0100 (MET)

Hi,

 Here is the patch I mentioned earlier.

  Maciej

patch-mips-2.4.0-test12-20010110-mem_map-39
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/arc/memory.c linux-mips-2.4.0-test12-20010110/arch/mips/arc/memory.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/arc/memory.c	Thu Jan  4 05:26:53 2001
+++ linux-mips-2.4.0-test12-20010110/arch/mips/arc/memory.c	Tue Jan 16 01:17:44 2001
@@ -12,6 +12,7 @@
 #include <linux/bootmem.h>
 #include <linux/swap.h>
 
+#include <asm/addrspace.h>
 #include <asm/sgialib.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>
@@ -120,7 +121,7 @@ void __init prom_meminit(void)
 		unsigned long base, size;
 		long type;

diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/baget/prom/init.c linux-mips-2.4.0-test12-20010110/arch/mips/baget/prom/init.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/baget/prom/init.c	Thu Dec 14 05:26:23 2000
+++ linux-mips-2.4.0-test12-20010110/arch/mips/baget/prom/init.c	Tue Jan 16 01:00:28 2001
@@ -4,16 +4,22 @@
  * Copyright (C) 1998 Gleb Raiko & Vladimir Roganov 
  */
 #include <linux/init.h>
+#include <asm/addrspace.h>
 #include <asm/bootinfo.h>
 
 char arcs_cmdline[COMMAND_LINE_SIZE];
 
 void __init prom_init(unsigned int mem_upper)
 {
-	mips_memory_upper = mem_upper;
+	mem_upper = PHYSADDR(mem_upper);
+
 	mips_machgroup  = MACH_GROUP_UNKNOWN;
 	mips_machtype   = MACH_UNKNOWN;
 	arcs_cmdline[0] = 0;
+
+	vac_memory_upper = mem_upper;
+
+	add_memory_region(0, mem_upper, BOOT_MEM_RAM);
 }
 
 void prom_free_prom_memory (void)
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/baget/setup.c linux-mips-2.4.0-test12-20010110/arch/mips/baget/setup.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/baget/setup.c	Tue Mar 28 04:26:01 2000
+++ linux-mips-2.4.0-test12-20010110/arch/mips/baget/setup.c	Tue Jan 16 01:43:10 2001
@@ -14,7 +14,7 @@
 
 #include <asm/baget/baget.h>
 
-extern long mips_memory_upper;
+long int vac_memory_upper;
 
 #define CACHEABLE_STR(val) ((val) ? "not cached" : "cached")
 #define MIN(a,b)           (((a)<(b)) ? (a):(b)) 
@@ -172,7 +172,7 @@ static void __init vac_show(void)
 
 static void __init vac_init(void)
 {
-	unsigned short mem_limit = ((mips_memory_upper-KSEG0) >> 16);
+	unsigned short mem_limit = (vac_memory_upper >> 16);
 
 	switch(vac_inw(VAC_ID)) {
 	case 0x1AC0:
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/galileo-boards/ev64120/setup.c linux-mips-2.4.0-test12-20010110/arch/mips/galileo-boards/ev64120/setup.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/galileo-boards/ev64120/setup.c	Thu Jan  4 05:26:53 2001
+++ linux-mips-2.4.0-test12-20010110/arch/mips/galileo-boards/ev64120/setup.c	Tue Jan 16 00:37:52 2001
@@ -133,7 +133,6 @@ void ev64120_setup(void)
 
 	board_time_init = galileo_time_init;
 	mips_io_port_base = KSEG1;
-	mips_memory_upper = 32 * 1024 * 1024 | KSEG0;
 	set_cp0_status(ST0_FR, 0);
 
 #ifdef CONFIG_L2_L3_CACHE
@@ -174,7 +173,6 @@ void SetUpBootInfo(int argc, char **argv
 	mips_machtype = MACH_EV64120A;
 }
 
-unsigned long mem_size;
 void __init prom_init(int a, char **b, char **c, int *d)
 {
 	unsigned long free_start, free_end, start_pfn, bootmap_size;
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/galileo-boards/ev96100/setup.c linux-mips-2.4.0-test12-20010110/arch/mips/galileo-boards/ev96100/setup.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/galileo-boards/ev96100/setup.c	Mon Nov  6 22:59:55 2000
+++ linux-mips-2.4.0-test12-20010110/arch/mips/galileo-boards/ev96100/setup.c	Tue Jan 16 00:35:49 2001
@@ -86,9 +86,6 @@ static void __init ev96100_irq_setup(voi
 void __init ev96100_setup(void)
 {
 
-	unsigned long mem_size, free_start, free_end, start_pfn,
-	    bootmap_size;
-
 #ifdef CONFIG_REMOTE_DEBUG
 	int rs_putDebugChar(char);
 	char rs_getDebugChar(void);
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/mips-boards/generic/memory.c linux-mips-2.4.0-test12-20010110/arch/mips/mips-boards/generic/memory.c
--- linux-mips-2.4.0-test12-20010110.macro/arch/mips/mips-boards/generic/memory.c	Sat Dec 30 05:26:48 2000
+++ linux-mips-2.4.0-test12-20010110/arch/mips/mips-boards/generic/memory.c	Tue Jan 16 01:19:47 2001
@@ -28,6 +28,7 @@
 #include <linux/mm.h>
 #include <linux/bootmem.h>
 
+#include <asm/addrspace.h>
 #include <asm/bootinfo.h>
 #include <asm/page.h>
 
@@ -135,7 +136,7 @@ void __init prom_meminit(void)
 		long type;
 
 		type = prom_memtype_classify (p->type);
-		base = __pa(p->base);			/* Fix up from KSEG0 */
+		base = PHYSADDR(p->base);		/* Fix up from KSEG0 */
 		size = p->size;
 
 		add_memory_region(base, size, type);
diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/addrspace.h linux-mips-2.4.0-test12-20010110/include/asm-mips/addrspace.h
--- linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/addrspace.h	Sat Aug 26 04:26:45 2000
+++ linux-mips-2.4.0-test12-20010110/include/asm-mips/addrspace.h	Tue Jan 16 01:04:14 2001
@@ -24,7 +24,7 @@
  * Returns the kernel segment base of a given address
  */
 #ifndef __ASSEMBLY__
-#define KSEGX(a)                (((unsigned long)(a)) & 0xe0000000)
+#define KSEGX(a)                ((__typeof__(a))(((unsigned long)(a) & 0xe0000000)))
 #else
 #define KSEGX(a)                ((a) & 0xe0000000)
 #endif
@@ -33,7 +33,7 @@
  * Returns the physical address of a KSEG0/KSEG1 address
  */
 #ifndef __ASSEMBLY__
-#define PHYSADDR(a)		(((unsigned long)(a)) & 0x1fffffff)
+#define PHYSADDR(a)		((__typeof__(a))(((unsigned long)(a) & 0x1fffffff)))
 #else
 #define PHYSADDR(a)		((a) & 0x1fffffff)
 #endif

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 14:24:49 -0200

> observe such large counts.

The Indy has it's memory starting at phys. 0x08000000; a part of it is also
mirrored at physical address zero.  So in case of an Indy the totalpages
number should indicate 128mb too much which means that Flo's machine should
have only 128mb real memory.  Right Florian?

   Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 16 Jan 2001 17:28:12 +0100

> observe such large counts.

Wouldnt be this correct ? Realsize is size - holes.

Index: mm/page_alloc.c
===================================================================
RCS file: /cvs/linux/mm/page_alloc.c,v
retrieving revision 1.49
diff -u -r1.49 page_alloc.c
--- mm/page_alloc.c	2001/01/11 04:02:45	1.49
+++ mm/page_alloc.c	2001/01/16 16:26:55
@@ -824,7 +824,7 @@
 		if (zholes_size)
 			realsize -= zholes_size[j];
 
-		printk("zone(%lu): %lu pages.\n", j, size);
+		printk("zone(%lu): %lu pages.\n", j, realsize);
 		zone->size = size;
 		zone->name = zone_names[j];
 		zone->lock = SPIN_LOCK_UNLOCKED;

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 17:34:45 +0100 (MET)

> have only 128mb real memory.  Right Florian?

 The memory map suggests it is so.

 But how does the Indy handle our kernel being linked at 0x80000000?  Does
the kernel always fit the mirrored area?

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 16 Jan 2001 17:44:18 +0100

> have only 128mb real memory.  Right Florian?

Correct "only" 128Mb :)

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 17:39:40 +0100 (MET)

> Wouldnt be this correct ? Realsize is size - holes.

 It look reasonable but is it what was really intended?  You should ask
the author or linux-kernel, I suppose.

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 16 Jan 2001 17:49:05 +0100

> problem or not -- you have a relatively small block at the beginning.

Works

[...]
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0 root=/dev/sda2 mem=0x07800000@0x08800000
Calibrating system timer... 1250000 [250.00 MHz CPU]
Console: colour dummy device 80x25
zs0: console input
Console: ttyS0 (Zilog8530)
Calibrating delay loop... 124.51 BogoMIPS
Memory: 118480k/122880k available (1176k kernel code, 4408k reserved, 75k data, 56k init)
[...]

Flo

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 16 Jan 2001 19:48:17 +0100

> > problem or not -- you have a relatively small block at the beginning.

Once removed all the debugging stuff even without the mem= parm - Interesting.

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 17:22:35 -0200

> the author or linux-kernel, I suppose. 

Which probably is Kanoj who is subscribed to this list.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 17:23:51 -0200

> the kernel always fit the mirrored area? 

Indy kernels are linked to 0x88002000.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 20:47:20 +0100 (MET)

> Indy kernels are linked to 0x88002000.

 Oh well, why can't it be done consistently in our linker script.  The
script does ". = 0x80000000;" -- it's at least confusing, even if the
"-Ttext" option has a priority (does it?).

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 16 Jan 2001 20:52:40 +0100 (MET)

> Once removed all the debugging stuff even without the mem= parm - Interesting.

 It's weird.  Could you please check it's repeatable?  It might be the
debugging stuff does destructive actions or we trigger an unrelated
problem such as a compiler/assembler/linker bug.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 16 Jan 2001 18:04:44 -0200

> "-Ttext" option has a priority (does it?).

It has; however the whole concept of how a linker script is interpreted
when used with -Ttext, -Tdata or -Tbss is undocumented.  It seems to be
working fine as long as the address passed to -Ttext is larger than the
address in the script, so the script is using the lowest possible
address which is KSEG0.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 17 Jan 2001 00:03:01 +0100

> problem such as a compiler/assembler/linker bug.

Works reliably afterwards ...

Flo

---

From: Kanoj Sarcar <[email-masked]>
Date: Wed, 17 Jan 2001 05:15:36 -0800 (PST)

> Which probably is Kanoj who is subscribed to this list.

realsize is fine, and that is what it is in Linus' tree. We want
to report actual number of pages, not number of pages including
the holes in memory.

Kanoj