While booting the latest fma-x64 bits, the following ereport is detected with the stack showing the ata driver causing a number of target abort ereports:
class = ereport.cpu.amd.nb.ta <---- Target Abort
ena = 0x20524af12000001
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = hc
hc-list = (array of embedded nvlists)
(start hc-list[0])
nvlist version: 0
hc-name = motherboard
hc-id = 0
(end hc-list[0])
(start hc-list[1])
nvlist version: 0
hc-name = chip
hc-id = 0
(end hc-list[1])
(start hc-list[2])
nvlist version: 0
hc-name = cpu
hc-id = 0
(end hc-list[2])
(end detector)
bank-status = 0xb60000110004081b
bank-number = 0x4
addr = 0xfdfc008440
addr-valid = 1
ip = 0x0
privileged = 0
stack = ao_mca_exception+5a cmi_mca_exception+34 trap+196d cmninttrap+178 ddi_io_get16+10 pci_intx_get_cap+78 pci_common_intr_ops+65d npe_intr_ops+23 i_ddi_intr_ops+54 pciide_intr_ops+70 i_ddi_intr_ops+54 ddi_intr_alloc+263 ddi_add_intr+84 ghd_register+106 ata_init_controller+364 ata_attach+36 devi_attach+94 attach_node+101 i_ndi_config_node+f0 i_ddi_attachchild+5e
This problem is explained by an email snippet from Anish below:
ddi_add_intr(9f) which adds interrupt handlers calls ddi_intr_alloc(9f) internally now.
ddi_intr_alloc(9f) tries to figure out the device's interrupt capabilities by calling ddi_intr_get_cap(9f)
which in turn does PCI config space accesses.
When the ATA disk driver calls ddi_add_intr(9f) its ddi_intr_get_cap(9f) call ends up with
pci_ide(7d) nexus driver. This nexus driver passes it on to PCIe nexus driver blindly
without checking if ATA is a PCI device or not.
The PCIe nexus driver does a PCI config space access to figure out interrupt capabilities and
causes this MCA.