Re: [microblaze-uclinux] [PATCH] return from interrupt.

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Kennth,

Kenneth Johansson wrote:
> Well then you need to investigate more. The patch is correct and
> needed. 
>
> but If you have the same problem with the interrupt disable I have seen
> all sort of interesting things can happen.
>
> you could try to run with the attaches files
> arch/microblaze/kernel/entry.S
> include/asm-microblaze/system.h

This is interesting (and scary!) - your changes fix a problem I've been 
looking at (related to Falk's and Jonas's).  The patch is basically two 
things:

1. bracket every MSR write with nops
2. iterate enable/disable IRQ code to make sure it "sticks".

The problem I've been looking at relates to behaviour under very high 
IRQ loads (>10KHz timer interrupts), and these changes seem to fix that. 
 However, I have trouble thinking of a consistent theory for why this 
should be necessary.

The MB ref guide is a bit vague about the msr operations, it says there 
is a 1 cycle latency in settings or clearing bits, apart from the carry 
bit.  Nop-padding msr ops makes sense because and mts/msrset/msrclr 
immediately followed by mfs could result in the wrong value being 
returned.

However, it doesn't explain the irq enable/disable looping!

Is it a MicroBlaze bug/feature whereby an IRQ received in that 1 cycle 
latency window causes the interrupt to be taken?  Even if that were the 
case, the eventual RTID at the end of that handler should mean 
interrupts are disabled when execution resumes immediately following the 
msrclr instruction.

I'll leave this particular  system under test for a while, see if we get 
an eventual failure, but it's looking pretty solid right now.

Cheers,

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