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

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



John,
Doing some more MSR print in the setup_frame() in signal.c and the
applciation handler  i got this.

==================================================
 /* Signal handler args: */
   regs->gpr[GPR_ARG0] = signal; /* Arg 0: signum */
   regs->gpr[GPR_ARG1] = &frame->sc; /* arg 1: sigcontext */

  __asm__ __volatile__("mfs %0, rmsr; nop;" : "=r" (flags));

   printk ("inside do_signal: are 0x%08x\n", flags);
   regs->pc = ((unsigned long)ka->sa.sa_handler);
===================================================

and the output i got is this when i send  a packet burst..
=======================================================
inside setup_frame: are 0x000000aa
flags are 0x000000a2
inside setup_frame: are 0x000000aa
flags are 0x000000a2
inside setup_frame: are 0x000000aa
flags are 0x000000a2
inside setup_frame: are 0x000000aa
flags are 0x000000a2
inside setup_frame: are 0x000000a2
flags are 0x000000a2
inside setup_frame: are 0x000000aa
flags are 0x000000a0
inside setup_frame: are 0x000000aa
flags are 0x000000a0
==========================================================

This is when the weird results happen.

I am not sure whether this points to something significant to debug.
If so, please let me know what else i can debug.

thanx
- Prasad





On 11/16/06, Prasad <ndprasad@xxxxxxxxx> wrote:
John,
I applied this patch to entry.S and the linux hangs when it comes up...
 "Console: xmbserial on UARTLite
Calibrating delay loop..."

Does it work for you? Please let me know.

- Prasad

On 11/15/06, John Williams <jwilliams@xxxxxxxxxxxxxx> wrote:
> 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 */
>
>
>

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