Hello,

> Yeah, something is still awry with pci in current. On my Beige G3 I put 
> a StarFire card (64 bit PCI, PCI-PCI bridge with 4 ANA-62011's on it) 
> It sits in a 32 bit PCI slot since this machine doesn't have 64 bit 
> slots.
> 
> ppb0 at pci0 dev 15 function 0: Digital Equipment DC21154 PCI-PCI 
> bridge ( rev. 0x02)
> pci1 at ppb0 bus 1
> pci1: i/o space, memory space enabled
> sf0 at pci1 dev 4 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
> sf0: interrupting at irq 25
> sf0: Ethernet address 00:00:d1:xx:xx:xx
> sf0: 64-bit PCI slot detected
> sqphy0 at sf0 phy 1: seeq 80220 10/100 media interface, rev. 1
> sqphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf1 at pci1 dev 5 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
> sf1: interrupttrap: pid 0.1 (swapper): kernel MCHK trap @0x44f5c0 
> (SRR1=0x41030)
> panic: trap
> Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x10: lwz r0, r1, 0
> x14
> db> bt
> 0x00682220: at panic+0x19c
> 0x006822b0: at trap+0xfc
> 0x00682330: kernel MCHK trap by rasops_do_cursor+0x84: srr1=0x41030 
> r1=0x6823f0 cr=0x53ad9e55 xer=0xc000be6f ctr=0x2
> saved LR(0x70) is invalid.
> db>

Ouch.
Ok, some questions: is 25 the right IRQ for the slot? 

From one of your earlier posts:
ppb0 at pci0 dev 15 function 0: Digital Equipment DECchip 21154 PCI-PCI  
Bridge (rev. 0x02)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
sf0 at pci1 dev 4 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
pci_intr_map: no mapping for pin A
sf0: unable to map interrupt
sf1 at pci1 dev 5 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
pci_intr_map: no mapping for pin B
sf1: unable to map interrupt
sf2 at pci1 dev 6 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
pci_intr_map: no mapping for pin C
sf2: unable to map interrupt
sf3 at pci1 dev 7 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
pci_intr_map: no mapping for pin D
sf3: unable to map interrupt

so OF didn't configure interrupts, you apparently updated macppc/pci/pci_machdep.c, got a fix I'm sort of responsible for so fixpci() should have written the same IRQ number into each sf instance. Could you please compile a kernel from the same source as the one that paniced above, but without the sf driver and then post what scanpci -v thinks about them? ( in your earlier post they all had a 0 in the IRQ register, now all should have 25 )
Does it work with only a single sf instance? 

have fun
Michael