SV: [microblaze-uclinux] crash of PetaLinux RC3 (kernel 2.6)

["Jonas Lindblad" <Jonas.Lindblad@xxxxxxx>]

Hi again,

During further investigations of my problem I have observed the
following:

Introducing a high "background" interrupt load in the system by using a
timer I get the application/system to hang in a few seconds. The
application does not need to run communication over Ethernet, runnig
both endpoints on on the local interface yields the same result.

The Ethernet controller interrupt handler seems to be the only one in my
test system that executes with interrupts enabled.  
In handle_IRQ_event (kernel/irq/handle.c) interrupts are enabled before
the handler is called and then disabled before the function exits.
Checking the MSR[IE] his point (or later in __do_IRQ) sometimes
indicates that interrupts are still enabled. 

Softirq handling in local_bh_enable() and _local_bh_enable()) also
reports unexpected state of IE. The softirq BUG/WARNING has been
reported on this list some time ago, but I can't find any indication of
it being resolved.

So, is anyone else experiencing strange behaviour during high interrupt
load? Has anyone looked into the softirq BUG/WARNING?

Regards,
Jonas


>Hi, 
>
>I am seeing similar behaviour. 
>A simple test application receiving and sending UDP packages over
>Ethernet using the emac in fifo mode "hangs" after a few minutes. The
>task seems to be stuck on the rtid instruction of the "_interrupt"
>interrupt handling code (which contains "restore_context"). 
>The r14 register contains the address of the rtid instruction itself,
so
>the rtid keeps reloading the PC, pointing back to itself.
>Usually the rest of the system is still alive when this has occurred.
>Sometimes the IP stack is "deaf", transmission still works, and
incoming
>packages are counted by the emac driver but does not make it up trough
>the stack. Occasionally the whole system crashes.
>
>Does anyone have an idea what could be causing this? 
>
>Regards
>Jonas



>Hi,
>my user application which is heavily IRQ-driven kills Linux after a few
>minutes anywhere. The same one is rock-stable when using it with
kernel->2.4.
>
>I wanted to know where it crashed, so, in a first attempt, I did:
> xmd
> xload mhs system.mhs
> connect mb mdm
> rrd pc
>and can see it's 0x80001f2c. Next I checked the file
linux-2.6.x/System.map >and it's within restore_context which is at
0x80001ebc. The offset is 28 >bytes, so I suspect it crashed at "lwi
r12, r1, PT_R12".
>I do use the latest patches known from this thread
>http://www.itee.uq.edu.au/~listarch/microblaze->uclinux/archive/2007/07
/msg00027.html.
>
>Do you have an idea what to do now?
>
>Cheers, F@lk


___________________________
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/


___________________________
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/