[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Microblaze system freeze
Hi Michal !
I'm not sure if I was clear enough initially. The board does boot properly w/o any problems. Its when I start my test-application things turn sour. The following lines of code is present in my app
printf("%s %s %d Before sem_post\r\n", __FILE__, __FUNCTION__, __LINE__);
error=sem_post(&timerSemId);
printf("%s %s %d After sem_post\r\n", __FILE__, __FUNCTION__, __LINE__);
If I remove the printf-statements, the program will stop/freeze. But the kernel seems to survive (Ctrl+C stops the program, can still ping etc). If I keep the printf statements the entire system goes dead. (Control+C does nothing, ping is dead)....
In both cases the program runs for a while (10min +) before trouble arrives...
Is this a case where I should upgrade every thing go the latest and hope for the best, or are there band-aids ..?
Thanks for all your help !
/Otto
On 5/15/08, Michal Simek <monstr@xxxxxxxxx> wrote:
Hi Otto,
> Hi F@lk <mailto:F@lk> and Michal !
>
> Thanks for your help ! Here is what the registers look like
>
> XMD% rr
> r0: 00000000 r8: 27fd5780 r16: 00000000 r24: 00000002
> r1: 2420dfa0 r9: 24226070 r17: 00000000 r25: 00000000
> r2: 241fc000 r10: 000056ba r18: 00000081 r26: 27fd9770
> r3: 00010000 r11: 2420c030 r19: 2420c000 r27: 27fdd0e4
> r4: 2420c000 r12: 000000a0 r20: 00000000 r28: 24000000
> r5: 24220664 r13: 2420e000 r21: 00000000 r29: 27f6023f
> r6: 2420c000 r14: 2400101c r22: 00000000 r30: 27fdd0e4
> r7: 88fe8c80 r15: 24001030 r23: 27f3fe28 r31: 241fc2a8
> pc: 24001020 msr: 000000a2
>
> So, the program counter is 24001020. I tried this multiple times and it
> hangs at the same place.
Turn on heartbeat function for kernel -> arch/microblaze/kernel/heartbeat.c ->
add your gpio led address and recompile -> You will see if your kernel work ->
blinking led like heart.:-)
> Looking in the system.map file we have
>
> ------
> 24000d10 T show_trace
> 24000dd4 T show_stack
> 24000edc T dump_stack
> 24000efc T show_regs
> 24000ff4 T cpu_idle
> 2400103c T flush_thread
> 24001044 T copy_thread
> 24001108 T thread_saved_pc
> 24001158 t kernel_thread_helper
> -----
>
> So I take it we are stuck in cpu_idle ...?
>
> Also, I checked the __log_buf
>
> ------
> XMD% mrd 0x24226E00 100
> 24226E00: 3C353E4C
> 24226E04: 696E7578
> 24226E08: 20766572
> 24226E0C: 73696F6E
> 24226E10: 20322E36
> 24226E14: 2E32302D
> 24226E18: 75633020
> 24226E1C: 286F7474
> 24226E20: 6F62406C
> 24226E24: 6F63616C
> -----
>
> and it reads "<5>Linux version 2.6 ......" etc. I'm not quite sure what
> to look for here ..?
That what I write in previous email. For showing __log_buf is better to use
U-BOOT because U-BOOT provides you conversion from your hex code to
messages(only decode). That's is really important because you have to in which
stage of booting you are. You can debug it and find the way.
You can increase size of kernel log buf -> menuconfig option to max value (17).
And you can change loglevel but I don't remember where is it ->
include/linux/kernel.h can be good start and google as well.
> I dumped VmLinux (using microblaze-uclinux-objdump -xDSl
> ./linux-2.6.x-petalogix/vmlinux)
> -------------------------------
> 24000ff4 <cpu_idle>:
> cpu_idle():
> 24000ff4: 3021ffe0 addik r1, r1, -32
> 24000ff8: fa61001c swi r19, r1, 28
> 24000ffc: f9e10000 swi r15, r1, 0
> 24001000: a661e000 andi r19, r1, -8192
> 24001004: 94910002 msrclr r4, 2
> 24001008: e8730008 lwi r3, r19, 8
> 2400100c: b0000001 imm 1
> 24001010: a0630000 ori r3, r3, 0
> 24001014: f8730008 swi r3, r19, 8
> 24001018: 9404c001 mts rmsr, r4
> 2400101c: e8730008 lwi r3, r19, 8
> 24001020: 64630003 bsrli r3, r3, 3
> 24001024: a4630001 andi r3, r3, 1
> 24001028: bc03fff4 beqi r3, -12 // 2400101c
> 2400102c: b000001b imm 27
> 24001030: b9f483e8 brlid r15, -31768 // 241b9418
> <schedule>
> 24001034: 80000000 or r0, r0, r0
> 24001038: b800ffe4 bri -28 // 2400101c
> -------------------------------
>
> So, from here it looks like we got stuck on an "andi" instruction ..?
> Sounds innocent.
Yes - because your kernel is cheating you. That's normal. Welcome to my world.:-)
>>Do you mean you can't ping your board? or only you can't see console
> output?
>
> Can't ping or see any console output. No characters are echoed.
Heartbeat tells you if your kernel is dead in first stage.
> So this is an exiting investigation and all, but... anyone has any ideas
> on what to do now ?
>
> Help, cheering or other kind words appreciated ! ;)
Regards,
Michal Simek
>
> Thanks
>
> /Otto
> On 5/14/08, *Brettschneider Falk* <fbrettschneider@xxxxxxxxxxxxxxx
> <mailto:fbrettschneider@xxxxxxxxxxxxxxx>> wrote:
>
> kernel 2.4 or 2.6?
>
> If your FPGA firmware includes the MDM module, you can connect to it
> via JTAG with the program 'xmd' and read out the current program
> counter address with 'rr pc'. You find the appropriate function in
> the System.map file of the compiled Linux kernel.
>
> CU, F@lk
>
> Otto Blomqvist wrote:
> > I have a multi-threaded test-application that continuously
> > calls setitimer / getitimer along with calls to sem_lock and
> > sem_release. A regular application freeze wouldn't surprise
> > me a whole lot, but the problem is that the entire system freezes.
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> <mailto:microblaze-uclinux@xxxxxxxxxxxxxx>
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
>
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/