[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] debugging kernel resource problems



Hi Rod,

On Thu, Jan 1, 2009 at 3:48 AM, Rod Campbell <rod@xxxxxxxxxxxxxxxxxx> wrote:
 
[snip]
 

I have a debug version that I normally use during development that is about 25% bigger than the prod app (around 250K).  I also often run programs from the serial console and ftp/telnet to monitor the system and download new app versions.  Lately I have noticed that the uClinux system will sometimes freeze up when I perform other activity with the debug app running.   Often there are no messages on the serial console, but sometimes I see "kernel BUG at buffer.c:xxxx" or "kernel BUG at slab.c:xxxx".

It would be helpful to know the xxxx line numbers here.  Take a look at the conditions in the BUG_ON() code at the appropriate files (will be in linux-2.4.x/mmnommu/*.c).

But, at first glance it doesn't sound like an out of memory condition.

 

I tried turning on kernel debugging code by adding options to uClinux-2.4.x/arch/microblaze/config.in, then selecting them during the make process.  This included:

 bool 'Debug kernel' CONFIG_DEBUG_KERNEL
 bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Debug slab' CONFIG_DEBUG_SLAB
 bool 'Debug stack oflow' CONFIG_DEBUG_STACKOVERFLOW
 bool 'Debug Highmem' CONFIG_DEBUG_HIGHMEM
 bool 'Debug Errors' CONFIG_DEBUG_ERRORS
 bool 'Add /proc/mem_map' CONFIG_MEM_MAP
 bool 'Debug spinlock (smp)' CONFIG_DEBUG_SPINLOCK
 bool 'Debug user' CONFIG_DEBUG_USER
 bool 'Debug frame pointer' CONFIG_FRAME_POINTER
 bool 'Debug I/O Virt' CONFIG_DEBUG_IOVIRT
 bool 'Debug Checking' CONFIG_CHECKING
 bool 'Verbose BUG msgs' CONFIG_DEBUG_BUGVERBOSE

When I turned all these on, the kernel image increased in size and I did see one change (cat /proc/slabinfo showed more columns), but I did not see any more diagnostic messages on the serial console when it booted up or when I caused the system to freeze.
Do I need to add something extra to another file somewhere to enable some of these debug parameters when the kernel is compiled?  Is there something else I could do to get memory statistics out of the kernel to see if this really is a memory resource issue?  Any advice would be appreciated.

A simple test, but try enabling the 'free' utility in busybox (and sleep if not already), you can then do something like this

# while [ 1 ]; do free; sleep 5; done

on an unloaded system, take a look at the memory behaviour.

Then, try it again on a loaded system, does anything interesting emerge?  ie downward trends in free memory over time.

Regards,

John