Subject: early crash on indigo2 fix breaks indy ...

From: Florian Lohoff <[email-masked]>
Date: Mon, 24 Apr 2000 13:22:21 +0200

On Mon, Apr 24, 2000 at 03:49:21AM -0700, Ulf Carlsson wrote:
> > Modified files:
> > 	arch/mips/arc  : memory.c 
> > 
> > Log message:
> > 	Fix early crash on SGI_IP22 due to not reserving kernel
> > 	pages in the boomem setup
> 
> This breaks on my Indy.  What machine are you using?  Do we know whether the
> part of memory where the kernel is loaded is reported as free memory from the
> prom or should we add some tests?

Indigo2 - I had the problem that the first alloc_bootmem i think
got back pages in the kernel marked as "free" - The resulting memset
let the kernel crash. My solution was to mark the kernel pages
as reserved.

BTW: What does break on indy ? Does it crash ? Does it hang in SCSI Detection ?
The SCSI detection is a different thing - The problem is that the kernel
gets loaded in a area which is from the MAX_DMA_ADDRESS DMAable memory.
Afterwards no pages are left for DMA and the generic scsi layer is not
able to get dma able pages (from zone 0 GFP_DMA) which results in error
messages in the scsi layer. I solved this by changing mm/init.c
to put ALL pages into zone 0 as from my understanding the MAX_DMA_ADDRESS
is only aplicable to PC style DMA Controllers which the indy/indigo2 hopefully
dont have. For this patch i didnt apply to CVS nobody gave back 
and usefull comment.

Here is the fix i am using:

Index: init.c
===================================================================
RCS file: /cvs/linux/arch/mips/mm/init.c,v
retrieving revision 1.27
diff -u -r1.27 init.c
--- init.c	2000/02/23 01:33:56	1.27
+++ init.c	2000/04/24 11:29:51
@@ -256,13 +256,16 @@
 	max_dma = virt_to_phys((char *)MAX_DMA_ADDRESS) >> PAGE_SHIFT;
 	low = max_low_pfn;
 
+#if defined(CONFIG_ISA) || defined(CONFIG_PCI)
 	if (low < max_dma)
 		zones_size[ZONE_DMA] = low;
 	else {
 		zones_size[ZONE_DMA] = max_dma;
 		zones_size[ZONE_NORMAL] = low - max_dma;
 	}
-
+#else
+	zones_size[ZONE_DMA] = low;
+#endif
 	free_area_init(zones_size);
 }

Flo
-- 
Florian Lohoff		[email-masked]		      	+49-subject-2-change
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 24 Apr 2000 13:24:33 +0200

> > prom or should we add some tests?

BTW: allocating/preserving the pages twice (once per arc-prom and 
once afterwards shouldnt hurt at all.

Flo

---

From: Ulf Carlsson <[email-masked]>
Date: Mon, 24 Apr 2000 11:57:13 -0700 (PDT)

> BTW: What does break on indy ? Does it crash ? Does it hang in SCSI Detection ?

Yeah, I noted that it didn't make any difference to revert your change except
that the algorithm breaks and I get spammed with zillions of ``hm, page
already marked as reserved'' messages when we try to reserve the already
reserved memory.  Is it possible to detect this with the PROM version or
something?

Ulf

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 24 Apr 2000 21:09:41 +0200

> reserved memory.  Is it possible to detect this with the PROM version or

One might check if you walk through the memory table the
arc gives back and free it via the bootmem api you can check whether
you got back a memory chunk which contains the kernel (Or overlaps)
and realloc it after freeing or just not free it up. Should be obvious
and trivial after the change i made ...

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 26 Apr 2000 13:10:47 -0700

> and trivial after the change i made ...

I don't see why the kernel memory could ever be treated as free.  Initially
the entire memory is considered to be allocated.  Then all areas that are
free as per ARC(S) firmware get freed.  The kernel itself should of course
not be part of those areas.  Then even later once again as part of
free_initmem() the rest of the ARC(S) memory gets freed, that's all the
firmware temporary areas.  Again the kernel memory should not reside in
any of those areas.  So I can't make any sense out of your changes?

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Fri, 28 Apr 2000 09:16:46 +0200

> any of those areas.  So I can't make any sense out of your changes?

The problem i seen on MY indigo2 is that i get a memory chunk from
the ARC which is freed up although the kernel resides in that memory
chunk. The first allocation of memory (still in the bootmem) 
then gets kernel pages - does a "memset" and dead we are.

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 28 Apr 2000 01:52:28 -0700

> then gets kernel pages - does a "memset" and dead we are.

In that case I suggest you enable the define DEBUG near the top of
arch/mips/arc/memory.c and take a closer look at the printout.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Fri, 28 Apr 2000 11:18:35 +0200

> arch/mips/arc/memory.c and take a closer look at the printout.

I did that - And i also included a lot more debugging myself. I also
mailed to output to the list but nobody seemed able to help - So i
fixed it myself ...

Flo