Re: [U-Boot] MPC8xx malloc failing

Hi
I have moved onto 2009.11, though more new versions are available but still .. I am using a MPC8XX based board( as earlier), but now the code is crashing in env_relocate() function. On applying debug prints I found that the code was failing in malloc with a Bus Fault with the following dump -
Bus Fault @ 0x00fc9988, fixup 0x00000000 Machine check in kernel mode. Caused by (from msr): regs 00f42e20 Unknown values in msr NIP: 00FC9988 XER: 20002D10 LR: 00FC9988 REGS: 00f42e20 TRAP: 0200 DAR: 7D8C6218 MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00FC9988 00F42F10 00F42F90 00000000 00FEC4AC 00F42B10 00000000 00000000 GPR08: 00000020 02202800 B060C000 00000020 82C00428 090700D8 00FFE400 FDFC7000 GPR16: 00019040 000448D1 045744A8 02420830 01A400E2 00000001 0074832A 00000000 GPR24: 00F42F90 00F42F78 00004008 00000072 00FF81E4 B0610008 00FFE424 7D8C6214 Call backtrace: 00FC9988 00FDCD34 00FCCD60 00FC93B8 machine check ### ERROR ### Please RESET the board ###
Help Required. Thanks Saugat.
On Mon, Jan 24, 2011 at 6:16 PM, Stefano Babic sbabic@denx.de wrote:
On 01/24/2011 01:12 PM, saugat mitra wrote:
Hi
Hi,
I am trying to boot a MPC8XXX based board using uboot version 1.1.3. I am able to get the serial console up. But when I try to ping it gives me a time out error. On trying "mii info" and enabling debug messages I see that all the mii read messages are returning 0xffff. Could any one please suggest me steps to debug.
make yourself a favour and upgrade to last U-Boot version. Your version is so ancient that is impossible to find which is the fix for you. And on current release, ethernet works well on mpc8xx (tested on a TQ tqm860L board).
Best regards, Stefano Babic
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Dear saugat mitra,
In message AANLkTi=SOo3RaVp8asHBRUYnOq4TTC_F07Miz3WrKRKT@mail.gmail.com you wrote:
I have moved onto 2009.11, though more new versions are available but still ..
Stefano wrote:
| > make yourself a favour and upgrade to last U-Boot version...
Can you please explain why you stick again with code that is > 1 year old?
I am using a MPC8XX based board( as earlier), but now the code is crashing in env_relocate() function. On applying debug prints I found that the code was failing in malloc with a Bus Fault with the following dump -
It would have been easier if you had just decoded the backtrace:
Call backtrace: 00FC9988 00FDCD34 00FCCD60 00FC93B8 machine check
Which routines are these addresses from?
Best regards,
Wolfgang Denk

Hi Wolfgang
The project was started more than a year back and that time 2009.11 was the latest version, so we are still continuing with the same. On running the back trace I found that functions to be called were from - malloc env_relocate board_init_r trap_init
To be more precise the code was dying while in the following loop from the function malloc() in dlmalloc.c. It executes the loop twice before crashing.
for (victim = last(bin); victim != bin; victim = victim->bk) { victim_size = chunksize(victim); remainder_size = victim_size - nb; if (remainder_size >= (long)MINSIZE) /* too big */ {
--idx; /* adjust to rescan below after checking last remainder */ break; }
else if (remainder_size >= 0) /* exact fit */ { unlink(victim, bck, fwd); set_inuse_bit_at_offset(victim, victim_size); check_malloced_chunk(victim, nb); return chunk2mem(victim); }
}
Also when I removed a few print(debug) statements the backtrace gave the first function to be puts instead of malloc, other functions were the same as earlier.
cpu is mpc8xx.
Thanks & Regards Saugat.
On Tue, Feb 1, 2011 at 6:59 PM, Wolfgang Denk wd@denx.de wrote:
Dear saugat mitra,
In message AANLkTi=SOo3RaVp8asHBRUYnOq4TTC_F07Miz3WrKRKT@mail.gmail.com you wrote:
I have moved onto 2009.11, though more new versions are available but still ..
Stefano wrote:
| > make yourself a favour and upgrade to last U-Boot version...
Can you please explain why you stick again with code that is > 1 year old?
I am using a MPC8XX based board( as earlier), but now the code is crashing in env_relocate() function. On applying debug prints I found that the code was failing in malloc with a Bus Fault with the following dump -
It would have been easier if you had just decoded the backtrace:
Call backtrace: 00FC9988 00FDCD34 00FCCD60 00FC93B8 machine check
Which routines are these addresses from?
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de In C we had to code our own bugs, in C++ we can inherit them.

Dear saugat mitra,
In message AANLkTinLdpASkBPhJ+EYG6rtvEeixtH7x8dydHQBATVF@mail.gmail.com you wrote:
The project was started more than a year back and that time 2009.11 was the latest version, so we are still continuing with the same.
I can imagine that you dislike this, but you are learning a lesson the hard way now. If you have to maintain your software for more than a few months (which usually applies only to few fast-living, high volume consumer devices) it is usually a good investment to push your changes upstream so they get included into mainline code, and the community does most of the maintenance work for you. You did not, so now you have to allthe work needed to bring your code back in sync with mainline yourself.
On running the back trace I found that functions to be called were from - malloc env_relocate board_init_r trap_init
To be more precise the code was dying while in the following loop from the function malloc() in dlmalloc.c. It executes the loop twice before crashing.
This is definitely not the place where the problem is. The problem happened earlier, and you see only the results of earlier failures here.
But we don't know your code, nor your configuration... And digging down into old code is not exactly interesting either, at least not in the context of free community work.
I recommend you update, and then you post your patches. The review process might catch a problem or two.
Best regards,
Wolfgang Denk
participants (2)
-
saugat mitra
-
Wolfgang Denk