1. 28 Apr, 2012 4 commits
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · cd88e3a6
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "As soon as I sent the non-urgent stack, two important fixes come in:
         - i915: fixes SNB GPU hangs in a number of 3D apps
         - radeon: initial fix for VGA on LLano system, 3 or 4 of us have
           spent time debugging this, and Jerome finally figured out the magic
           bit the BIOS/fglrx set that we didn't.  This at least should get
           things working, there may be future reliability fixes."
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
        drm/radeon/kms: need to set up ss on DP bridges as well
    • Linus Torvalds's avatar
      Revert "autofs: work around unhappy compat problem on x86-64" · fcbf94b9
      Linus Torvalds authored
      This reverts commit a32744d4
      While that commit was technically the right thing to do, and made the
      x86-64 compat mode work identically to native 32-bit mode (and thus
      fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
      turns out that the automount binaries had workarounds for this compat
      Now, the workarounds are disgusting: doing an "uname()" to find out the
      architecture of the kernel, and then comparing it for the 64-bit cases
      and fixing up the size of the read() in automount for those.  And they
      were confused: it's not actually a generic 64-bit issue at all, it's
      very much tied to just x86-64, which has different alignment for an
      'u64' in 64-bit mode than in 32-bit mode.
      But the end result is that fixing the compat layer actually breaks the
      case of a 32-bit automount on a x86-64 kernel.
      There are various approaches to fix this (including just doing a
      "strcmp()" on current->comm and comparing it to "automount"), but I
      think that I will do the one that teaches pipes about a special "packet
      mode", which will allow user space to not have to care too deeply about
      the padding at the end of the autofs packet.
      That change will make the compat workaround unnecessary, so let's revert
      it first, and get automount working again in compat mode.  The
      packetized pipes will then fix autofs for systemd.
      Reported-and-requested-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Cc: Ian Kent <raven@themaw.net>
      Cc: stable@kernel.org # for 3.3
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Kenneth Graunke's avatar
      drm/i915: Set the Stencil Cache eviction policy to non-LRA mode. · 3a69ddd6
      Kenneth Graunke authored
      Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
      OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
      using separate stencil buffers.  Without it, the GPU tries to use the
      LRA eviction policy, which isn't supported.  This was supposed to be off
      by default, but seems to be on for many machines.
      This cannot be done in gen6_init_clock_gating with most of the other
      workaround bits; the render ring needs to exist.  Otherwise, the
      register write gets dropped on the floor (one printk will show it
      changed, but a second printk immediately following shows the value
      reverts to the old one).
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
      Cc: stable@vger.kernel.org
      Cc: Rob Castle <futuredub@gmail.com>
      Cc: Eric Appleman <erappleman@gmail.com>
      Cc: aaron667@gmx.net
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Alex Deucher's avatar
      drm/radeon/kms: need to set up ss on DP bridges as well · 700698e7
      Alex Deucher authored
      Makes Nutmeg DP to VGA bridges work for me.
      Noticed by Jerome Glisse (after weeks of debugging).
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  2. 27 Apr, 2012 30 commits
  3. 26 Apr, 2012 6 commits
    • Konrad Rzeszutek Wilk's avatar
      xen/acpi: Workaround broken BIOSes exporting non-existing C-states. · b930fe5e
      Konrad Rzeszutek Wilk authored
      We did a similar check for the P-states but did not do it for
      the C-states. What we want to do is ignore cases where the DSDT
      has definition for sixteen CPUs, but the machine only has eight
      CPUs and we get:
      xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14
      Reported-by: default avatarTobias Geiger <tobias.geiger@vido.info>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    • Konrad Rzeszutek Wilk's avatar
      xen/smp: Fix crash when booting with ACPI hotplug CPUs. · cf405ae6
      Konrad Rzeszutek Wilk authored
      When we boot on a machine that can hotplug CPUs and we
      are using 'dom0_max_vcpus=X' on the Xen hypervisor line
      to clip the amount of CPUs available to the initial domain,
      we get this:
      (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
      .. snip..
      DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
      .. snip.
      SMP: Allowing 64 CPUs, 32 hotplug CPUs
      installing Xen timer for CPU 7
      cpu 7 spinlock event irq 361
      NMI watchdog: disabled (cpu7): hardware events not enabled
      Brought up 8 CPUs
      .. snip..
      	[acpi processor finds the CPUs are not initialized and starts calling
      	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
      CPU 8 got hotplugged
      CPU 9 got hotplugged
      CPU 10 got hotplugged
      .. snip..
      initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
      calling  erst_init+0x0/0x2bb @ 1
      	[and the scheduler sticks newly started tasks on the new CPUs, but
      	said CPUs cannot be initialized b/c the hypervisor has limited the
      	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
      	The spinlock tries to kick the other CPU, but the structure for that
      	is not initialized and we crash.]
      BUG: unable to handle kernel paging request at fffffffffffffed8
      IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      PGD 180d067 PUD 180e067 PMD 0
      Oops: 0002 [#1] SMP
      CPU 7
      Modules linked in:
      Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
      RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282
      With this patch, we cap the amount of vCPUS that the initial domain
      can run, to exactly what dom0_max_vcpus=X has specified.
      In the future, if there is a hypercall that will allow a running
      domain to expand past its initial set of vCPUS, this patch should
      be re-evaluated.
      CC: stable@kernel.org
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    • Paul Mundt's avatar
    • Nobuhiro Iwamatsu's avatar
      sh: Fix up tracepoint build fallout from static key introduction. · ec2ccd88
      Nobuhiro Iwamatsu authored
      With the introduction of static keys, anything using tracepoints blows up
      in the following manner:
      include/trace/events/oom.h:8:13: error: initializer element is not constant
      include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update')
      include/trace/events/oom.h:8:13: error: initializer element is not constant
      include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update.key')
      This is a result of the STATIC_KEY_INIT_xxx defs wrapping ATOMIC_INIT()
      which on sh includes an atomic_t typecast. Given that we don't really
      need the typecast for anything anymore, the simplest solution is simply
      to kill off the cast.
      Signed-off-by: default avatarNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
    • Linus Torvalds's avatar
      Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile · 82b76906
      Linus Torvalds authored
      Pull arch/tile fixes from Chris Metcalf:
       "One change fixes a platform-independent bug about environment var
        handling in the boot command line.  The other is a trivial
        tile-specific bug fix to avoid a link-time warning."
      * 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
        arch/tile: fix a couple of functions that should be __init
        init: fix bug where environment vars can't be passed via boot args
    • Linus Torvalds's avatar
      Merge tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband · ebcf596d
      Linus Torvalds authored
      Pull infiniband fixes from Roland Dreier:
       "A few fixes for regressions introduced in 3.4-rc1:
         - fix memory leak in mlx4
         - fix two problems with new MAD response generation code"
      * tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
        IB/mlx4: Fix memory leaks in ib_link_query_port()
        IB/mad: Don't send response for failed MADs
        IB/mad: Set 'D' bit in response for unhandled MADs