[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] Heavy packet load and the sigaction..



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/