RE: [Ilw] Intel Wireless 7260 hardware timed out randomly

["Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>]

> >
> > On Tue, Nov 12, 2013 at 12:37 PM, Emmanuel Grumbach
> > <egrumbach@gmail.com> wrote:
> > > On 11/12/2013 09:14 PM, Bjorn Helgaas wrote:
> > >> On Tue, Nov 12, 2013 at 11:25 AM, Grumbach, Emmanuel
> > >> <emmanuel.grumbach@intel.com> wrote:
> > >>
> > >>> Right - I remember the discussion we had on that.
> > >>> On this device (7260 that has an issue with ASPM), we don't call
> > pci_disable_link_state, because we know it is supposed to work...
> > >>
> > >> If ASPM is supposed to work as far as the hardware is concerned, I
> > >> guess you're saying this must be an iwlwifi driver issue.  Right?
> > >
> > > ASPM is supposed to work as far as the hardware is concerned.
> > > We might very well have an issue in iwlwifi - and I am checking this
> > > internally with our System guys.
> > > It can be a PCI core problem too, and it could also be a platform /
> > > BIOS / Lenovo issue.
> > > Of course, I have no clue which of these is the culprit here.
> > > Our System folks seemed to say that this new device uses L1
> > > substates which can be enabled in Haswell platform which the user owns.
> > > Now - L1 substates is a new feature and might introduce issues
> > > (apparently) - and this is why they (System folks) wanted the try
> > > without L1 substates. But disabling L1 substates doesn't seem
> > > trivial with the production BIOS of Lenovo. So I am pretty stuck here.
> >
> > For debugging purposes, we could configure L1 substates with setpci,
> > as we did for ASPM.  The Linux kernel knows nothing about L1
> > substates, so the PCI core isn't doing anything with them.  It's
> > possible the driver itself could muck with L1 substate configuration,
> > but that would be discouraged, and I don't see anything in iwlwifi that is
> doing that.
> >
> > The lspci output in
> > https://bugzilla.kernel.org/attachment.cgi?id=114061 shows an L1 PM
> > Substates extended capability (capability ID 0x1e) for the Root Port
> > leading to the 7260 device, but not for the 7260 device itself:
> >
> >   00:1c.1 PCI bridge: Intel Corporation Lynx Point-LP PCI Express Root
> > Port 3 (rev e4) (prog-if 00 [Normal decode])
> >     Capabilities: [200 v1] #1e
> >
> > Per sec 5.5.4 of the ECN for L1 PM Substates (15 Aug 2012), I think L1
> > substates must be configured on both ends of the link, and if the 7260
> > device doesn't have that capability, I don't see how it could be enabled.
> 
> Makes sense.
> 
> >
> > The lspci version wzyboy has doesn't decode the L1 PM Substates
> > capability, but there is a newer version at
> > git://git.kernel.org/pub/scm/utils/pciutils/pciutils.git that should decode it.
> > Also, "lspci -vvxxx" didn't hexdump this capability, which should be
> > at offset 0x200.  Using "lspci -xxxx" (four "x"s) should dump it, and
> > we can decode it manually.
> >
> 
> You can find this in
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/115378.
> 
> Somehow my System team says that it should be at offset 0x160?
> Is it possible that there is a "walk algorithm" with pointers just like for the
> ASPM register?
> I'll try to check the PCI spec when I'll find the time for that.

So I read a bit the lspci code, and it looks that there are plenty of pointers inside the config space. Fun :)
So basically, since:
#define PCI_EXT_CAP_ID_L1PM        0x1e
This means that I need to find an 0x1e in the output of wzyboy's lspci. I found only one: at offset 0x15d.
Should that mean that my System team was right when they asked for offset 0x160 which is 3 bytes afterwards (and matches more the less the code of lspci)?
If so, 
160: 0f 00 a0 40 f0 00 00 00 00 00 00 00 00 00 00 00 seems to say that it is enabled?

OTOH, 0x15d is 0x1e and not 0x001e as required by PCI-SIG ECN? Me scraping my head.