Should whatever this issue is be a general PCI fixup? Like broken MSI,
etc.
Can you point me to some details on this?
Might be nice to include what 0x51 tunes in the commit to aide other
peoole with the broken chipset :)
Isn't it necesary to check the PCI vendor as well as the devid?
Will
Does this work on systems where the broken chipset might
not be the immediate parent of the qib device (ie there are
some PCIe switches in between)?
The code figures this out at the top of routine and returns, changing nothing.
This message and any attached documents contain information
On Thu, Jan 12, 2012 at 08:02:52AM -0800, Mike Marciniszyn wrote:
Should whatever this issue is be a general PCI fixup? Like broken MSI,
etc.
Can you point me to some details on this?
I can explain the broken MSI stuff, as an example. As I noted I'm not
sure what you are working around
On Thu, Jan 12, 2012 at 9:17 AM, Mike Marciniszyn
mike.marcinis...@qlogic.com wrote:
Does this work on systems where the broken chipset might
not be the immediate parent of the qib device (ie there are
some PCIe switches in between)?
The code figures this out at the top of routine and
if (parent-vendor != 0x8086)
return 1;
so I guess you don't need another vendor check.
Actually, Jason is right. The vendor check you reference here is in
qib_tune_pcie_coalesce() and not the routine being patched.
A bit of background here is that the issue was
On Thu, Jan 12, 2012 at 02:14:12PM -0800, Mike Marciniszyn wrote:
Actually, Jason is right. The vendor check you reference here is in
qib_tune_pcie_coalesce() and not the routine being patched.
A bit of background here is that the issue was noted with the
indicated Harpertown root complex
It doesn't seem to me like this has any place in the quirks thing
either. Things seem to be working properly, the MaxPayLoad of 128 is
clearly the highest the system will support correctly.
Jason
Probably the best thing to do unwind the module parameter default in 8d4548f2b
which would
Commit 8d4548f2b (IB/qib: Default some module parameters optimally)
introduced an issue with older root complexes. They cannot handle
the pcie_caps of 0x51.
A typical diagnostic in this situation reported by syslog contains
the text:
[PCIe Poisoned TLP][Send DMA memory read]
Insure the 0x51
On Wed, Jan 11, 2012 at 10:00:49PM -0500, Mike Marciniszyn wrote:
Commit 8d4548f2b (IB/qib: Default some module parameters optimally)
introduced an issue with older root complexes. They cannot handle
the pcie_caps of 0x51.
Should whatever this issue is be a general PCI fixup? Like broken MSI,
On Wed, Jan 11, 2012 at 7:00 PM, Mike Marciniszyn
mike.marcinis...@qlogic.com wrote:
+ if (!qib_pcie_caps) {
+ u16 devid = parent-device;
+ if ((devid = 0x25e2 devid = 0x25fa) ||
+ (devid = 0x65e2 devid = 0x65fa) ||
+
On Wed, Jan 11, 2012 at 9:48 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
Isn't it necesary to check the PCI vendor as well as the devid?
That definitely seems like a good idea.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
11 matches
Mail list logo
