On Tue, 22 Aug 2000, Eduardo Horvath wrote:

> 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.


I just don't know what is a correct way so the story is:

I found cpuinfo only as
#define cpuinfo	(*(struct cpu_softc *)CPUINFO_VA)
in sparc64/cpuvar.h
and I had to include that to sbus.c
Then I got errors because sparc64/cache.h doesn't let you include it
twice and cpuvar.h includes it. 
Then I found that cpuinfo->ci_upaid has wrong syntax, I changed it to
cpuinfo.ci_upaid and found that cpu_softc doesn't have ci_upaid, so
I found cpus in cpu.h and I gave it a try.  


> 
> 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.
> 

got 4400, must be hex(?), looks like clocks only.

Havn't done the next yet.

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

Thank you for help,
	Andrey