Hello,

>  From the land of the inexplicable, I rebooted, same kernel, and it 
> worked!
Now that's weird. It seems to have paniced in establish_intr() or something related...

> I should have clarified better, the can't map IRQ dmesg was from 2.0, 
Thought so, it certainly didn't have the PCI-bridge fixes Allen committed a couple of days ago.

> so then I built a current kernel from todays sources with no 
> patches applied and that's what the panic and now, non-panic is from. 
Ok, so the bridge-fix works for you - wasn't sure if it handles 64bit PCI correctly but apparently it does :)

> Since I should know better than not posting full dmesgs by now, here's 
> the whole thing. IRQ 25 seems to be correct as slot 1 is 23 and slot 2 
> is 24. It looks like it probes everything fine. The starfire nic's 
> won't send packets though, tcpdump shows data coming in off the wire, 
> and ifconfig -i shows packet counters incrementing in both directions. 
> So nothing wrong with the pci code for me, keep up the good work! Sorry 
> for the noise!
Hmm, what kind of interrupt controller does the G3 have? Apple's Grand Central or an OpenPIC? Since there are IRQs above 31 in your dmesg I'd assume it's an OpenPIC so the interrupt code fixes won't affect you.
Besides that there seems to be something wrong with the OpenPIC code too - my iBook seems to lose interrupts, just like the S900 used to before the patch. Well, not quite as bad and it's still only a suspicion but looking at it can't hurt.

> NetBSD 2.99.11 (GENERIC) #0: Mon Dec 13 22:55:16 EST 2004
> 	root@blah:/usr/current/src/sys/arch/macppc/compile/obj/GENERIC
> total memory = 384 MB
> avail memory = 364 MB
> mainbus0 (root)
> cpu0 at mainbus0: 750 (Revision 2.2), ID 0 (primary)
> cpu0: HID0 8290c0a4<EMCP,ECLK,DOZE,DPM,ICE,DCE,SGE,BTIC,BHT>
> cpu0: 271.19 MHz, no-parity 512KB WB L2 cache (PB SRAM) at 2:1 ratio
> grackle0 at mainbus0
> pci0 at grackle0 bus 0
> pci0: i/o space, memory space enabled
> pchb0 at pci0 dev 0 function 0
> pchb0: Motorola MPC106 "Grackle" Host Bridge (rev. 0x40)
> fwohci0 at pci0 dev 13 function 0: Texas Instruments TSB12LV26 IEEE 
> 1394 Host Controller (rev. 0x00)
> fwohci0: interrupting at irq 23
> fwohci0: OHCI 1.0, 00:d0:03:56:00:a1:a0:5b, 400Mb/s, 2048 max_rec, 4 
> ir_ctx, 8 it_ctx
> ohci0 at pci0 dev 14 function 0: Opti 82C861 (rev. 0x10)
> ohci0: interrupting at irq 24
> ohci0: OHCI version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: Opti OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> 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:ed:41:5d
> 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: interrupting at irq 25
> sf1: Ethernet address 00:00:d1:ed:41:5e
> sf1: 64-bit PCI slot detected
> sqphy1 at sf1 phy 1: Seeq 80220 10/100 media interface, rev. 1
> sqphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf2 at pci1 dev 6 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
> sf2: interrupting at irq 25
> sf2: Ethernet address 00:00:d1:ed:41:5f
> sf2: 64-bit PCI slot detected
> sqphy2 at sf2 phy 1: Seeq 80220 10/100 media interface, rev. 1
> sqphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf3 at pci1 dev 7 function 0: ANA-62011 (rev 0) 10/100 Ethernet, rev. 3
> sf3: interrupting at irq 25
> sf3: Ethernet address 00:00:d1:ed:41:60
> sf3: 64-bit PCI slot detected
> sqphy3 at sf3 phy 1: Seeq 80220 10/100 media interface, rev. 1
> sqphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> obio0 at pci0 dev 16 function 0: addr 0xf3000000
> mesh0 at obio0 offset 0x10000 irq 12: 50MHz, SCSI ID 7
> scsibus0 at mesh0: 8 targets, 8 luns per target
> bm0 at obio0 offset 0x11000 irq 42,33: address 00:05:02:6e:31:29
> zsc0 at obio0 offset 0x13000: irq 15,16
> zstty0 at zsc0 channel 0
> zstty1 at zsc0 channel 1
> davbus at obio0 offset 0x14000 not configured
> swim3 at obio0 offset 0x15000 not configured
> nvram0 at obio0 offset 0x60000
> wdc0 at obio0 offset 0x20000 irq 13: DMA transfer
> atabus0 at wdc0 channel 0
> wdc1 at obio0 offset 0x21000 irq 14: DMA transfer
> atabus1 at wdc1 channel 0
> adb0 at obio0 offset 0x16000 irq 18: 2 targets
> aed0 at adb0 addr 0: ADB Event device
> akbd0 at adb0 addr 2: adjustable keyboard
> wskbd0 at akbd0: console keyboard
> adb0 addr 7: misc. device (remote control?) (2) unsupported
> ofb0 at pci0 dev 18 function 0: ATI Technologies 3D Rage I/II
> ofb0: 1024 x 768, 8bpp
> wsdisplay0 at ofb0 kbdmux 1: console (std, vt100 emulation), using 
> wskbd0
> wsmux1: connecting to wsdisplay0
> fw0 at fwohci0: 00:d0:03:56:00:a1:a0:5b:0a:02:ff:ff:f0:01:00:00
> scsibus0: waiting 2 seconds for devices to settle...
> wd0 at atabus0 drive 0: <Maxtor 51536H2>
> wd0: drive supports 16-sector PIO transfers, LBA addressing
> wd0: 14594 MB, 29651 cyl, 16 head, 63 sec, 512 bytes/sect x 29888820 
> sectors
> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
> wd0(wdc0:0:0): using PIO mode 4, DMA mode 2 (using DMA)
> atapibus0 at atabus1: 2 targets
> cd0 at atapibus0 drive 0: <MATSHITA CR-589, , GA0W> cdrom removable
> cd0: drive supports PIO mode 4, DMA mode 2
> cd0(wdc1:0:0): using PIO mode 4, DMA mode 2 (using DMA)
> boot device: wd0
> root on wd0a dumps on wd0b
> root file system type: ffs

Do the other devices ( ohci, firewire and so on ) work? Could you check throughput / data loss on the serials? If they're unreliable we'll definitely have to look at the OpenPIC stuff ( which in turn may fix the problem the snapper audio controller has in my iBook G4 )
If you have a spare SCSI disk sitting around please hook it up with the mesh, allow sync mode ( in kernel config change the upper 8 bits of the flags field in mesh's line to 0, the lower 8 bits are ignored anyway so you may just set it to 0 ) and see what throughput you get, should be quite a bit better than it used to be.

have fun
Michael
have