crash in __alloc_bootmem_core on SGI current cvs

crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

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                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Mon, 15 Jan 2001, Florian Lohoff wrote:

> 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 ?

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Mon, Jan 15, 2001 at 10:21:27PM +0100, Maciej W. Rozycki wrote:

>  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.

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

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Mon, Jan 15, 2001 at 10:21:27PM +0100, Maciej W. Rozycki wrote:
>  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.

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 03:36:18PM +0100, Florian Lohoff wrote:

> -		base = __pa(p->base << PAGE_SHIFT);	/* Fix up from KSEG0 */
> +		base = p->base << PAGE_SHIFT;

This fix looks good.

> 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.

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

> 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

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

  Ralf

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Ralf Baechle wrote:

> > Before:
> > 	On node 0 totalpages: 589824
> > 	zone(0): 589824 pages.
> > 
> > 
> > After:
> > 	On node 0 totalpages: 65536
> > 	zone(0): 65536 pages.
> 
> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 05:06:29PM +0100, Maciej W. Rozycki wrote:

> On Tue, 16 Jan 2001, Ralf Baechle wrote:
> 
> > > Before:
> > > 	On node 0 totalpages: 589824
> > > 	zone(0): 589824 pages.
> > > 
> > > 
> > > After:
> > > 	On node 0 totalpages: 65536
> > > 	zone(0): 65536 pages.
> > 
> > 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.

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?

> > Can you decode the addresses in $epc and $31 for me?
> 
>  Probably a memory access in free_all_bootmem() or so.

   Ralf

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Ralf Baechle wrote:

> 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?

 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? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 05:34:45PM +0100, Maciej W. Rozycki wrote:

> > 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?
> 
>  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? 

Indy kernels are linked to 0x88002000.

  Ralf

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Ralf Baechle wrote:

> 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?).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 08:47:20PM +0100, Maciej W. Rozycki wrote:

> > 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?).

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

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Tue, Jan 16, 2001 at 02:24:49PM -0200, Ralf Baechle wrote:
> 
> 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?
> 

Correct "only" 128Mb :)

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Tue, Jan 16, 2001 at 05:06:29PM +0100, Maciej W. Rozycki wrote:
> On Tue, 16 Jan 2001, Ralf Baechle wrote:
> 
> > > Before:
> > > 	On node 0 totalpages: 589824
> > > 	zone(0): 589824 pages.
> > > 
> > > 
> > > After:
> > > 	On node 0 totalpages: 65536
> > > 	zone(0): 65536 pages.
> > 
> > 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.

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Florian Lohoff wrote:

> 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;

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 05:39:40PM +0100, Maciej W. Rozycki wrote:

> > 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;
> 
>  It look reasonable but is it what was really intended?  You should ask
> the author or linux-kernel, I suppose. 

Which probably is Kanoj who is subscribed to this list.

  Ralf

Re: crash in __alloc_bootmem_core on SGI current cvs

[Kanoj Sarcar]

> 
> On Tue, Jan 16, 2001 at 05:39:40PM +0100, Maciej W. Rozycki wrote:
> 
> > > 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;
> > 
> >  It look reasonable but is it what was really intended?  You should ask
> > the author or linux-kernel, I suppose. 
> 
> Which probably is Kanoj who is subscribed to this list.
> 
>   Ralf
> 

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

Re: crash in __alloc_bootmem_core on SGI current cvs

[Kanoj Sarcar]

> 
> On Tue, Jan 16, 2001 at 05:39:40PM +0100, Maciej W. Rozycki wrote:
> 
> > > 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;
> > 
> >  It look reasonable but is it what was really intended?  You should ask
> > the author or linux-kernel, I suppose. 
> 
> Which probably is Kanoj who is subscribed to this list.
> 
>   Ralf
> 

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

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Florian Lohoff wrote:

> 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);

 That's about the correct fix.

> 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...

 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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

Hi,

 Here is the patch I mentioned earlier.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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;
 
-		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);
 
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

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Tue, Jan 16, 2001 at 05:01:15PM +0100, Maciej W. Rozycki wrote:
> 
>  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.
> 

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
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Tue, Jan 16, 2001 at 05:49:05PM +0100, Florian Lohoff wrote:
> On Tue, Jan 16, 2001 at 05:01:15PM +0100, Maciej W. Rozycki wrote:
> > 
> >  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.
> > 
> 
> Works
> 

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

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Florian Lohoff wrote:

> 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Florian Lohoff]

On Tue, Jan 16, 2001 at 08:52:40PM +0100, Maciej W. Rozycki wrote:
> On Tue, 16 Jan 2001, Florian Lohoff wrote:
> 
> > 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.

Works reliably afterwards ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ian Chilton]

Hello,

> mem=0x07800000@0x08800000

What will I use with 96MB RAM please ?


Is someone going to fix it so this param is not needed?
 

*Tootles off and posts to the news page @ http://linuxmips.ichilton.co.uk*


Bye for Now,

Ian

                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |        Proofread carefully to see if you any words out.         |
 \-----------------------------------------------------------------/

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Ian Chilton wrote:

> > mem=0x07800000@0x08800000
> 
> What will I use with 96MB RAM please ?

 "mem=0x05800000@0x08800000"?  Verify it with what is reported last by the
memory map.

> Is someone going to fix it so this param is not needed?

 I guess so.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ralf Baechle]

On Tue, Jan 16, 2001 at 04:55:34PM +0000, Ian Chilton wrote:

> Hello,
> 
> > mem=0x07800000@0x08800000
> 
> What will I use with 96MB RAM please ?
> 
> 
> Is someone going to fix it so this param is not needed?

Don't use mem= on an ARC machine.  The ARC firmware provides a usable way
to detect the installed amount of memory including memory used internally
by the firmware.  If you use mem= on an ARC machine you'll simply make
the kernel stomp over all this firmwar data with more or less random
results.

  Ralf

Re: crash in __alloc_bootmem_core on SGI current cvs

[Maciej W. Rozycki]

On Tue, 16 Jan 2001, Ralf Baechle wrote:

> Don't use mem= on an ARC machine.  The ARC firmware provides a usable way
> to detect the installed amount of memory including memory used internally
> by the firmware.  If you use mem= on an ARC machine you'll simply make
> the kernel stomp over all this firmwar data with more or less random
> results.

 Ralf, please do not depreciate the tool.  You should not use "mem=" 
blindly on any kind of machine or bad things will happen.  Whenever you
use "mem=", you need to have at least a bare idea which memory areas are
usable and which are not.  You wouldn't like to put a process in
framebuffer memory, for example, would you?  When used carefully "mem=" 
may be a valuable tool for development and debugging.  It's flexible
enough to specify multiple memory ranges and you may use decimal, octal
and hexadecimal notation, as well as suffixes for kilo and mega (or kibi
and mebi, actually).  It may be used as a workaround for unsupported
memory configurations or broken memory areas.

 That written, one wouldn't normally use "mem=" for a production system,
of course.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: crash in __alloc_bootmem_core on SGI current cvs

[tmaloney]

anyone know a source of monitor parts? i need two bezels(front pieces) for
two Sony GDM-20D11's.

thanks

-----Original Message-----
From: Ian Chilton [mailto:mailinglist@ichilton.co.uk]
Sent: Tuesday, January 16, 2001 11:56 AM
To: Ralf Baechle
Cc: macro@ds2.pg.gda.pl; linux-mips@oss.sgi.com
Subject: Re: crash in __alloc_bootmem_core on SGI current cvs


Hello,

> mem=0x07800000@0x08800000

What will I use with 96MB RAM please ?


Is someone going to fix it so this param is not needed?
 

*Tootles off and posts to the news page @ http://linuxmips.ichilton.co.uk*


Bye for Now,

Ian

                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |        Proofread carefully to see if you any words out.         |
 \-----------------------------------------------------------------/

Re: crash in __alloc_bootmem_core on SGI current cvs

[Ian Chilton]

Hello,

> anyone know a source of monitor parts? i need two bezels(front pieces) for

For starters, why ask this question under the heading " Re: crash in
__alloc_bootmem_core on SGI current cvs"

And secondary, I seem to recall you already posted this question. If
you didn't get an answer, it will be becasue no one knows. Posting the
same question again is just annoying and will not get you an answer if
you didn't the 1st time.


Bye for Now,

Ian

                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |        Proofread carefully to see if you any words out.         |
 \-----------------------------------------------------------------/