Re: [Nouveau] How to check for proper MSI support?

2014-07-08 Thread Bjorn Helgaas 
On Thu, Jul 3, 2014 at 10:32 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 So let me get this straight -- you're suggesting I add a quirk for
 every PCI chipset that doesn't support MSI? There are probably
 hundreds of these... anything made before 1999 or so, and probably a
 bunch since then too. There _has_ to be a way to do this generically.
 Is the PCI spec version anywhere in the root hub?

 Perhaps we can check if every bridge on the way to the CPU has the MSI
 capability (including the root hub)? (And naturally _that_ won't
 work... on my sandybridge laptop, the host bridge doesn't have the MSI
 cap but the system most definitely supports MSI.)

 Adding Bjorn... perhaps you know? Some of the info has been stripped
 out by now, you can see the full lspci -vvvxxx at
 http://marc.info/?l=linux-pcim=140443441730503w=2

Huh, this stinks.  We don't really have a good way of figuring out
whether the system chipset supports MSI.  The ACPI FADT MSI Not
Supported bit (ACPI_FADT_NO_MSI) was added to the ACPI v3.0b spec in
October 2006, so that won't help the systems that predate that or
don't have ACPI.

We have quirks for some Serverworks, ATI, and VIA chipsets that
basically do the same as booting with pci=nomsi.  But as you say,
it's unreasonable to add quirks for all old systems.

Brian, can you open a report at http://bugzilla.kernel.org and attach
a complete dmesg log, /proc/cpuinfo contents, and lspci -vvv output?

If I understand correctly, you have a P200MMX with a 430FX chipset.
I'm not a hardware guy, but sounds like that might be a 200MHz Pentium
with MMX (P54CS), which does have an integrated LAPIC, according to
wikipedia.

From the PCI host bridge's perspective, an incoming MSI just looks
like a normal DMA write.  As long as that write reaches the CPU LAPIC,
it should work fine.  There's not really any specific MSI support
required, except to route the incoming write to the CPU LAPIC.  So
it's possible that a bridge designed before MSI was added to the PCI
spec might be able to support MSI.

But I don't know how much value there is in MSI on such old systems.
Maybe we could default to disabling MSI on BIOS dates before 1998 or
something.

Bjorn
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Yijing Wang 
 There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
 - PCI bridge (all on one card), which is plugged into a motherboard
 with the 430FX chipset (PCI 2.0 supported).

 The GPU PCI device, of course, has full support for MSI. However my
 understanding is that MSI won't actually work here. This is confirmed
 by the fact that if we let nouveau enable MSI, the device doesn't work
 (presumably due to lack of interrupt delivery, although I admit to not
 having debugged it that far). How do I, as a nouveau driver developer,
 know not to call pci_enable_msi? Or alternatively how can
 pci_enable_msi be taught not to succeed in this case?

 You can set bus_flags or global pci_msi_enable flag by add quirk function.
 You can refer to examples in drivers/pci/quirk.c

 Linux support some broken chipsets or devices to disable msi during device 
 initialization by add quirk.
 
 So let me get this straight -- you're suggesting I add a quirk for
 every PCI chipset that doesn't support MSI? There are probably
 hundreds of these... anything made before 1999 or so, and probably a
 bunch since then too. There _has_ to be a way to do this generically.
 Is the PCI spec version anywhere in the root hub?

There is no register to identify PCI spec version in PCI config space registers.
If your platform boot up with ACPI, you can setting ACPI FADT boot flag to 
disable MSI,
you can refer to this in ACPI 5.2.9.3 chapter Fixed ACPI Description Table 
Boot Architecture Flags


 
 Perhaps we can check if every bridge on the way to the CPU has the MSI
 capability (including the root hub)? (And naturally _that_ won't
 work... on my sandybridge laptop, the host bridge doesn't have the MSI
 cap but the system most definitely supports MSI.)
 
 Adding Bjorn... perhaps you know? Some of the info has been stripped
 out by now, you can see the full lspci -vvvxxx at
 http://marc.info/?l=linux-pcim=140443441730503w=2
 
   -ilia
 
 .
 


-- 
Thanks!
Yijing

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Yijing Wang 
On 2014/7/4 14:26, Brian Becker wrote:
 I am booting a kernel with CONFIG_ACPI=n on a platform which does not
 support ACPI.

Hmmm, so my suggestion is
1. Add quirk to detect 430FX chipset, if detected, disable MSI in this platform.
or

2. Append boot argument pci=nomsi in OS command line when the OS running on 
your old platform.

Maybe other guys has some advices. :)




 
 On Fri, Jul 4, 2014 at 1:59 AM, Yijing Wang wangyij...@huawei.com wrote:
 There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
 - PCI bridge (all on one card), which is plugged into a motherboard
 with the 430FX chipset (PCI 2.0 supported).

 The GPU PCI device, of course, has full support for MSI. However my
 understanding is that MSI won't actually work here. This is confirmed
 by the fact that if we let nouveau enable MSI, the device doesn't work
 (presumably due to lack of interrupt delivery, although I admit to not
 having debugged it that far). How do I, as a nouveau driver developer,
 know not to call pci_enable_msi? Or alternatively how can
 pci_enable_msi be taught not to succeed in this case?

 You can set bus_flags or global pci_msi_enable flag by add quirk function.
 You can refer to examples in drivers/pci/quirk.c

 Linux support some broken chipsets or devices to disable msi during device 
 initialization by add quirk.

 So let me get this straight -- you're suggesting I add a quirk for
 every PCI chipset that doesn't support MSI? There are probably
 hundreds of these... anything made before 1999 or so, and probably a
 bunch since then too. There _has_ to be a way to do this generically.
 Is the PCI spec version anywhere in the root hub?

 There is no register to identify PCI spec version in PCI config space 
 registers.
 If your platform boot up with ACPI, you can setting ACPI FADT boot flag to 
 disable MSI,
 you can refer to this in ACPI 5.2.9.3 chapter Fixed ACPI Description Table 
 Boot Architecture Flags



 Perhaps we can check if every bridge on the way to the CPU has the MSI
 capability (including the root hub)? (And naturally _that_ won't
 work... on my sandybridge laptop, the host bridge doesn't have the MSI
 cap but the system most definitely supports MSI.)

 Adding Bjorn... perhaps you know? Some of the info has been stripped
 out by now, you can see the full lspci -vvvxxx at
 http://marc.info/?l=linux-pcim=140443441730503w=2

   -ilia

 .



 --
 Thanks!
 Yijing

 
 .
 


-- 
Thanks!
Yijing

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Brian Becker 
Yijing,

cat /sys/bus/pci/devices/\:00\:0e.0/msi_bus returns 1, suggesting
that it supports MSI. However, this 00:0e.0 PCI bridge: PLX
Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
is a component of the addin card. Wouldn't the lack of support for MSI
by the chipset 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX
TSC [Triton I] (rev 01) preclude the use of MSI with buses attached
via a bridge?

Thanks,
Brian

On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() return 
 during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

 On 2014/7/4 8:35, Brian Becker wrote:
 I mistakenly only replied to Yijing Wang the first time. Here are the 
 further details.

 uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 
 GNU/Linux

 Here is the output from lspci -vvvxxx:

 root@p5-133:~# cat lspci.txt
 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 
 01)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort+ SERR- PERR- INTx-
 Latency: 64
 00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
 60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
 70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
 70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

 00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev 
 02) (prog-if 80 [Master])
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 64
 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) 
 [size=8]
 Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) 
 [size=1]
 Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) 
 [size=8]
 Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) 
 [size=1]
 Region 4: I/O ports at ef80 [size=16]
 Kernel driver in use: pata_oldpiix
 00: 86 80 30 12 05 00 80 02 02 80 01 01 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Brian Becker 
My previous message was badly formatted, and didn't make it to
linux-...@vger.kernel.org. Hopefully this information is of some use.

root@p5-133:~# uname -a
Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 GNU/Linux
root@p5-133:~# lspci -vvvxxx
00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- TAbort- MAbort+ SERR- PERR- INTx-
Latency: 128
00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 80 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I]
(rev 02) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 128
Region 0: [virtual] Memory at 01f0 (32-bit,
non-prefetchable) [size=8]
Region 1: [virtual] Memory at 03f0 (type 3,
non-prefetchable) [size=1]
Region 2: [virtual] Memory at 0170 (32-bit,
non-prefetchable) [size=8]
Region 3: [virtual] Memory at 0370 (type 3,
non-prefetchable) [size=1]
Region 4: I/O ports at ef80 [size=16]
Kernel driver in use: pata_oldpiix
00: 86 80 30 12 05 00 80 02 02 80 01 01 00 80 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

00:0e.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 128, Cache Line Size: 32 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: f000-
Memory behind bridge: f5e0-fbff
Prefetchable memory behind bridge: d5d0-f5df
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Brian Becker 
I mistakenly only replied to Yijing Wang the first time. Here are the
further details.

uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586
GNU/Linux

Here is the output from lspci -vvvxxx:

root@p5-133:~# cat lspci.txt
00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev
01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort+ SERR- PERR- INTx-
Latency: 64
00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev
02) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 64
Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable)
[size=8]
Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable)
[size=1]
Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable)
[size=8]
Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable)
[size=1]
Region 4: I/O ports at ef80 [size=16]
Kernel driver in use: pata_oldpiix
00: 86 80 30 12 05 00 80 02 02 80 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

00:0e.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI
Bridge (rev aa) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 66, Cache Line Size: 32 bytes

Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: f000-
Memory behind bridge: f5e0-fbff
Prefetchable memory behind bridge: d5d0-f5df
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

Capabilities: [40]

Re: [Nouveau] How to check for proper MSI support?

2014-07-04 Thread Brian Becker 
I am booting a kernel with CONFIG_ACPI=n on a platform which does not
support ACPI.

-Brian

On Fri, Jul 4, 2014 at 1:59 AM, Yijing Wang wangyij...@huawei.com wrote:
 There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
 - PCI bridge (all on one card), which is plugged into a motherboard
 with the 430FX chipset (PCI 2.0 supported).

 The GPU PCI device, of course, has full support for MSI. However my
 understanding is that MSI won't actually work here. This is confirmed
 by the fact that if we let nouveau enable MSI, the device doesn't work
 (presumably due to lack of interrupt delivery, although I admit to not
 having debugged it that far). How do I, as a nouveau driver developer,
 know not to call pci_enable_msi? Or alternatively how can
 pci_enable_msi be taught not to succeed in this case?

 You can set bus_flags or global pci_msi_enable flag by add quirk function.
 You can refer to examples in drivers/pci/quirk.c

 Linux support some broken chipsets or devices to disable msi during device 
 initialization by add quirk.

 So let me get this straight -- you're suggesting I add a quirk for
 every PCI chipset that doesn't support MSI? There are probably
 hundreds of these... anything made before 1999 or so, and probably a
 bunch since then too. There _has_ to be a way to do this generically.
 Is the PCI spec version anywhere in the root hub?

 There is no register to identify PCI spec version in PCI config space 
 registers.
 If your platform boot up with ACPI, you can setting ACPI FADT boot flag to 
 disable MSI,
 you can refer to this in ACPI 5.2.9.3 chapter Fixed ACPI Description Table 
 Boot Architecture Flags



 Perhaps we can check if every bridge on the way to the CPU has the MSI
 capability (including the root hub)? (And naturally _that_ won't
 work... on my sandybridge laptop, the host bridge doesn't have the MSI
 cap but the system most definitely supports MSI.)

 Adding Bjorn... perhaps you know? Some of the info has been stripped
 out by now, you can see the full lspci -vvvxxx at
 http://marc.info/?l=linux-pcim=140443441730503w=2

   -ilia

 .



 --
 Thanks!
 Yijing

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Yijing Wang 
On 2014/7/3 11:20, Ilia Mirkin wrote:
 Hello,
 
 A user (cc'd) reported that nouveau's enabling of MSI causes the card
 to not work on his setup [1]. I think the situation is that MSI is
 just not supported by the underlying motherboard, even though the
 card, and probably bridge, support it just fine. It's a very old
 board. The nouveau code does:


What is the kernel version running in your board ?

 
 pmc-use_msi = pci_enable_msi(device-pdev) == 0;

Driver call pci_enable_msi() and always return 0 ?

 
 Does it need to do more checking than that before trying to enable MSI
 on the device? Could it be that the linux pci subsystem is missing on
 inheriting MSI capabilities somewhere?

pci_enable_msi() will checking your device whether it supports MSI.
Can you provide the detailed lspci information ? eg. lspci -vvvxxx ?


 
   -ilia
 
 [1]
 
 00:00.0 Host bridge [0600]: Intel Corporation 430FX - 82437FX TSC
 [Triton I] [8086:122d] (rev 01)
 Flags: bus master, medium devsel, latency 64
 
 00:0e.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
 Express-to-PCI Bridge [10b5:8112] (rev aa) (prog-if 00 [Normal
 decode])
 Flags: bus master, 66MHz, medium devsel, latency 66
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 I/O behind bridge: f000-
 Memory behind bridge: f5e0-fbff
 Prefetchable memory behind bridge: d5d0-f5df
 Capabilities: [40] Power Management version 2
 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [60] Express PCI/PCI-X to PCI-Express Bridge, MSI 00
 
 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96
 [GeForce 9400 GT] [10de:0641] (rev a1) (prog-if 00 [VGA controller])
 Subsystem: Jaton Corp Device [1b13:0641]
 Flags: bus master, fast devsel, latency 0, IRQ 11
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Memory at e000 (64-bit, prefetchable) [size=256M]
 Memory at f800 (64-bit, non-prefetchable) [size=32M]
 I/O ports at fc80 [size=128]
 [virtual] Expansion ROM at d5d0 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Endpoint, MSI 00
 Capabilities: [b4] Vendor Specific Information: Len=14 ?
 Kernel driver in use: nouveau
 --
 To unsubscribe from this list: send the line unsubscribe linux-pci in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 


-- 
Thanks!
Yijing

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Yijing Wang 
Hi Brian,
   From your 01:00.0 VGA compatible controller PCI config register, it supports 
1 MSI vector, so I think this
card has no problem. But you didn't answer what's the pci_enable_msi() return 
during it enable MSI fail.

You can check PCI bus whether support MSI like:

cat /sys/bus/pci/devices/00:0e.0/msi_bus

Other, do you call pci_enable_device() before pci_enable_msi() ?

On 2014/7/4 8:35, Brian Becker wrote:
 I mistakenly only replied to Yijing Wang the first time. Here are the further 
 details.
 
 uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 
 GNU/Linux
 
 Here is the output from lspci -vvvxxx:
 
 root@p5-133:~# cat lspci.txt
 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 01)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort+ SERR- PERR- INTx-
 Latency: 64
 00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
 60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
 70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
 
 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
 70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00
 
 00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev 02) 
 (prog-if 80 [Master])
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 64
 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) 
 [size=8]
 Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) 
 [size=1]
 Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) 
 [size=8]
 Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) 
 [size=1]
 Region 4: I/O ports at ef80 [size=16]
 Kernel driver in use: pata_oldpiix
 00: 86 80 30 12 05 00 80 02 02 80 01 01 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00
 
 00:0e.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI 
 Bridge (rev aa) (prog-if 00 [Normal decode])
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
 Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Ilia Mirkin 
On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() return 
 during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

Yes, the device is enabled. nouveau does generally work for most
people :) And it works fine here if MSI is forced off.

The problem here is that pci_enable_msi() succeeds, but it probably
shouldn't. I don't know all the details about MSI, but doesn't the CPU
or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
chipset board. Both quite ancient...

So given that the PCI device itself supports MSI, how do we tell that
it shouldn't actually get turned on?

  -ilia


 On 2014/7/4 8:35, Brian Becker wrote:
 I mistakenly only replied to Yijing Wang the first time. Here are the 
 further details.

 uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 
 GNU/Linux

 Here is the output from lspci -vvvxxx:

 root@p5-133:~# cat lspci.txt
 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 
 01)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort+ SERR- PERR- INTx-
 Latency: 64
 00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
 60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
 70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
 70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

 00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev 
 02) (prog-if 80 [Master])
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 64
 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) 
 [size=8]
 Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) 
 [size=1]
 Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) 
 [size=8]
 Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) 
 [size=1]
 Region 4: I/O ports at ef80 [size=16]
 Kernel driver in use: pata_oldpiix
 00: 86 80 30 12 05 00 80 02 02 80 01 01 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Yijing Wang 
On 2014/7/4 10:43, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() 
 return during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?
 
 Yes, the device is enabled. nouveau does generally work for most
 people :) And it works fine here if MSI is forced off.

 The problem here is that pci_enable_msi() succeeds, but it probably

It's some strange, pci_enable_msi() succeeds, but there is nothing in MSI 
address and data register

Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Because the address and data is invalid, so MSI can not work.

Because you said pci_enable_msi() return 0 which indicates success, so I guess 
the device
current power state is not D0, because checking code in __write_msi_msi.

void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
if (entry-dev-current_state != PCI_D0) {
/* Don't touch the hardware now */
} else if (entry-msi_attrib.is_msix) {
void __iomem *base;
base = entry-mask_base +
entry-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;

writel(msg-address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
writel(msg-address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
writel(msg-data, base + PCI_MSIX_ENTRY_DATA);
..

 shouldn't. I don't know all the details about MSI, but doesn't the CPU
 or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
 chipset board. Both quite ancient...

MSI in x86 always send to specific interrupt address(0xfee), most x86 CPU
should support MSI, but I am not sure, I don't know hardware much.

 
 So given that the PCI device itself supports MSI, how do we tell that
 it shouldn't actually get turned on?

Generally, some message in dmesg like:
[   17.322311] ahci :00:1f.2: irq 119 for MSI/MSI-X
[   17.322319] ahci :00:1f.2: irq 120 for MSI/MSI-X
[   17.322326] ahci :00:1f.2: irq 121 for MSI/MSI-X
[   17.322333] ahci :00:1f.2: irq 122 for MSI/MSI-X
[   17.322339] ahci :00:1f.2: irq 123 for MSI/MSI-X

Also you can check /proc/interrupts I think.

 
   -ilia
 

 On 2014/7/4 8:35, Brian Becker wrote:
 I mistakenly only replied to Yijing Wang the first time. Here are the 
 further details.

 uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 
 GNU/Linux

 Here is the output from lspci -vvvxxx:

 root@p5-133:~# cat lspci.txt
 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 
 01)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort+ SERR- PERR- INTx-
 Latency: 64
 00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
 60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
 70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
 70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Yijing Wang 
On 2014/7/4 10:45, Brian Becker wrote:
 Yijing,
 
 cat /sys/bus/pci/devices/\:00\:0e.0/msi_bus returns 1, suggesting
 that it supports MSI. However, this 00:0e.0 PCI bridge: PLX
 Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
 is a component of the addin card. Wouldn't the lack of support for MSI
 by the chipset 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX
 TSC [Triton I] (rev 01) preclude the use of MSI with buses attached
 via a bridge?

We have no ways to check host bridge whether support MSI routing to CPU, BIOS
is responsible for setting and config this in their private registers located 
in IOH.
This is transparent to OS I think.

 
 Thanks,
 Brian
 
 On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() 
 return during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

 On 2014/7/4 8:35, Brian Becker wrote:
 I mistakenly only replied to Yijing Wang the first time. Here are the 
 further details.

 uname -a: Linux p5-133 3.15.2-p5-133 #1 Thu Jun 26 22:56:27 EDT 2014 i586 
 GNU/Linux

 Here is the output from lspci -vvvxxx:

 root@p5-133:~# cat lspci.txt
 00:00.0 Host bridge: Intel Corporation 430FX - 82437FX TSC [Triton I] (rev 
 01)
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort+ SERR- PERR- INTx-
 Latency: 64
 00: 86 80 2d 12 06 00 00 22 01 00 00 06 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 50: 88 00 41 00 00 00 00 03 49 10 55 55 55 05 55 05
 60: 08 10 18 20 20 00 00 00 0f 00 00 00 00 00 00 00
 70: 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00

 00:07.0 ISA bridge: Intel Corporation 82371FB PIIX ISA [Triton I] (rev 02)
 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 00: 86 80 2e 12 0f 00 80 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 60 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 0b 0b 0b 09 00 00 00 00 00 f2 05 00 00 00 00 00
 70: 0f 80 00 00 00 00 04 04 02 00 00 00 00 00 00 00
 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 03 00 e0 00 02 d0 00 a0 13 00 00 00 00 00 00 00
 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 f0: 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 00

 00:07.1 IDE interface: Intel Corporation 82371FB PIIX IDE [Triton I] (rev 
 02) (prog-if 80 [Master])
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 64
 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) 
 [size=8]
 Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) 
 [size=1]
 Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) 
 [size=8]
 Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) 
 [size=1]
 Region 4: I/O ports at ef80 [size=16]
 Kernel driver in use: pata_oldpiix
 00: 86 80 30 12 05 00 80 02 02 80 01 01 00 40 00 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 81 ef 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 40: 36 a3 07 a3 00 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Ilia Mirkin 
On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang wangyij...@huawei.com wrote:
 On 2014/7/4 10:43, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() 
 return during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

 Yes, the device is enabled. nouveau does generally work for most
 people :) And it works fine here if MSI is forced off.

 The problem here is that pci_enable_msi() succeeds, but it probably

 It's some strange, pci_enable_msi() succeeds, but there is nothing in MSI 
 address and data register

 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Address:   Data: 
 Because the address and data is invalid, so MSI can not work.

 Because you said pci_enable_msi() return 0 which indicates success, so I 
 guess the device
 current power state is not D0, because checking code in __write_msi_msi.

 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 if (entry-dev-current_state != PCI_D0) {
 /* Don't touch the hardware now */
 } else if (entry-msi_attrib.is_msix) {
 void __iomem *base;
 base = entry-mask_base +
 entry-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;

 writel(msg-address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
 writel(msg-address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
 writel(msg-data, base + PCI_MSIX_ENTRY_DATA);
 ..

 shouldn't. I don't know all the details about MSI, but doesn't the CPU
 or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
 chipset board. Both quite ancient...

 MSI in x86 always send to specific interrupt address(0xfee), most x86 CPU
 should support MSI, but I am not sure, I don't know hardware much.

To put things in perspective, P200MMX was released in early 1997. It
looks like the PCI 2.2 spec, which defines MSI, was released in late
1998. The 430FX chipset only supports PCI 2.0.



 So given that the PCI device itself supports MSI, how do we tell that
 it shouldn't actually get turned on?

 Generally, some message in dmesg like:
 [   17.322311] ahci :00:1f.2: irq 119 for MSI/MSI-X
 [   17.322319] ahci :00:1f.2: irq 120 for MSI/MSI-X
 [   17.322326] ahci :00:1f.2: irq 121 for MSI/MSI-X
 [   17.322333] ahci :00:1f.2: irq 122 for MSI/MSI-X
 [   17.322339] ahci :00:1f.2: irq 123 for MSI/MSI-X

 Also you can check /proc/interrupts I think.

I must not have made my question clear. Let me try again:

There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
- PCI bridge (all on one card), which is plugged into a motherboard
with the 430FX chipset (PCI 2.0 supported).

The GPU PCI device, of course, has full support for MSI. However my
understanding is that MSI won't actually work here. This is confirmed
by the fact that if we let nouveau enable MSI, the device doesn't work
(presumably due to lack of interrupt delivery, although I admit to not
having debugged it that far). How do I, as a nouveau driver developer,
know not to call pci_enable_msi? Or alternatively how can
pci_enable_msi be taught not to succeed in this case?

Thanks,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Yijing Wang 
On 2014/7/4 11:30, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang wangyij...@huawei.com wrote:
 On 2014/7/4 10:43, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() 
 return during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

 Yes, the device is enabled. nouveau does generally work for most
 people :) And it works fine here if MSI is forced off.

 The problem here is that pci_enable_msi() succeeds, but it probably

 It's some strange, pci_enable_msi() succeeds, but there is nothing in MSI 
 address and data register

 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Address:   Data: 
 Because the address and data is invalid, so MSI can not work.

 Because you said pci_enable_msi() return 0 which indicates success, so I 
 guess the device
 current power state is not D0, because checking code in __write_msi_msi.

 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 if (entry-dev-current_state != PCI_D0) {
 /* Don't touch the hardware now */
 } else if (entry-msi_attrib.is_msix) {
 void __iomem *base;
 base = entry-mask_base +
 entry-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;

 writel(msg-address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
 writel(msg-address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
 writel(msg-data, base + PCI_MSIX_ENTRY_DATA);
 ..

 shouldn't. I don't know all the details about MSI, but doesn't the CPU
 or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
 chipset board. Both quite ancient...

 MSI in x86 always send to specific interrupt address(0xfee), most x86 CPU
 should support MSI, but I am not sure, I don't know hardware much.
 
 To put things in perspective, P200MMX was released in early 1997. It
 looks like the PCI 2.2 spec, which defines MSI, was released in late
 1998. The 430FX chipset only supports PCI 2.0.

Maybe you are right, the chipset can not support MSI...

But why after your call pci_enable_msi(), the MSI address and data register is 
nothing initialized.


 


 So given that the PCI device itself supports MSI, how do we tell that
 it shouldn't actually get turned on?

 Generally, some message in dmesg like:
 [   17.322311] ahci :00:1f.2: irq 119 for MSI/MSI-X
 [   17.322319] ahci :00:1f.2: irq 120 for MSI/MSI-X
 [   17.322326] ahci :00:1f.2: irq 121 for MSI/MSI-X
 [   17.322333] ahci :00:1f.2: irq 122 for MSI/MSI-X
 [   17.322339] ahci :00:1f.2: irq 123 for MSI/MSI-X

 Also you can check /proc/interrupts I think.
 
 I must not have made my question clear. Let me try again:
 
 There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
 - PCI bridge (all on one card), which is plugged into a motherboard
 with the 430FX chipset (PCI 2.0 supported).
 
 The GPU PCI device, of course, has full support for MSI. However my
 understanding is that MSI won't actually work here. This is confirmed
 by the fact that if we let nouveau enable MSI, the device doesn't work
 (presumably due to lack of interrupt delivery, although I admit to not
 having debugged it that far). How do I, as a nouveau driver developer,
 know not to call pci_enable_msi? Or alternatively how can
 pci_enable_msi be taught not to succeed in this case?

You can set bus_flags or global pci_msi_enable flag by add quirk function.
You can refer to examples in drivers/pci/quirk.c

Linux support some broken chipsets or devices to disable msi during device 
initialization by add quirk.

 
 Thanks,
 
   -ilia
 
 .
 


-- 
Thanks!
Yijing

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to check for proper MSI support?

2014-07-03 Thread Ilia Mirkin 
On Thu, Jul 3, 2014 at 11:56 PM, Yijing Wang wangyij...@huawei.com wrote:
 On 2014/7/4 11:30, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 11:09 PM, Yijing Wang wangyij...@huawei.com wrote:
 On 2014/7/4 10:43, Ilia Mirkin wrote:
 On Thu, Jul 3, 2014 at 10:35 PM, Yijing Wang wangyij...@huawei.com wrote:
 Hi Brian,
From your 01:00.0 VGA compatible controller PCI config register, it 
 supports 1 MSI vector, so I think this
 card has no problem. But you didn't answer what's the pci_enable_msi() 
 return during it enable MSI fail.

 You can check PCI bus whether support MSI like:

 cat /sys/bus/pci/devices/00:0e.0/msi_bus

 Other, do you call pci_enable_device() before pci_enable_msi() ?

 Yes, the device is enabled. nouveau does generally work for most
 people :) And it works fine here if MSI is forced off.

 The problem here is that pci_enable_msi() succeeds, but it probably

 It's some strange, pci_enable_msi() succeeds, but there is nothing in MSI 
 address and data register

 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Address:   Data: 
 Because the address and data is invalid, so MSI can not work.

 Because you said pci_enable_msi() return 0 which indicates success, so I 
 guess the device
 current power state is not D0, because checking code in __write_msi_msi.

 void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
 {
 if (entry-dev-current_state != PCI_D0) {
 /* Don't touch the hardware now */
 } else if (entry-msi_attrib.is_msix) {
 void __iomem *base;
 base = entry-mask_base +
 entry-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;

 writel(msg-address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR);
 writel(msg-address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR);
 writel(msg-data, base + PCI_MSIX_ENTRY_DATA);
 ..

 shouldn't. I don't know all the details about MSI, but doesn't the CPU
 or (L)APIC have to support it? In this case, it's a P200MMX on a 430FX
 chipset board. Both quite ancient...

 MSI in x86 always send to specific interrupt address(0xfee), most x86 
 CPU
 should support MSI, but I am not sure, I don't know hardware much.

 To put things in perspective, P200MMX was released in early 1997. It
 looks like the PCI 2.2 spec, which defines MSI, was released in late
 1998. The 430FX chipset only supports PCI 2.0.

 Maybe you are right, the chipset can not support MSI...

 But why after your call pci_enable_msi(), the MSI address and data register 
 is nothing initialized.

The lspci output you saw was not with pci_enable_msi having been run
-- it was in the working configuration, where nouveau is told not to
enable MSI.






 So given that the PCI device itself supports MSI, how do we tell that
 it shouldn't actually get turned on?

 Generally, some message in dmesg like:
 [   17.322311] ahci :00:1f.2: irq 119 for MSI/MSI-X
 [   17.322319] ahci :00:1f.2: irq 120 for MSI/MSI-X
 [   17.322326] ahci :00:1f.2: irq 121 for MSI/MSI-X
 [   17.322333] ahci :00:1f.2: irq 122 for MSI/MSI-X
 [   17.322339] ahci :00:1f.2: irq 123 for MSI/MSI-X

 Also you can check /proc/interrupts I think.

 I must not have made my question clear. Let me try again:

 There is a NVIDIA G96 GPU (which is PCIe only) hanging off of a PCIe
 - PCI bridge (all on one card), which is plugged into a motherboard
 with the 430FX chipset (PCI 2.0 supported).

 The GPU PCI device, of course, has full support for MSI. However my
 understanding is that MSI won't actually work here. This is confirmed
 by the fact that if we let nouveau enable MSI, the device doesn't work
 (presumably due to lack of interrupt delivery, although I admit to not
 having debugged it that far). How do I, as a nouveau driver developer,
 know not to call pci_enable_msi? Or alternatively how can
 pci_enable_msi be taught not to succeed in this case?

 You can set bus_flags or global pci_msi_enable flag by add quirk function.
 You can refer to examples in drivers/pci/quirk.c

 Linux support some broken chipsets or devices to disable msi during device 
 initialization by add quirk.

So let me get this straight -- you're suggesting I add a quirk for
every PCI chipset that doesn't support MSI? There are probably
hundreds of these... anything made before 1999 or so, and probably a
bunch since then too. There _has_ to be a way to do this generically.
Is the PCI spec version anywhere in the root hub?

Perhaps we can check if every bridge on the way to the CPU has the MSI
capability (including the root hub)? (And naturally _that_ won't
work... on my sandybridge laptop, the host bridge doesn't have the MSI
cap but the system most definitely supports MSI.)

Adding Bjorn... perhaps you know? Some of the info has been stripped
out by now, you can see the full lspci -vvvxxx at
http://marc.info/?l=linux-pcim=140443441730503w=2

  -ilia
___
Nouveau mailing list

[Nouveau] How to check for proper MSI support?

2014-07-02 Thread Ilia Mirkin 
Hello,

A user (cc'd) reported that nouveau's enabling of MSI causes the card
to not work on his setup [1]. I think the situation is that MSI is
just not supported by the underlying motherboard, even though the
card, and probably bridge, support it just fine. It's a very old
board. The nouveau code does:

pmc-use_msi = pci_enable_msi(device-pdev) == 0;

Does it need to do more checking than that before trying to enable MSI
on the device? Could it be that the linux pci subsystem is missing on
inheriting MSI capabilities somewhere?

Thanks,

  -ilia

[1]

00:00.0 Host bridge [0600]: Intel Corporation 430FX - 82437FX TSC
[Triton I] [8086:122d] (rev 01)
Flags: bus master, medium devsel, latency 64

00:0e.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge [10b5:8112] (rev aa) (prog-if 00 [Normal
decode])
Flags: bus master, 66MHz, medium devsel, latency 66
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: f000-
Memory behind bridge: f5e0-fbff
Prefetchable memory behind bridge: d5d0-f5df
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] Express PCI/PCI-X to PCI-Express Bridge, MSI 00

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96
[GeForce 9400 GT] [10de:0641] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Jaton Corp Device [1b13:0641]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at f800 (64-bit, non-prefetchable) [size=32M]
I/O ports at fc80 [size=128]
[virtual] Expansion ROM at d5d0 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 ?
Kernel driver in use: nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau