On Mon, 21 Aug 2000, Andrei Petrov wrote:

> They both cleared, and I can break to ddb anytime I want. No console
> echo thou, shouldn't be I guess. -(.

If you can break into the console then zs interrupts are almost certainly
working.  If you do a `trace' once you break into ddb you should see a
`zsintr' or equivalent on the stack.

Back to the HME interrupt problem.

I'm surprised that it couldn't find `cpuinfo', but `cpus' should only
contain the primary cpu so it should be equivalent.

Go to the prom and `cd' to both the CPU nodes and do `.properties' to find
out what the `upa-portid' property is for each CPU.

To find out if/where the interrupts are getting lost you need to poke
around a bit in the PROM.  Do a `softint@ .' to see what pending softints
you have.  Network should be level 6, clocks should be 10 and 14, zs 12,
and SCSI 3, so look to see if bit 6 (counting from zero) is set.  If it
isn't then that means that interrupts probably are not getting through
from the SBus controller.

Next step is to look at the sysio register map in the U2P document or
sys/arch/sparc64/dev/sbusreg.h and locate the physical addresses of the
interrupt map, clear interrupt and interrupt diagnostic registers for the
HME card.  If it's on-board it should use the `ethernet' registers,
otherwise you need to look at the registers for the appropriate SBus
slot.  Use the offset in conjunction with the physical base address of the
sysio controller from the `reg' property to calculate the absolute
physical address of those registers.  Dump the contents of the interrupt
mapping register and interrupt diagnostic register with `<physical
address> 15 spacex@ .'  The two bits associated with that interrupt source
should be zero.  

If those bits are not clear, it means that the interrupt has been sent but
has not reached the CPU.  Check the contents of the interrupt mapping
register.  Bit 31 should be set to enable the interrupt source, and bits
29-25 should match that CPU's UPA address property.  If that is not
correct try updating the interrupt mapping register with `<new value>
<physical address> 15 spacex!' and verify the change.

If the interrupt diagnostic register bits are clear and the interrupt
mapping register looks correct, you can try to clear the associated clear
interrupt register to re-latch the interrupt.  Store a zero there then
re-check the interrupt diagnostic register.  The bits there should have
changed.  If not, the hme is probably not sending interrupts.

It is possible that there are some issues with the interrupt mapping code,
especially for SBus slots.

Eduardo Horvath