Hi Dave,
Dave Meador wrote:
Greg Ungerer wrote:
Dave Meador wrote:
I am stuck on a bug at bootup in kmem_cache_init(). Trying to tweak
the uClinux-20080808 w/ 20090312 patch to boot on a 547x coldfire
board. Upon attempt to "Init caches for array cache kmem_list3" the
kernel panics upon running check_slabp() with the following error:
slab: Internal list corruption detected in cache 'kmem_cache'(27),
slabp 01c00000(0). Hexdump:...
I ran into a similar bug when using slub allocator, so I switched to
slab and still get a crash in kmem_cache_init. Any help to resolve
this would be greatly appreciated. Does anyone have any ideas on why
I would be running into Internal list corruption?
Thanks,
-Dave
uClinux boot output:
---------------------snip---------------------snip---------------------snip---------------------snip---------------------
Linux version 2.6.26-uc0-svn29-dirty17 (x...@yyy) (gcc version 4.3.2
(Sourcery G++ Lite 4.3-45) ) #60 Thu Apr 16 15:09:49 PDT
2009
uClinux/COLDFIRE(m547x)
^^^^^
I am a little confused by this. There is no native 547x support in
the linux-2.6.x kernels in uClinux-dist-20080808 and later. They
won't report an m527x CPU type here...
Have you made changes to the code here?
(Note that the linux-2.4.x kernels in those source packages did
have native 547x support).
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
KERNEL -> TEXT=0x002000-0x135bac DATA=0x135bac-0x143000
^^^^^^^^
That seems like an unusually low address to start at on a
ColdFire dev board. Are you sure that is right?
(Most of the Freescale dev board start at offset 0x20000 into
RAM, some older ones at 0x10000 offset).
Maybe I need to take a step back :-)
Is this a Freescale dev board, or something else?
Yes, it is a Freescale dev board... I did change the address in the
vmlinux.ld from 0x20000 to 0x2000. My loader is placed near the end of
ram and then jumps to the kernel start address. Correct me if I am
wrong, but I think that once the jump to kernel start occurs, the memory
that the loader occupies can be reused.
Yep, that is right. It is safe to use that memory after starting the
kernel proper.
I was trying to conserve ram.
But that is the least of my worries at the moment. Sorry for the
unaligned log listing... something went wrong with my cut-n-paste.
:-)
The biggest problem I see in the linux-2.6.x code is that it doesn't
have the native 547x code that the linux-2.4.x code had...
Anyway, for this type of memory setup/init problems the most usual
cause I have seen is bad processor cache setup. Do you have the
processor cache enabled?
Regards
Greg
BSS=0x152000-0x15d070
start_mem is
0xf84000
virtual_end is
0x2000000 before
free_area_init
free_area_init -> start_mem is
0xf84000 virtual_end is
0x2000000 On node
0 totalpages: 8192
DMA zone: 64 pages used for
memmap DMA zone: 0 pages
reserved DMA zone:
8128 pages, LIFO batch:0
Normal zone: 0 pages used for
memmap Movable zone: 0 pages
used for memmap Built 1 zonelists
in Zone order, mobility grouping on. Total pages: 8128 Kernel
command line: console=ttyS0,19200 debug
PID hash table entries: 128 (order: 7, 512
bytes) console [ttyS0]
enabled Dentry
cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
mem_init()
Mem_init: start=f84000, end=2000000
Mem_init: enter start=f84000, end=2000000
Mem_init: free_bootmem
Mem_init: free_all_bootmem
free_all_bootmem_core( pgdat = 0x13beb8 )
free_all_bootmem_core: __free_pages_bootmem( pages... )
Mem_init: free_all_bootmem done
Mem_init: nr_free_pages() = 16982016
Memory available: 16584k/32768k RAM, (1230k kernel code, 157k data)
kmem_cache_init()
kmem_cache_init: kmem_list3_init
kmem_cache_init: set_up_list3s
kmem_cache_init: set_up_list3s done
kmem_cache_init: cache_estimate
kmem_cache_init: cache_estimate done
kmem_cache_init: Init caches for array cache kmem_list3
slab: Internal list corruption detected in cache 'kmem_cache'(27),
slabp 01c00000(0). Hexdump:
000: 00 15 0b 1a 00 15 0b 1a 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
080: 00 00 00 00 00 00
BUG: failure at mm/slab.c:2997/check_slabp()!
Kernel panic - not syncing: BUG!
---------------------snip---------------------snip---------------------snip---------------------snip---------------------
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
