1. 18 Jan, 2017 1 commit
    • Gavin Shan's avatar
      powerpc/eeh: Enable IO path on permanent error · 387bbc97
      Gavin Shan authored
      
      
      We give up recovery on permanent error, simply shutdown the affected
      devices and remove them. If the devices can't be put into quiet state,
      they spew more traffic that is likely to cause another unexpected EEH
      error. This was observed on "p8dtu2u" machine:
      
         0002:00:00.0 PCI bridge: IBM Device 03dc
         0002:01:00.0 Ethernet controller: Intel Corporation \
                      Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
         0002:01:00.1 Ethernet controller: Intel Corporation \
                      Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
         0002:01:00.2 Ethernet controller: Intel Corporation \
                      Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
         0002:01:00.3 Ethernet controller: Intel Corporation \
                      Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
      
      On P8 PowerNV platform, the IO path is frozen when shutdowning the
      devices, meaning the memory registers are inaccessible. It is why
      the devices can't be put into quiet state before removing them.
      This fixes the issue by enabling IO path prior to putting the devices
      into quiet state.
      Reported-by: default avatarPridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Acked-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      387bbc97
  2. 22 Nov, 2016 2 commits
    • Russell Currey's avatar
      powerpc/eeh: Refactor EEH PE reset functions · 6654c936
      Russell Currey authored
      
      
      eeh_pe_reset and eeh_reset_pe are two different functions in the same
      file which do mostly the same thing.  Not only is this confusing, but
      potentially causes disrepancies in functionality, notably eeh_reset_pe
      as it does not check return values for failure.
      
      Refactor this into the following:
      
       - eeh_pe_reset(): stays as is, performs a single operation, exported
       - eeh_pe_reset_full(): new, full reset process that calls eeh_pe_reset()
       - eeh_reset_pe(): removed and replaced by eeh_pe_reset_full()
       - eeh_reset_pe_once(): removed
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      6654c936
    • Russell Currey's avatar
      powerpc/pci: Always print PHB and PE numbers as hexadecimal · 1f52f176
      Russell Currey authored
      
      
      PHB, PE (and by association MVE) numbers are printed as a mix of decimal
      and hexadecimal throughout the kernel.  This can be misleading, so make
      them all hexadecimal.
      
      Standardising on hex instead of dec because:
      
       - PHB numbers are presented in hex in sysfs/debugfs (and lspci, etc)
       - PE numbers are presented as hex in sysfs and parsed in hex in debugfs
      
      The only place I think this could cause confusing are the messages during
      boot, i.e.
      
      	pci 000a:01     : [PE# 000] Secondary bus 1 associated with PE#0
      
      which can be a quick way to check PE numbers.  pe_level_printk() will
      only print two characters instead of three, so the above would be
      
      	pci 000a:01     : [PE# 00] Secondary bus 1 associated with PE#0
      
      which gives a hint it's in hex.
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1f52f176
  3. 04 Oct, 2016 1 commit
  4. 29 Sep, 2016 2 commits
  5. 09 Aug, 2016 1 commit
  6. 12 May, 2016 2 commits
  7. 11 Apr, 2016 1 commit
  8. 09 Mar, 2016 1 commit
    • Andrew Donnellan's avatar
      powerpc/eeh: eeh_pci_enable(): fix checking of post-request state · 949e9b82
      Andrew Donnellan authored
      
      
      In eeh_pci_enable(), after making the request to set the new options, we
      call eeh_ops->wait_state() to check that the request finished successfully.
      
      At the moment, if eeh_ops->wait_state() returns 0, we return 0 without
      checking that it reflects the expected outcome. This can lead to callers
      further up the chain incorrectly assuming the slot has been successfully
      unfrozen and continuing to attempt recovery.
      
      On powernv, this will occur if pnv_eeh_get_pe_state() or
      pnv_eeh_get_phb_state() return 0, which in turn occurs if the relevant OPAL
      call returns OPAL_EEH_STOPPED_MMIO_DMA_FREEZE or
      OPAL_EEH_PHB_ERROR respectively.
      
      On pseries, this will occur if pseries_eeh_get_state() returns 0, which in
      turn occurs if RTAS reports that the PE is in the MMIO Stopped and DMA
      Stopped states.
      
      Obviously, none of these cases represent a successful completion of a
      request to thaw MMIO or DMA.
      
      Fix the check so that a wait_state() return value of 0 won't be considered
      successful for the EEH_OPT_THAW_MMIO or EEH_OPT_THAW_DMA cases.
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Reviewed-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      949e9b82
  9. 08 Mar, 2016 4 commits
  10. 08 Feb, 2016 1 commit
  11. 21 Oct, 2015 1 commit
  12. 15 Oct, 2015 1 commit
  13. 12 Oct, 2015 1 commit
    • Aneesh Kumar K.V's avatar
      powerpc/mm: Differentiate between hugetlb and THP during page walk · 891121e6
      Aneesh Kumar K.V authored
      We need to properly identify whether a hugepage is an explicit or
      a transparent hugepage in follow_huge_addr(). We used to depend
      on hugepage shift argument to do that. But in some case that can
      result in wrong results. For ex:
      
      On finding a transparent hugepage we set hugepage shift to PMD_SHIFT.
      But we can end up clearing the thp pte, via pmdp_huge_get_and_clear.
      We do prevent reusing the pfn page via the usage of
      kick_all_cpus_sync(). But that happens after we updated the pte to 0.
      Hence in follow_huge_addr() we can find hugepage shift set, but transparent
      huge page check fail for a thp pte.
      
      NOTE: We fixed a variant of this race against thp split in commit
      691e95fd
      
      
      ("powerpc/mm/thp: Make page table walk safe against thp split/collapse")
      
      Without this patch, we may hit the BUG_ON(flags & FOLL_GET) in
      follow_page_mask occasionally.
      
      In the long term, we may want to switch ppc64 64k page size config to
      enable CONFIG_ARCH_WANT_GENERAL_HUGETLB
      Reported-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      891121e6
  14. 28 Aug, 2015 1 commit
    • Gavin Shan's avatar
      powerpc/eeh: Fix fenced PHB caused by eeh_slot_error_detail() · 25980013
      Gavin Shan authored
      The config space of some PCI devices can't be accessed when their
      PEs are in frozen state. Otherwise, fenced PHB might be seen.
      Those PEs are identified with flag EEH_PE_CFG_RESTRICTED, meaing
      EEH_PE_CFG_BLOCKED is set automatically when the PE is put to
      frozen state (EEH_PE_ISOLATED). eeh_slot_error_detail() restores
      PCI device BARs with eeh_pe_restore_bars(), which then calls
      eeh_ops->restore_config() to reinitialize the PCI device in
      (OPAL) firmware. eeh_ops->restore_config() produces PCI config
      access that causes fenced PHB. The problem was reported on below
      adapter:
      
         0001:01:00.0 0200: 14e4:168e (rev 10)
         0001:01:00.0 Ethernet controller: Broadcom Corporation \
                      NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
      
      This fixes the issue by skipping eeh_pe_restore_bars() in
      eeh_slot_error_detail() when EEH_PE_CFG_BLOCKED is set for the PE.
      
      Fixes: b6541db1
      
       ("powerpc/eeh: Block PCI config access upon frozen PE")
      Cc: stable@vger.kernel.org # v4.0+
      Reported-by: default avatarManvanthara B. Puttashankar <mputtash@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      25980013
  15. 18 Aug, 2015 1 commit
    • Gavin Shan's avatar
      powerpc/eeh: Disable automatically blocked PCI config · 39bfd715
      Gavin Shan authored
      
      
      pcibios_set_pcie_reset_state() could be called to complete
      reset request when passing through PCI device, flag
      EEH_PE_ISOLATED is set before saving the PCI config sapce.
      On some Broadcom adapters, EEH_PE_CFG_BLOCKED is automatically
      set when the flag EEH_PE_ISOLATED is marked. It caused bogus
      data saved from the PCI config space, which will be restored
      to the PCI adapter after the reset. Eventually, the hardware
      can't work with corrupted data in PCI config space.
      
      The patch fixes the issue with eeh_pe_state_mark_no_cfg(), which
      doesn't set EEH_PE_CFG_BLOCKED when seeing EEH_PE_ISOLATED on the
      PE, in order to avoid the bogus data saved and restored to the PCI
      config space.
      Reported-by: default avatarRajanikanth H. Adaveeshaiah <rajanikanth.ha@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      39bfd715
  16. 14 Aug, 2015 1 commit
    • Daniel Axtens's avatar
      powerpc/eeh: Probe after unbalanced kref check · e642d11b
      Daniel Axtens authored
      In the complete hotplug case, EEH PEs are supposed to be released
      and set to NULL. Normally, this is done by eeh_remove_device(),
      which is called from pcibios_release_device().
      
      However, if something is holding a kref to the device, it will not
      be released, and the PE will remain. eeh_add_device_late() has
      a check for this which will explictly destroy the PE in this case.
      
      This check in eeh_add_device_late() occurs after a call to
      eeh_ops->probe(). On PowerNV, probe is a pointer to pnv_eeh_probe(),
      which will exit without probing if there is an existing PE.
      
      This means that on PowerNV, devices with outstanding krefs will not
      be rediscovered by EEH correctly after a complete hotplug. This is
      affecting CXL (CAPI) devices in the field.
      
      Put the probe after the kref check so that the PE is destroyed
      and affected devices are correctly rediscovered by EEH.
      
      Fixes: d91dafc0
      
       ("powerpc/eeh: Delay probing EEH device during hotplug")
      Cc: stable@vger.kernel.org
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Acked-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      e642d11b
  17. 11 Jun, 2015 1 commit
  18. 07 Jun, 2015 1 commit
  19. 13 May, 2015 1 commit
  20. 12 May, 2015 1 commit
  21. 01 May, 2015 2 commits
  22. 17 Apr, 2015 1 commit
    • Aneesh Kumar K.V's avatar
      powerpc/mm/thp: Make page table walk safe against thp split/collapse · 691e95fd
      Aneesh Kumar K.V authored
      
      
      We can disable a THP split or a hugepage collapse by disabling irq.
      We do send IPI to all the cpus in the early part of split/collapse,
      and disabling local irq ensure we don't make progress with
      split/collapse. If the THP is getting split we return NULL from
      find_linux_pte_or_hugepte(). For all the current callers it should be ok.
      We need to be careful if we want to use returned pte_t pointer outside
      the irq disabled region. W.r.t to THP split, the pfn remains the same,
      but then a hugepage collapse will result in a pfn change. There are
      few steps we can take to avoid a hugepage collapse.One way is to take page
      reference inside the irq disable region. Other option is to take
      mmap_sem so that a parallel collapse will not happen. We can also
      disable collapse by taking pmd_lock. Another method used by kvm
      subsystem is to check whether we had a mmu_notifer update in between
      using mmu_notifier_retry().
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      691e95fd
  23. 14 Apr, 2015 1 commit
  24. 24 Mar, 2015 3 commits
  25. 16 Mar, 2015 1 commit
    • Gavin Shan's avatar
      powerpc/eeh: Enhance pcibios_set_pcie_reset_state() · 28158cd1
      Gavin Shan authored
      
      
      Function pcibios_set_pcie_reset_state() is possibly called by
      pci_reset_function(), on which VFIO infrastructure depends to
      issue reset. pcibios_set_pcie_reset_state() is issuing reset
      on the parent PE of the indicated PCI device. The reset causes
      state lost on all PCI devices except the indicated one as the
      argument to pcibios_set_pcie_reset_state(). Also, sideband
      MMIO access from guest when issuing reset would cause unexpected
      EEH error.
      
      For above two issues, the patch applies following enhancements
      to pcibios_set_pcie_reset_state():
      
         * For all PCI devices except the indicated one, save their
           state prior to reset and restore state after that.
         * Explicitly freeze PE prior to reset and unfreeze it after
           that, in order to avoid unexpected EEH error.
      Tested-by: default avatarPriya M. A <priyama2@in.ibm.com>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      28158cd1
  26. 23 Jan, 2015 1 commit
  27. 02 Dec, 2014 5 commits