Hi

>On first glance this looks like an interrupt routing issue. Either
>interrupts are not enabled ( unlikely I think ) or they aren't signalled
>where the kernel expects them.
>  
>
hm i compare the dmesg of OpenBSD with the one of NetBSD.
Everything seems to be identical apart to one issue.
While the hme0 has the same ivec

OpenBSD:
hme0: using ivec 3021 for interrupt
NetBSD:
hme0: interrupting at ivec 3021

the esiop has a diffrent one!

OpenBSD:
siop0 at pci0 dev 3 function 0 vendor 0x1000 product 0x000f rev 0x14: 
ivec 1820, using 4K of on-board RAM
NetBSD:
esiop0 at pci0 dev 3 function 0: Symbios Logic 53c875 (ultra-wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at ivec 20

>Did you try a -current kernel? Blade 1x0 systems have similar problems (
>depending on firmware, newer revisions apparently encode interrupt
>information in a different way ) - I'm not sure if anyone fixed it.
>
>  
>
no because i have no working SPARC64 - installation atm.
But i poking a little bit inside the interrupt handling of both 
implementations
and found a issue in the OpenBSD version of pci_intr_map

if (pa->pa_pc->intr_map)
    return ((*pa->pa_pc->intr_map)(pa, ihp));
else
    return (0);

it looks like that they try to track down a diffrent interrupt for the 
chip of the siop?!

Best Regards