John M. Martin wrote: > J?rgen Keil wrote: > > > > And what is the expected behavior with that new nvidia > > driver module? > > > > Should it be able to use the MSI interrupt with the > > GeForce 6150? Or should it fall back to use a pci > > fixed interrupt? > > It should never try to use MSI on devices that don't advertise PCI-E > compliance > (even if ddi_intr_get_supported_types() returns DDI_INTR_TYPE_MSI).
And the PCI-E compliance test is done by checking for a "pcie-capid-pointer" property? > > On an ASUS M2NPV-VM with no PCIe add-on cards > > installed, but with "set pcplusmp:apic_support_msi = 1" > > in /etc/system the new nvidia module is now able to start > > Xorg; the old nvidia module was failing with "NVRM: > > RmInitAdapter failed! (0x12:0x2b:1636)". The new nvidia > > module is using a fixed pci interrupt. > > > > > > OTOH, on my other system with a "GeForce 6200 TurboCache" > > PCIe add-on card the new nvidia module did fall back to use a > > fixed pci interrupt, too. The old nvidia module was able to use > > an MSI interrupt with this GeForce 6200. > > Can I get the output of /usr/bin/nvidia-SunOS-bug-report.sh from > this system? I'm still not convinced the MSI delivery problem > originates at the GPU but may be higher up in the plumbing. nvidia-SunOS-bug-report.sh output is attached. This "GeForce 6200 TurboCache" pci-e add-on card dioes define the PCI-E capability at pci configuration space offset 0x78 (in addition to PM capability at offset 0x60 and MSI capability at offset 0x68). I checked that from kmdb using "*pci_getb_func" calls. Problem appears to be that on my box no "pcie-capid-pointer" property is defined for the geforce pci-e add-on card. A quick grep in the onnv-gate usr/src/uts didn't find any code that would set such a property, but maybe I'm searching the wrong set of sources or my grep pattern isn't ideal. -- This message posted from opensolaris.org
