1. 27 6月, 2013 1 次提交
  2. 26 6月, 2013 20 次提交
  3. 12 6月, 2013 5 次提交
  4. 11 6月, 2013 6 次提交
  5. 10 6月, 2013 8 次提交
    • K
      xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it. · b2c75c44
      Konrad Rzeszutek Wilk 提交于
      Commit 10a7a077 ("xen: tmem: enable Xen
      tmem shim to be built/loaded as a module") allows the tmem module
      to be loaded any time. For this work the frontswap API had to
      be able to asynchronously to call tmem_frontswap_init before
      or after the swap image had been set. That was added in git
      commit 905cd0e1
      ("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").
      
      Which means we could do this (The common case):
      
       modprobe tmem		[so calls frontswap_register_ops, no ->init]
      			 modifies tmem_frontswap_poolid = -1
       swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
      			 < 0 so tmem hypercall done]
      
      Or the failing one:
      
       swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
       modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
      			tmem_frontswap_poolid is 0, does not make a hypercall.
      			Later in the module_init, sets tmem_frontswap_poolid=-1]
      
      Which meant that in the failing case we would not call the hypercall
      to initialize the pool and never be able to make any frontswap
      backend calls.
      
      Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
      fixes it.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: NBob Liu <bob.liu@oracle.com>
      b2c75c44
    • D
      drm/i915: prefer VBT modes for SVDO-LVDS over EDID · c3456fb3
      Daniel Vetter 提交于
      In
      
      commit 53d3b4d7
      Author: Egbert Eich <eich@suse.de>
      Date:   Tue Jun 4 17:13:21 2013 +0200
      
          drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC
      
      Egbert Eich fixed a long-standing bug where we simply used a
      non-working i2c controller to read the EDID for SDVO-LVDS panels.
      Unfortunately some machines seem to not be able to cope with the mode
      provided in the EDID. Specifically they seem to not be able to cope
      with a 4x pixel mutliplier instead of a 2x one, which seems to have
      been worked around by slightly changing the panels native mode in the
      VBT so that the dotclock is just barely above 50MHz.
      
      Since it took forever to notice the breakage it's fairly safe to
      assume that at least for SDVO-LVDS panels the VBT contains fairly sane
      data. So just switch around the order and use VBT modes first.
      
      v2: Also add EDID modes just in case, and spell Egbert correctly.
      
      v3: Elaborate a bit more about what's going on on Chris' machine.
      
      Cc: Egbert Eich <eich@suse.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c3456fb3
    • C
      drm/i915: Enable hotplug interrupts after querying hw capabilities. · 7ba220ce
      Chris Wilson 提交于
      sdvo->hotplug_active is initialised during intel_sdvo_setup_outputs(),
      and so we never enabled the hotplug interrupts on SDVO as we were
      checking too early.
      
      This regression has been introduced somewhere in the hpd rework for
      the storm detection and handling starting with
      
      commit 1d843f9d
      Author: Egbert Eich <eich@suse.de>
      Date:   Mon Feb 25 12:06:49 2013 -0500
      
          DRM/I915: Add enum hpd_pin to intel_encoder.
      
      and the follow-up patches to use the new encoder->hpd_pin variable for
      the different irq setup functions.
      
      The problem is that encoder->hpd_pin was set up _before_ the output
      setup was done and so before we could assess the hotplug capabilities
      of the outputs on an sdvo encoder.
      Reported-by: NAlex Fiestas <afiestas@kde.org>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add regression note.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7ba220ce
    • C
      drm/i915: Fix hotplug interrupt enabling for SDVOC · 7ee2aff3
      Chris Wilson 提交于
      A broken conditional would lead to SDVOC waiting upon hotplug events on
      SDVOB - and so miss all activity on its SDVO port.
      
      This regression has been introduced in
      
      commit 1d843f9d
      Author: Egbert Eich <eich@suse.de>
      Date:   Mon Feb 25 12:06:49 2013 -0500
      
          DRM/I915: Add enum hpd_pin to intel_encoder.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=58405Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add regression note.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7ee2aff3
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc · ae75d84f
      Linus Torvalds 提交于
      Pull powerpc fixes from Benjamin Herrenschmidt:
       "This is purely regressions (though not all recent ones) or stable
        material"
      
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
        powerpc: Partial revert of "Context switch more PMU related SPRs"
        powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
        powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
        powerpc/power8: Update denormalization handler
        powerpc/pseries: Simplify denormalization handler
        powerpc/power8: Fix oprofile and perf
        powerpc/eeh: Don't check RTAS token to get PE addr
        powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources
      ae75d84f
    • L
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 0b52a3c8
      Linus Torvalds 提交于
      Pull ARM fixes from Russell King:
       "The biggest two fixes are fixing a compilation error with the
        decompressor, and a problem with our __my_cpu_offset implementation.
      
        Other changes are very trivial and small, which seems to be the way
        for most -rc stuff."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7747/1: pcpu: ensure __my_cpu_offset cannot be re-ordered across barrier()
        ARM: 7750/1: update legacy CPU ID in decompressor cache support jump table
        ARM: 7743/1: compressed/head.S: work around new binutils warning
        ARM: 7742/1: topology: export cpu_topology
        ARM: 7737/1: fix kernel decompressor compilation error with CONFIG_DEBUG_SEMIHOSTING
      0b52a3c8
    • M
      powerpc: Partial revert of "Context switch more PMU related SPRs" · b11ae951
      Michael Ellerman 提交于
      In commit 59affcd3 I added context switching of more PMU SPRs, because
      they are potentially exposed to userspace on Power8. However despite me
      being a smart arse in the commit message it's actually not correct. In
      particular it interacts badly with a global perf record.
      
      We will have to do something more complicated, but that will have to
      wait for 3.11.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b11ae951
    • M
      powerpc/perf: Fix deadlock caused by calling printk() in PMU exception · 6772faa1
      Michael Ellerman 提交于
      In commit bc09c219 "Fix finding overflowed PMC in interrupt" we added
      a printk() to the PMU exception handler. Unfortunately that is not safe.
      
      The problem is that the PMU exception may run even when interrupts are
      soft disabled, aka NMI context. We do this so that we can profile parts
      of the kernel that have interrupts soft-disabled.
      
      But by calling printk() from the exception handler, we can potentially
      deadlock in the printk code on logbuf_lock, eg:
      
        [c00000038ba575c0] c000000000081928 .vprintk_emit+0xa8/0x540
        [c00000038ba576a0] c0000000007bcde8 .printk+0x48/0x58
        [c00000038ba57710] c000000000076504 .perf_event_interrupt+0x2d4/0x490
        [c00000038ba57810] c00000000001f6f8 .performance_monitor_exception+0x48/0x60
        [c00000038ba57880] c0000000000032cc performance_monitor_common+0x14c/0x180
        --- Exception: f01 (Performance Monitor) at c0000000007b25d4 ._raw_spin_lock_irq
        +0x64/0xc0
        [c00000038ba57bf0] c00000000007ed90 .devkmsg_read+0xd0/0x5a0
        [c00000038ba57d00] c0000000001c2934 .vfs_read+0xc4/0x1e0
        [c00000038ba57d90] c0000000001c2cd8 .SyS_read+0x58/0xd0
        [c00000038ba57e30] c000000000009d54 syscall_exit+0x0/0x98
        --- Exception: c01 (System Call) at 00001fffffbf6f7c
        SP (3ffff6d4de10) is in userspace
      
      Fix it by making sure we only call printk() when we are not in NMI
      context.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Cc: <stable@vger.kernel.org> # 3.9
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6772faa1