Prasad,
Can you please try the attached patch to entry.S, and let me know if it
has any impact?
Thanks
John
Prasad wrote:
> John,
> Bingo....when the program starts, the sighandler prints msr as 0xa2
> (which is interrupts enabled). As soon as i starts flooding the
> packet, it starts printing as 0xa0. Even when i stop the packet
> flooding, it still prints it as 0xa0. So when i kill the test program
> and restart it, it shows as 0xa2 again.
>
> I can repeat this again. It prints "count" properly.
>
> Any other thing that u want me to test, please let me know (i just
> came from my work..and i logged into our vpn to test it. So i cannot
> observe thro scope until tomorrow morning.)
>
> thanx
> - dp
>
> On 11/15/06, John Williams <jwilliams@xxxxxxxxxxxxxx> wrote:
>
>> Hi Prasad,
>>
>> Hmm, this is interesting. A couple of questions
>>
>> 1. Does the 1 or 2 msec delay of the timer interrupt occur only around
>> the time when your sighandler runs (e.g. about once per second)?
>>
>> 2. Can you modify your signal handler to create a really long delay
>> loop, and print out the contents of the MSR? Something like this should
>> be fine
>>
>> void signalhandler(int signum)
>> {
>> int flags;
>> int count;
>>
>> __asm__ __volatile__ ("mfs %0, rmsr;nop;" : "=r" (flags));
>>
>> printf("flags are 0x%08x\n",flags);
>>
>> while(count=0;count<100000000; count++)
>> ;
>>
>> printf("count is %i\n",count);
>> }
>>
>> Does this long delay loop block interrupts in your system until after
>> the sighndler terminates?
>>
>> There are two conditions under which interrupst will be blocked - one is
>> if the BIP bit is set (break in progress), the other is if interrupts
>> are disabled (EIP bit is cleared).
>>
>> The execution path from the kernel out to the sighandler is somehow
>> managing to leave kernel mode with interrupts disabled (or BIP set).
>>
>> Let's find out which, and that will help to discover how it's happening
>> in the first place. Since you see this only with high IRQ load, my
>> suspicion is the path whereby a sighandler can be executed on the back
>> of an interrupt.
>>
>> Cheers,
>>
>> John
>>
>>
>> Prasad wrote:
>> > John,
>> > I found signal related issue under lots of ethernet packet (typically
>> > in the order of 400 packets or more). I found that timer interrupt is
>> > not scheduled properly under heavy loads. So hooked up timer_irq,
>> > ethernet_irq, uart_irq to the logic-analyzer and figured out it is
>> > getting delayed processing for some strange reason.
>> >
>> > It turns out to be related with the sigaction routines. To prove that
>> > i wrote a test send and receive routine that worked fine normally
>> > (under heavy packet load). As soon as i add a sigaction to call a
>> > function every one sec, i see interrupt to the microblaze getting
>> > blocked (in the order of 1 or two msecs or even more) sometimes. I
>> > could see the timer interrupt getting delayed. I see that my test
>> > process runs during that time and the interrupt is disabled when it
>> > runs (which can never happen).
>> >
>> > As soon as disable the sigaction, everything comes back to normal.
>> >
>> > Just wondering which can disable the interrupt but allow the process
>> > to get scheduled. Seems very strange. I am continuing my debugging on
>> > this and will post as soon as i get something new.
>> >
>> > Meanwhile, any pointers regarding this is appreciated.
>> >
>> > Thanx
>> > - Prasad
>> > ___________________________
>> > 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/
>>
>>
> ___________________________
> 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/
>
>
? entry-test.diff
Index: entry.S
===================================================================
RCS file: /var/cvs/uClinux-2.4.x/arch/microblaze/kernel/entry.S,v
retrieving revision 1.20
diff -u -b -B -w -p -r1.20 entry.S
--- entry.S 5 Sep 2006 23:31:09 -0000 1.20
+++ entry.S 16 Nov 2006 05:58:34 -0000
@@ -233,9 +233,13 @@
mts r ## reg , clobber;
/* Save processor status word into saved state frame
- Uses r{clobber} as a clobber register */
+ Uses r{clobber} as a clobber register.
+ Hack - clear BIP and EI on the way in, we'll force all returns
+ as rtid so that interrupts are re-enabled on the way out */
#define SAVE_PSW(clobber) \
- SAVE_SPECIAL(msr,PSW,clobber)
+ mfs clobber, rmsr; \
+ andi clobber, clobber, ~0x0a; // Forced clear BIP and EI \
+ swi clobber, r1, PTO+PT_PSW;
/* Restore processor status word from saved state frame
Uses r{clobber} as a clobber register */
@@ -550,17 +554,17 @@
nop; /* Delay slot */
/* Instructions to return from a trap */
-/* Note we use rtbd to clear BIP bit on way out */
+/* Note we use rtid since BIP was cleared on the way in by state save */
/* Return offset is zero, because we incremented r14 on the way in */
#define TRAP_RETURN_INST \
- rtbd r14, 0; /* r14 used as trap link register */ \
+ rtid r14, 0; /* r14 used as trap link register */ \
nop;
/* Instructions to return from a debug trap */
/* Note we use rtbd to clear BIP bit on exit */
/* Return offset is zero, to ensure trapped instruction is re-executed */
#define DBTRAP_RETURN_INST \
- rtbd r14, 0; /* r14 used as trap link register */ \
+ rtid r14, 0; /* r14 used as trap link register */ \
nop;
/* Code fragment to return from NMI */