Boot failure on linux 2.6.25, 547x_8x BSP

[Dave_SC]

Hi Folks,

I am getting a failure during the boot process of linux-2.6.25.  I think that the failure begins at the following line:
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: -520210

where the Total pages returned is a negative number.   Does anyone know what would be wrong to get a negative number of pages?  My board has 32MB of SDRAM and 8MB of flash.  I have attempted to add some debug prints to show initialization values.

The boot continues, but as soon as a memory allocation is attempted, the kernel dies. 
See the kernel boot output below:

Linux version 2.6.25 (user@local) (gcc version 4.2.3 (Sourcery G++ Lite 4.2-125)) #74 Wed Jan 21 12:49:28 PST 2009                                                             
starting up linux startmem 0x286000, endmem 0x2000000,          size 29MB
init_bootmem_node x page_start 323, pa_base 0, page_end 4095
coldfire_bootmem_alloc bootmap_size 512
coldfire_bootmem_alloc availmem 2646528
coldfire_bootmem_alloc PAGE_ALIGN(availmem) 2654208
coldfire_bootmem_alloc num_pages 4096, mem_start 2646016, memory_end 33546240
coldfire_bootmem_alloc base_pfn 0, min_low_pfn 323,  max_low_pfn 4095
free_bootmem __pa(availmem) 2654208, freebytes 30892032
console [ttyS0] enabled
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: -520210
Kernel command line: console=ttyS0,19200
start_kernel(): pidhash_init()
PID hash table entries: 4096 (order: 12, 16384 bytes)
start_kernel(): console_init()
Console: colour dummy device 80x25
start_kernel(): vfs_caches_init_early()
__alloc_bootmem_core(): zero-sized request
kernel BUG at mm/bootmem.c:215!
*** ILLEGAL INSTRUCTION ***   FORMAT=4
Current process id is 0
BAD KERNEL TRAP: 00000000
PC: [<0024b076>] __alloc_bootmem_core+0x2c6/0x4ba<0>
SR: 2000  SP: 00259eb4  a2: 00232414
d0: 00000023    d1: fffff9a0    d2: 00000000    d3: 00000010
d4: 00000000    d5: 00000000    a0: f000860c    a1: 00233b00
Process swapper (pid: 0, stackpage=00234414)
Stack from 00259eb4:
       <0> fffff9a0<0> 00000000<0> 00000010<0> 00000000<0> 00000000<0> f000860c<0> 00233b00<0> 00232414
       <0> 00000023<0> ffffffff<0> 00000000<0> 10000803<0> 00000000<0> 40102000<0> 0024b076<0> 001ffcb7
       <0> 00205856<0> 000000d7<0> 00205863<0> 00000000<0> 00000010<0> 00000000<0> 00000000<0> ffffffff
       <0> 00000001<0> 00254e1e<0> 0024adb0<0> 0003298e<0> 00259fb4<0> 0000002b<0> 00259f86<0> f000860c
       <0> 00233b00<0> 00232414<0> 0024b360<0> 00254e06<0> 00000000<0> 00000010<0> 00000000<0> 00000000
       <0> 0000007f<0> fc07f700<0> 00000000<0> 00000004<0> 00031fa0<0> 0024b3a4<0> 00000000<0> 00000010
Call Trace:
       <0> [<0000d33e>]<0> [<0000d33e>]<0> [<0000d33e>]<0> [<00005dbc>]
Kernel panic - not syncing: Attempted to kill the idle task!

[truregs]

Hi,

The size allocated to DMA zone is fixed to 32Mo (arch/m68k/mm/cf-mmu.c)

so the "normal" zone ( which is total RAM - DMA ) becomes negative

changing this size  allows booting to go forth ( I still have a rootfs problem, so I don't know yet the side effects ) 

[truregs]

ok

I simply misspelled the  flash mapping space in my command line ( I'm using colilo)

using "physmap-flash.0"  instead of old "phys_mapped_flash" did it

I allocated 16Mo to DMA (and  thus 16 to Normal zone) 

[Dave_SC]

Can you show me a snippet of the lines of code you changed, please??

[truregs]

Here it is :

(from arch/m68k/mm/cf-mmu.c)

 --- cf-mmu.c    2009-04-17 12:27:19.101646700 +0200
+++ arch/m68k/mm/cf-mmu.c       2009-04-15 09:00:24.757896700 +0200
@@ -130,7 +130,7 @@
        /* allocate the bottom 32M (0x40x 0x41x) to DMA - head.S marks them NO CACHE */
        /* JKM - this should be changed to allocate from the TOP (0x4f,0x4e) but the
         * allocator is being a bit challenging */
-        zones_size[ZONE_DMA] = (32*1024*1024) >> PAGE_SHIFT;
+        zones_size[ZONE_DMA] = (16*1024*1024) >> PAGE_SHIFT;

        /* allocate the rest to NORMAL - head.S marks them CACHE */
        zones_size[ZONE_NORMAL] = (((unsigned long)high_memory - PAGE_OFFSET) >> PAGE_SHIFT) - zones_size[0]; 

 

I'm working on the base distribution ( from Freescale 08/08/2008 ) and just try to evaluate which effort it would be to switch to 2.6.25 kernel.

I did not take the latest patches from gpp  where this line  has been changed, 

(linux-2.6.25-m5445x-dma-mem-alloc.patch) because this patch allocates a 16MB page (so it is 5444x related) and is tied to changes I don't have time to figure out what they may results in yet.

but the change itself is much cleaner :

-    /* allocate the bottom 32M (0x40x 0x41x) to DMA - head.S marks them NO CACHE */
-    /* JKM - this should be changed to allocate from the TOP (0x4f,0x4e) but the
-     * allocator is being a bit challenging */
-        zones_size[ZONE_DMA] = (32*1024*1024) >> PAGE_SHIFT;
-
-    /* allocate the rest to NORMAL - head.S marks them CACHE */
-    zones_size[ZONE_NORMAL] = (((unsigned long)high_memory - PAGE_OFFSET) >> PAGE_SHIFT) - zones_size[0];
-
+    zones_size[ZONE_DMA] = CONFIG_DMA_SIZE >> PAGE_SHIFT;
+    zones_size[ZONE_NORMAL] = (((unsigned long)high_memory -
+                    PAGE_OFFSET) >> PAGE_SHIFT) -
+                   zones_size[ZONE_DMA];

 but is tied to CONFIG_DMA_SIZE which turn to modify code in early startup ( and Kconfig )...and digging GPP patches feds me up.

I could'nt find  the kernel-2.6.25-mcfv4e.spec.in containing this patch anywhere. 

Could you tell me which environment you're working with?

Thanks,