1. 12 Nov, 2010 1 commit
    • Bjorn Helgaas's avatar
      PCI: fix pci_bus_alloc_resource() hang, prefer positive decode · 82e3e767
      Bjorn Helgaas authored
      When a PCI bus has two resources with the same start/end, e.g.,
      
          pci_bus 0000:04: resource 2 [mem 0xd0000000-0xd7ffffff pref]
          pci_bus 0000:04: resource 7 [mem 0xd0000000-0xd7ffffff]
      
      the previous pci_bus_find_resource_prev() implementation would alternate
      between them forever:
      
          pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff pref])
              returns [mem 0xd0000000-0xd7ffffff]
          pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff])
              returns [mem 0xd0000000-0xd7ffffff pref]
          pci_bus_find_resource_prev(... [mem 0xd0000000-0xd7ffffff pref])
              returns [mem 0xd0000000-0xd7ffffff]
          ...
      
      This happened because there was no ordering between two resources with the
      same start and end.  A resource that had the same start and end as the
      cursor, but was not itself the cursor, was considered to be before the
      cursor.
      
      This patch fixes the hang by making a fixed ordering between any two
      resources.
      
      In addition, it tries to allocate from positively decoded regions before
      using any subtractively decoded resources.  This means we will use a
      positive decode region before a subtractive decode one, even if it means
      using a smaller address.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=22062Reported-by: default avatarBorislav Petkov <bp@amd64.org>
      Tested-by: default avatarBorislav Petkov <bp@amd64.org>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      82e3e767
  2. 11 Nov, 2010 4 commits
    • Jesse Barnes's avatar
      PCI: read current power state at enable time · 97c145f7
      Jesse Barnes authored
      When we enable a PCI device, we avoid doing a lot of the initial setup
      work if the device's enable count is non-zero.  If we don't fetch the
      power state though, we may later fail to set up MSI due to the unknown
      status.  So pick it up before we short circuit the rest due to a
      pre-existing enable or mismatched enable/disable pair (as happens with
      VGA devices, which are special in a special way).
      Tested-by: default avatarJesse Brandeburg <jesse.brandeburg@gmail.com>
      Reported-by: default avatarDave Airlie <airlied@linux.ie>
      Tested-by: default avatarDave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      97c145f7
    • Martin Wilck's avatar
      PCI: fix size checks for mmap() on /proc/bus/pci files · 3b519e4e
      Martin Wilck authored
      The checks for valid mmaps of PCI resources made through /proc/bus/pci files
      that were introduced in 9eff02e2 have several
      problems:
      
      1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0,
      whereas under /sys/bus/pci/devices, the start of the resource corresponds
      to offset 0. This may lead to false negatives in pci_mmap_fits(), which
      implicitly assumes the /sys/bus/pci/devices layout.
      
      2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads
      to false positives, because pci_mmap_fits() doesn't treat empty resources
      correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT)
      in this case!).
      
      3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus
      WARNINGS for the first resources that don't fit until the correct one is found.
      
      On many controllers the first 2-4 BARs are used, and the others are empty.
      In this case, an mmap attempt will first fail on the non-empty BARs
      (including the "right" BAR because of 1.) and emit bogus WARNINGS because
      of 3., and finally succeed on the first empty BAR because of 2.
      This is certainly not the intended behaviour.
      
      This patch addresses all 3 issues.
      Updated with an enum type for the additional parameter for pci_mmap_fits().
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarMartin Wilck <martin.wilck@ts.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      3b519e4e
    • Bjorn Helgaas's avatar
      x86/PCI: coalesce overlapping host bridge windows · 4723d0f2
      Bjorn Helgaas authored
      Some BIOSes provide PCI host bridge windows that overlap, e.g.,
      
          pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0xffffffff]
          pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xdfffffff]
          pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xffffffff]
      
      If we simply insert these as children of iomem_resource, the second window
      fails because it conflicts with the first, and the third is inserted as a
      child of the first, i.e.,
      
          b0000000-ffffffff PCI Bus 0000:00
            f0000000-ffffffff PCI Bus 0000:00
      
      When we claim PCI device resources, this can cause collisions like this
      if we put them in the first window:
      
          pci 0000:00:01.0: address space collision: [mem 0xff300000-0xff4fffff] conflicts with PCI Bus 0000:00 [mem 0xf0000000-0xffffffff]
      
      Host bridge windows are top-level resources by definition, so it doesn't
      make sense to make the third window a child of the first.  This patch
      coalesces any host bridge windows that overlap.  For the example above,
      the result is this single window:
      
          pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xffffffff]
      
      This fixes a 2.6.34 regression.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=17011Reported-and-tested-by: default avatarAnisse Astier <anisse@astier.eu>
      Reported-and-tested-by: default avatarPramod Dematagoda <pmd.lotr.gandalf@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      4723d0f2
    • Steven Rostedt's avatar
      PCI hotplug: ibmphp: Add check to prevent reading beyond mapped area · ac3abf2c
      Steven Rostedt authored
      While testing various randconfigs with ktest.pl, I hit the following panic:
      
      BUG: unable to handle kernel paging request at f7e54b03
      IP: [<c0d63409>] ibmphp_access_ebda+0x101/0x19bb
      
      Adding printks, I found that the loop that reads the ebda blocks
      can move out of the mapped section.
      
      ibmphp_access_ebda: start=f7e44c00 size=5120 end=f7e46000
      ibmphp_access_ebda: io_mem=f7e44d80 offset=384
      ibmphp_access_ebda: io_mem=f7e54b03 offset=65283
      
      The start of the iomap was at f7e44c00 and had a size of 5120,
      making the end f7e46000. We start with an offset of 0x180 or
      384, giving the first read at 0xf7e44d80. Reading that location
      yields 65283, which is much bigger than the 5120 that was allocated
      and makes the next read at f7e54b03 which is outside the mapped area.
      
      Perhaps this is a bug in the driver, or buggy hardware, but this patch
      is more about not crashing my box on start up and just giving a warning
      if it detects this error.
      
      This patch at least lets my box boot with just a warning.
      
      Cc: Chandru Siddalingappa <chandru@linux.vnet.ibm.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      ac3abf2c
  3. 09 Nov, 2010 5 commits
  4. 08 Nov, 2010 17 commits
  5. 06 Nov, 2010 7 commits
  6. 05 Nov, 2010 6 commits