more multiple dec21140 on ppc

[gregory.menke at gsfc.nasa.gov]

 > gregory.menke at gsfc.nasa.gov writes:
 >  > 
 >  > Till Straumann writes:
 >  >  > gregory.menke at gsfc.nasa.gov wrote:
 >  >  > > (sorry Till, I sent a copy to to alone by accident...)
 >  >  > > 
 >  >  > > 
 >  >  > > I'm still working on it and have little more to report except that its
 >  >  > > increasingly looking like something isn't quite configured right in
 >  >  > > MPIC or the PBC.  
 >  >  > > 
 >  >  > > Shifting the onboard dec to MPIC irq 2 (which its supposed to be wired
 >  >  > > to) causes it to stop receiving interrupts (and I am changing its
 >  >  > > INTERRUPT_LINE value to 2, with name = 18).  I've only been able to
 >  >  > > make the onboard dec operate under its ISA irq 10.
 >  >  > > 
 >  >  > 
 >  >  > Hmm - I cannot reproduce your problem on my mvme2306 board.
 >  >  > Here's what works (with both, the original dec21140.c and the
 >  >  > modified version you sent me a couple of days ago) on my board:
 >  > 

Sorry to keep posting, but I think I'm closing in on the problem.  Its
really looking like interrupts are not being delivered to the MPIC or
its not asserting them for some reason.  I confirmed the board is
working by pinging continuously on the onboard ethernet, then polling
both boards for status.  In that case, the cpci board delivers packets
to the stack and sends them as well.

However, I cannot get interrupts from the onboard ethernet when its
configured for MPIC irq 2 (irqname 18), nor from any of the 4 cpci
interrupt channels irq 8 thru 11 (irqname 24 thru 27).

Till, now I understand what you mean by not wanting a struct sockaddr
for interrupts, I just learned about the pci swizzle...  I agree with
you.

If I have the onboard ethernet on ISA 10, and the cpci board vectored
for service on all 4 cpci interrupt lines, with the onboard ethernet
pinging continuously, I will sometimes see MPIC irq 11 asserts.  It
seems like something is stopping the MPIC from receiving/servicing the
interrupts, possibly unless MPIC irq 0 is coincidentally being
signalled.  I wonder if it might be a subtle inservice/ack problem...

The MPIC registers all look OK however, this is a dump that shows all
4 cpci vectors set- this is in a more or less idle state.  I think I'm
going to poll the MPIC and see if I can find irq 11 in progress but
waiting.


OpenPIC Registers:
Global:
 FR0 000f0103
 FR1 00000000
 GC0 20000000
 GC1 00000000
 SV  00000063
 TF  007f28cf


Sources:
    0   Pri 00c80010   Dest 00000001
    1   Pri 80080011   Dest 00000001
    2   Pri 80080012   Dest 00000001
    3   Pri 80080013   Dest 00000001
    4   Pri 80080014   Dest 00000001
    5   Pri 80080015   Dest 00000001
    6   Pri 80080016   Dest 00000001
    7   Pri 80080017   Dest 00000001
    8   Pri 00080018   Dest 00000001
    9   Pri 00080019   Dest 00000001
   10   Pri 0008001a   Dest 00000001
   11   Pri 0008001b   Dest 00000001
   12   Pri 8008001c   Dest 00000001
   13   Pri 8008001d   Dest 00000001
   14   Pri 8008001e   Dest 00000001
   15   Pri 8008001f   Dest 00000001

Processors:
      Ctask 00000001   Iack 00000063
      Ctask 0000000f   Iack 00000063


As always, all comments welcome.  Thanks,

Gregm