All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 24 Sep, 2015 3 commits
  2. 22 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Clear IORESOURCE_UNSET when clipping a bridge window · b838b39e
      Bjorn Helgaas authored
      c770cb4c ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET
      if we fail to claim a resource.  If we tried to claim a bridge window,
      failed, clipped the window, and tried to claim the clipped window, we
      failed again because of IORESOURCE_UNSET:
        pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window]
        pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window
        pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0:   bridge window [mem size 0x1df00000 64bit pref]
        pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned
      The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref].  That
      starts before the host bridge window [mem 0xc0000000-0xffffffff window], so
      we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref].
      But we left it marked IORESOURCE_UNSET, so the second claim failed when it
      should have succeeded.
      This means downstream devices will also fail for lack of resources, e.g.,
      in the bugzilla below,
        radeon 0000:01:00.0: Fatal error during GPU init
      Clear IORESOURCE_UNSET when we clip a bridge window.  Also clear
      IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly
      what the original window was and how it now fits inside the upstream
      Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
      Link: default avatarLorenzo Pieralisi <>
      Based-on-patch-by: default avatarYinghai Lu <>
      Tested-by: default avatarLorenzo Pieralisi <>
      Signed-off-by: default avatarBjorn Helgaas <>
      Reviewed-by: default avatarLorenzo Pieralisi <>
      Acked-by: default avatarYinghai Lu <>
      CC:	# v4.1+
  3. 15 Sep, 2015 1 commit
    • Bjorn Helgaas's avatar
      PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code" · 237865f1
      Bjorn Helgaas authored
      Revert dff22d20 ("PCI: Call pci_read_bridge_bases() from core instead
      of arch code").
      Reading PCI bridge windows is not arch-specific in itself, but there is PCI
      core code that doesn't work correctly if we read them too early.  For
      example, Hannes found this case on an ARM Freescale i.mx6 board:
        pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
        pci 0000:00:00.0: PCI bridge to [bus 01-ff]
        pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
        pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
        pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
        pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]
      The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
      0x204100 of space, and mem windows are megabyte-aligned.
      Bus sizing can increase a bridge window size, but never *decrease* it (see
      d65245c3 ("PCI: don't shrink bridge resources")).  Prior to
      dff22d20, ARM didn't read bridge windows at all, so the "original size"
      was zero, and we assigned a 3MB window.
      After dff22d20, we read the bridge windows before sizing the bus.  The
      firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
      we never decrease the size, we kept 16MB even though we only needed 3MB.
      But 16MB doesn't fit in the host bridge aperture, so we failed to assign
      space for the window and the downstream devices.
      I think this is a defect in the PCI core: we shouldn't rely on the firmware
      to assign sensible windows.
      Ray reported a similar problem, also on ARM, with Broadcom iProc.
      Issues like this are too hard to fix right now, so revert dff22d20.
      Reported-by: default avatarHannes <>
      Reported-by: default avatarRay Jui <>
      Link: default avatarBjorn Helgaas <>
      Acked-by: default avatarYinghai Lu <>
      Acked-by: default avatarLorenzo Pieralisi <>
  4. 11 Sep, 2015 10 commits
  5. 10 Sep, 2015 17 commits
  6. 09 Sep, 2015 8 commits