1. 13 Dec, 2011 1 commit
    • Rafael J. Wysocki's avatar
      PCI hotplug: Always allow acpiphp to handle non-PCIe bridges · 619a5182
      Rafael J. Wysocki authored
      Commit 0d52f54e (PCI / ACPI: Make
      acpiphp ignore root bridges using PCIe native hotplug) added code
      that made the acpiphp driver completely ignore PCIe root complexes
      for which the kernel had been granted control of the native PCIe
      hotplug feature by the BIOS through _OSC.  Unfortunately, however,
      this was a mistake, because on some systems there were PCI bridges
      supporting PCI (non-PCIe) hotplug under such root complexes and
      those bridges should have been handled by acpiphp.
      
      For this reason, revert the changes made by the commit mentioned
      above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c
      avoid registering hotplug slots for PCIe ports that belong to
      root complexes with native PCIe hotplug enabled (which means that
      the BIOS has granted the kernel control of this feature for the
      given root complex).  This is reported to address the original
      issue fixed by commit 0d52f54e and
      to work on the system where that commit broke things.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      619a5182
  2. 05 Dec, 2011 2 commits
    • James Bottomley's avatar
      PCI: fix ats compile failure · 8c451945
      James Bottomley authored
      I get this compile failure on parisc:
      
      drivers/pci/ats.c: In function 'ats_alloc_one':
      drivers/pci/ats.c:29: error: implicit declaration of function 'kzalloc'
      drivers/pci/ats.c:29: warning: assignment makes pointer from integer without a cast
      drivers/pci/ats.c: In function 'ats_free_one':
      drivers/pci/ats.c:45: error: implicit declaration of function 'kfree'
      
      Because ats.c is missing linux/slab.h as an include.  This patch fixes it
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      8c451945
    • Ram Pai's avatar
      PCI: defer enablement of SRIOV BARS · bbef98ab
      Ram Pai authored
      All the PCI BARs of a device are enabled when the device is enabled
      using pci_enable_device().  This unnecessarily enables SRIOV BARs of the
      device.
      
      On some platforms, which do not support SRIOV as yet, the
      pci_enable_device() fails to enable the device if its SRIOV BARs are not
      allocated resources correctly.
      
      The following patch fixes the above problem. The SRIOV BARs are now
      enabled when IOV capability of the device is enabled in sriov_enable().
      
      NOTE: Note, there is subtle change in the pci_enable_device() API.  Any
      driver that depends on SRIOV BARS to be enabled in pci_enable_device()
      can fail.
      
      The patch has been touch tested on power and x86 platform.
      Tested-by: default avatarMichael Wang <wangyun@linux.vnet.ibm.com>
      Signed-off-by: default avatarRam Pai <linuxram@us.ibm.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      bbef98ab
  3. 04 Dec, 2011 1 commit
    • Linus Torvalds's avatar
      x86: Fix boot failures on older AMD CPU's · 8e8da023
      Linus Torvalds authored
      People with old AMD chips are getting hung boots, because commit
      bcb80e53 ("x86, microcode, AMD: Add microcode revision to
      /proc/cpuinfo") moved the microcode detection too early into
      "early_init_amd()".
      
      At that point we are *so* early in the booth that the exception tables
      haven't even been set up yet, so the whole
      
      	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
      
      doesn't actually work: if the rdmsr does a GP fault (due to non-existant
      MSR register on older CPU's), we can't fix it up yet, and the boot fails.
      
      Fix it by simply moving the code to a slightly later point in the boot
      (init_amd() instead of early_init_amd()), since the kernel itself
      doesn't even really care about the microcode patchlevel at this point
      (or really ever: it's made available to user space in /proc/cpuinfo, and
      updated if you do a microcode load).
      Reported-tested-and-bisected-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Tested-by: default avatarBob Tracy <rct@gherkin.frus.com>
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8e8da023
  4. 03 Dec, 2011 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/pm_idle: Make pm_idle be default_idle under Xen. · e5fd47bf
      Konrad Rzeszutek Wilk authored
      The idea behind commit d91ee586 ("cpuidle: replace xen access to x86
      pm_idle and default_idle") was to have one call - disable_cpuidle()
      which would make pm_idle not be molested by other code.  It disallows
      cpuidle_idle_call to be set to pm_idle (which is excellent).
      
      But in the select_idle_routine() and idle_setup(), the pm_idle can still
      be set to either: amd_e400_idle, mwait_idle or default_idle.  This
      depends on some CPU flags (MWAIT) and in AMD case on the type of CPU.
      
      In case of mwait_idle we can hit some instances where the hypervisor
      (Amazon EC2 specifically) sets the MWAIT and we get:
      
        Brought up 2 CPUs
        invalid opcode: 0000 [#1] SMP
      
        Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
        RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
        ...
        Call Trace:
         [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
         [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
        RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
         RSP <ffff8801d28ddf10>
      
      In the case of amd_e400_idle we don't get so spectacular crashes, but we
      do end up making an MSR which is trapped in the hypervisor, and then
      follow it up with a yield hypercall.  Meaning we end up going to
      hypervisor twice instead of just once.
      
      The previous behavior before v3.0 was that pm_idle was set to
      default_idle regardless of select_idle_routine/idle_setup.
      
      We want to do that, but only for one specific case: Xen.  This patch
      does that.
      
      Fixes RH BZ #739499 and Ubuntu #881076
      Reported-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e5fd47bf
  5. 02 Dec, 2011 14 commits
  6. 01 Dec, 2011 21 commits