I'm attempting to figure out why an ahc on pci1 on a serverworks board
isn't finding its correct MP interrupt routing entry.  

Here's what I know so far:

There is an interrupt mapping entry for the device:

ioapic1: int12 attached to pci1 device 3 INT_A (type 0<type=0> flags f<pol=3=Act Lo,trig=3=Level>)

The device attaches as follows:

...
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 0 function 0
pchb0: ServerWorks CNB20LE Host (rev. 0x05)
pchb1 at pci0 dev 0 function 1
pchb1: ServerWorks CNB20LE Host (rev. 0x05)
pci1 at pchb1 bus 1
pci1: i/o space, memory space enabled
ahc1 at pci1 dev 3 function 0
ahc1: OptionMode = 3
pci_intr_map: bus 1 dev 3 func 0 pin 4; line 10
pci_intr_map: no MP mapping found
isa_intr_establish: no MP mapping found
ahc1: interrupting at irq 10
ahc1: aic7892 Wide Channel A, SCSI Id=7, 16/255 SCBs
...

It looks like the ahc is the victim of incorrect interrupt swizzling;
I would have expected "pin" to be 1 (INT_A), not 4 (INT_D).

I note that sys/arch/i386/pci/pchb.c fails to fill in all fields of
the "struct pcibus_attach_args"; in particular, pba_intrtag and
pba_intrswiz are not filled in.

pciattach copies these uninitialized fields to the bus's softc, and
they're used in pci_probe_bus() if the bus number is non-zero.

Since we're using an uninitialized variable, this can't possibly be
right.  

What is the right answer?  It seems like the "bus number is nonzero"
test in pci_probe_bus() ought to be replaced by a "bridged bus" vs
"top level bus" test, but I'll admit to some ignorance regarding PCI
bus interrupt routing..

						- Bill