5329EVB, LTIB and Kernel panics?

[jpa]

Anyone else getting spurious kernel panics with the 5329 and the latest LTIB?

By 'spurious',  I mean that the board is just sitting there with the busybox prompt, I'm off doing something else, and I come back and the board has locked with a kernel panic.  Networking is turned off in LTIB as far as I can tell, and I'm not running any user programs. 

This has happened 4-6 times with several different kernel configurations, including one that was based on the LTIB defaults minus microwindows, mp3play and play.

John

[mwaddel]

I didn't see behavior like that during development and I did leave it
running overnight on many occasions.  Any clues from the kernel
panic dump as to which area is causing the crash? 

You can use "m68k-uclinux-objdump -d vmlinux | less" and search
through the disassembled kernel for the sequence that's causing
the problem.

[jpa]

The board was kind enough to cooperate and repeat itself...

# *** ILLEGAL INSTRUCTION ***   FORMAT=4
Current process id is 0
BAD KERNEL TRAP: 00000000
PC: [<4001fcf4>]
SR: 2200  SP: 40208ed8  a2: 406a2360
d0: 00000000    d1: 00000100    d2: 00000000    d3: 00000000
d4: 00000068    d5: 02000000    a0: fc030000    a1: 401f284a
Process swapper (pid: 0, stackpage=401f384a)
Stack from 40208f0c:
        40002000 40103d22 00000000 00000000 00000068 00000000 00000000 00000000
        4069a640 4004224c 40042ce2 40027fa8 40208ff8 406a202a fc030000 4004227c
        00000068 406a2000 00000068 4069a640 00000000 401f6108 40042336 00000068
        4069a640 00000000 00000000 401ae4b0 402196fb 400ceab4 40020992 00000068
        00000000 40023b3a 00000068 40208f9c 4021a820 00000000 00000000 00000000
        00000000 40208008 401f284a 401ae4b0 00000000 ffffffff 00000000 41a02000
Call Trace:
        [<40020a84>] [<40020bb4>] [<400200e2>]
Kernel panic - not syncing: Aiee, killing interrupt handler!

[mwaddel]

Well, if my kernel addresses are the same as your's then it's crashing in
the _exit routine.  Looks like it's trying to jump back to the bootloader area
(0x4001fcf4), all the kernel code is in 0x40020000+.  Something could be
corrupting the stack or stepping on a register???

[jpa]

I'm not familiar with the utility you suggested, can you flesh this out a bit?  Where is the utility located?  I'm assuming I'm running this against my kernel image on my host, yes?  And that would be image.bin for me, not vmlinux, since I'm building a romfs flash image?

For what it's worth, I'm beginning to wonder if the kernel panic isn't related to my problems with USB hubs.  It's too early to tell, but the board seems suspiciously stable now that I've unplugged the hub so I can try other things. 

At the time of the panic, it was just sitting at a busybox prompt.  Would it be helpful to see a list of active processes from ps ?

John

[mwaddel]

> I'm not familiar with the utility you suggested, can you flesh this out a bit? 

m68k-uclinux-objdump is part of the gnu toolchain.  Documentation
on the standard objdump should help you understand most of the
options.  I believe "man objdump" should work.

> Where is the utility located? 

It's located in the toolchain.  For this bsp the toolchain installs at:
/opt/freescale/usr/local/gcc-4.2.47-uclibc-0.9.47/m68k-uclinux/bin/

> I'm assuming I'm running this against my kernel image on my host, yes?  And that
> would be image.bin for me, not vmlinux, since I'm building a romfs flash image?

Yes, you would run objdump against your built kernel on the host.  The
image.bin is just the kernel binary+romfs.img cat'd together.  Since the
problem is causing the kernel to crash you can look at the elf kernel that
is still on your host and get an idea of where it's failing.  Using the objdump
command you can see the kernel assembly code as it lays out in memory
starting at location 0x40020000 (this part of the image never changes, the
kernel will always be at this memory location).  There is a copy of the
kernel elf file located at <ltib>/rootfs/boot/vmlinux after a build.