1. 22 Oct, 2004 2 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Fix boot on some non-LPAR pSeries · 7923a9d6
      Benjamin Herrenschmidt authored
      This patch fixes a problem when allocating the TCE tables (iommu) during
      early boot on some non-LPAR machines with a lot of memory.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7923a9d6
    • Paul Mackerras's avatar
      [PATCH] PPC64 remove __ioremap_explicit() error message · 577e92ea
      Paul Mackerras authored
      This patch, from John Rose, is the counterpart of one recently
      forwarded by Greg KH.  It has the same description, but isn't the same
      patch - this is the arch/ppc64 part of the change.
      
      As an unfortunate side effect of runtime addition/removal of PCI Host Bridges,
      the RPA DLPAR driver can no longer depend on the success of ioremap_explicit()
      (and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot.  
      
      Without addressing this, an attempt to add the first child slot of a newly
      added PHB will fail when __ioremap_explicit() determines the mappings for that
      range to already exist.
      
      For a little context, __ioremap_explicit() creates mappings for the range of a
      newly added slot.  Here's why these calls will be expected to fail in some
      cases.  Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for
      the entire range spanned by each PHB.  Consider the following scenarios of
      DLPAR-adding an I/O slot.
      
      1) Just after boot, one removes an I/O slot.  At this point the range
         associated with the parent PHB is fragmented, and the child range for the
         slot in question is iounmap()'ed.  One then re-adds the slot, at which point
         remap_page_range()/ioremap_explicit() restores the mappings that were
         previously removed.
      
      2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the
         entire PHB range.  One then performs a DLPAR-add of a child slot of that
         PHB.  At this point, mappings already exist for the range of the slot to
         be added.  So remap_page_range()/ioremap_explicit() will fail at this point.
      
      The problem is, there's not a good way to distinguish between cases 1 and 2
      from the perspective of the DLPAR driver.  Because of that, I believe the
      correct solution to be:
      
      - Removal of relevant error prints from iounmap_explicit(), which is only used
        for DLPAR.
      - Removal of error code checks from the RPA driver
      
      Here's the first of these.
      Signed-off-by: default avatarJohn Rose <johnrose@austin.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      577e92ea
  2. 21 Oct, 2004 10 commits
  3. 22 Oct, 2004 2 commits
  4. 21 Oct, 2004 26 commits