1. 16 5月, 2011 3 次提交
    • C
      drm: Take lock around probes for drm_fb_helper_hotplug_event · 752d2635
      Chris Wilson 提交于
      We need to hold the dev->mode_config.mutex whilst detecting the output
      status. But we also need to drop it for the call into
      drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
      attaching the fbcon.
      
      Failure to do so exposes a race with normal output probing. Detected by
      adding some warnings that the mutex is held to the backend detect routines:
      
      [   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
      [   17.772458] Hardware name: Latitude E6400
      [   17.772460] Modules linked in: ....
      [   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
      [   17.772584] Call Trace:
      [   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
      [   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
      [   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
      [   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
      [   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
      [   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
      [   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
      [   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
      [   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
      [   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
      [   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
      [   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
      [   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
      [   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
      Reported-by: NFrederik Himpe <fhimpe@telenet.be>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      752d2635
    • A
      drm/i915: Revert i915.semaphore=1 default from 47ae63e0 · 8eea1be1
      Andy Lutomirski 提交于
      My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
      instantly when GNOME loads and it hangs so hard the reset button
      doesn't work.  Setting i915.semaphore=0 fixes it.
      
      Semaphores were disabled in a1656b90
      in 2.6.38 and were re-enabled by
      
      commit 47ae63e0
      Merge: c59a333f 467cffba
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Mar 7 12:32:44 2011 +0000
      
          Merge branch 'drm-intel-fixes' into drm-intel-next
      
          Apply the trivial conflicting regression fixes, but keep GPU semaphores
          enabled.
      
          Conflicts:
              drivers/gpu/drm/i915/i915_drv.h
              drivers/gpu/drm/i915/i915_gem_execbuffer.c
      
      (It's worth noting that the offending change is i915_drv.c,
       which is not a conflict.)
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Acked-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8eea1be1
    • F
      vga_switcheroo: don't toggle-switch devices · a67b8887
      Florian Mickler 提交于
      If the requested device is already active, ignore the request.
      
      This restores the original behaviour of the interface. The change was
      probably an unintended side effect of
      
      commit 66b37c67 vga_switcheroo: split switching into two stages
      
      which did not take into account to duplicate the !active check in the split-off
      stage2.
      
      Fix this by factoring that check out of stage1 into the debugfs_write routine.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=34252Reported-by: NIgor Murzov <e-mail@date.by>
      Tested-by: NIgor Murzov <e-mail@date.by>
      Signed-off-by: NFlorian Mickler <florian@mickler.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a67b8887
  2. 15 5月, 2011 4 次提交
    • T
      libata: fix oops when LPM is used with PMP · 5f6f12cc
      Tejun Heo 提交于
      ae01b249 (libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65)
      added ATA_FLAG_NO_DIPM and made ata_eh_set_lpm() check the flag.
      However, @ap is NULL if @link points to a PMP link and thus the
      unconditional @ap->flags dereference leads to the following oops.
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
        IP: [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
        ...
        Pid: 295, comm: scsi_eh_4 Tainted: P            2.6.38.5-core2 #1 System76, Inc. Serval Professional/Serval Professional
        RIP: 0010:[<ffffffff813f98e1>]  [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
        RSP: 0018:ffff880132defbf0  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: ffff880132f40000 RCX: 0000000000000000
        RDX: ffff88013377c000 RSI: ffff880132f40000 RDI: 0000000000000000
        RBP: ffff880132defce0 R08: ffff88013377dc58 R09: ffff880132defd98
        R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000
        R13: 0000000000000000 R14: ffff88013377c000 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff8800bf700000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000018 CR3: 0000000001a03000 CR4: 00000000000406e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process scsi_eh_4 (pid: 295, threadinfo ffff880132dee000, task ffff880133b416c0)
        Stack:
         0000000000000000 ffff880132defcc0 0000000000000000 ffff880132f42738
         ffffffff813ee8f0 ffffffff813eefe0 ffff880132defd98 ffff88013377f190
         ffffffffa00b3e30 ffffffff813ef030 0000000032defc60 ffff880100000000
        Call Trace:
         [<ffffffff81400867>] sata_pmp_error_handler+0x607/0xc30
         [<ffffffffa00b273f>] ahci_error_handler+0x1f/0x70 [libahci]
         [<ffffffff813faade>] ata_scsi_error+0x5be/0x900
         [<ffffffff813cf724>] scsi_error_handler+0x124/0x650
         [<ffffffff810834b6>] kthread+0x96/0xa0
         [<ffffffff8100cd64>] kernel_thread_helper+0x4/0x10
        Code: 8b 95 70 ff ff ff b8 00 00 00 00 48 3b 9a 10 2e 00 00 48 0f 44 c2 48 89 85 70 ff ff ff 48 8b 8d 70 ff ff ff f6 83 69 02 00 00 01 <48> 8b 41 18 0f 85 48 01 00 00 48 85 c9 74 12 48 8b 51 08 48 83
        RIP  [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
         RSP <ffff880132defbf0>
        CR2: 0000000000000018
      
      Fix it by testing @link->ap->flags instead.
      
      stable: ATA_FLAG_NO_DIPM was added during 2.6.39 cycle but was
              backported to 2.6.37 and 38.  This is a fix for that and thus
              also applicable to 2.6.37 and 38.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: N"Nathan A. Mourey II" <nmoureyii@ne.rr.com>
      LKML-Reference: <1304555277.2059.2.camel@localhost.localdomain>
      Cc: Connor H <cmdkhh@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      5f6f12cc
    • T
      Revert "libata: ahci_start_engine compliant to AHCI spec" · 22fe9446
      Tejun Heo 提交于
      This reverts commit 270dac35.
      
      The commits causes command timeouts on AC plug/unplug.  It isn't yet
      clear why.  As the commit was for a single rather obscure controller,
      revert the change for now.
      
      The problem was reported and bisected by Gu Rui in bug#34692.
      
       https://bugzilla.kernel.org/show_bug.cgi?id=34692
      
      Also, reported by Rafael and Michael in the following thread.
      
       http://thread.gmane.org/gmane.linux.kernel/1138771Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NGu Rui <chaos.proton@gmail.com>
      Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: NMichael Leun <lkml20100708@newton.leun.net>
      Cc: Jian Peng <jipeng2005@gmail.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      22fe9446
    • B
      Further fbcon sanity checking · c590cece
      Bruno Prémont 提交于
      This moves the
      
          if (num_registered_fb == FB_MAX)
                  return -ENXIO;
      
      check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
      would (now in a safe way) allow a native driver to replace the
      conflicting one even if all slots in registered_fb[] are taken.
      
      This also prevents unregistering a framebuffer that is no longer
      registered (vga16f will unregister at module unload time even if the
      frame buffer had been unregistered earlier due to being found
      conflicting).
      Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c590cece
    • L
      fbmem: fix remove_conflicting_framebuffers races · 712f3147
      Linus Torvalds 提交于
      When a register_framebuffer() call results in us removing old
      conflicting framebuffers, the new registration_lock doesn't protect that
      situation.  And we can't just add the same locking to the function,
      because these functions call each other: register_framebuffer() calls
      remove_conflicting_framebuffers, which in turn calls
      unregister_framebuffer for any conflicting entry.
      
      In order to fix it, this just creates wrapper functions around all three
      functions and makes the versions that actually do the work be called
      "do_xxx()", leaving just the wrapper that gets the lock and calls the
      worker function.
      
      So the rule becomes simply that "do_xxxx()" has to be called with the
      lock held, and now do_register_framebuffer() can just call
      do_remove_conflicting_framebuffers(), and that in turn can call
      _do_unregister_framebuffer(), and there is no deadlock, and we can hold
      the registration lock over the whole sequence, fixing the races.
      
      It also makes error cases simpler, and fixes one situation where we
      would return from unregister_framebuffer() without releasing the lock,
      pointed out by Bruno Prémont.
      Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      712f3147
  3. 14 5月, 2011 3 次提交
  4. 13 5月, 2011 9 次提交
  5. 12 5月, 2011 5 次提交
    • L
      fbmem: make read/write/ioctl use the frame buffer at open time · c47747fd
      Linus Torvalds 提交于
      read/write/ioctl on a fbcon file descriptor has traditionally used the
      fbcon not when it was opened, but as it was at the time of the call.
      That makes no sense, but the lack of sense is much more obvious now that
      we properly ref-count the usage - it means that the ref-counting doesn't
      actually protect operations we do on the frame buffer.
      
      This changes it to look at the fb_info that we got at open time, but in
      order to avoid using a frame buffer long after it has been unregistered,
      we do verify that it is still current, and return -ENODEV if not.
      Acked-by: NTim Gardner <tim.gardner@canonical.com>
      Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c47747fd
    • L
      fbcon: add lifetime refcount to opened frame buffers · 698b3682
      Linus Torvalds 提交于
      This just adds the refcount and the new registration lock logic.  It
      does not (for example) actually change the read/write/ioctl routines to
      actually use the frame buffer that was opened: those function still end
      up alway susing whatever the current frame buffer is at the time of the
      call.
      
      Without this, if something holds the frame buffer open over a
      framebuffer switch, the close() operation after the switch will access a
      fb_info that has been free'd by the unregistering of the old frame
      buffer.
      
      (The read/write/ioctl operations will normally not cause problems,
      because they will - illogically - pick up the new fbcon instead.  But a
      switch that happens just as one of those is going on might see problems
      too, the window is just much smaller: one individual op rather than the
      whole open-close sequence.)
      
      This use-after-free is apparently fairly easily triggered by the Ubuntu
      11.04 boot sequence.
      Acked-by: NTim Gardner <tim.gardner@canonical.com>
      Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
      Cc: Bruno Prémont <bonbons@linux-vserver.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      698b3682
    • B
      sfc: Always map MCDI shared memory as uncacheable · 747df225
      Ben Hutchings 提交于
      We enabled write-combining for memory-mapped registers in commit
      65f0b417, but inhibited it for the
      MCDI shared memory where this is not supported.  However,
      write-combining mappings also allow read-reordering, which may also
      be a problem.
      
      I found that when an SFC9000-family controller is connected to an
      Intel 3000 chipset, and write-combining is enabled, the controller
      stops responding to PCIe read requests during driver initialisation
      while the driver is polling for completion of an MCDI command.  This
      results in an NMI and system hang.  Adding read memory barriers
      between all reads to the shared memory area appears to reduce but not
      eliminate the probability of this.
      
      We have not yet established whether this is a bug in our BIU or in the
      PCIe bridge.  For now, work around by mapping the shared memory area
      separately.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      747df225
    • A
      ehea: Fix memory hotplug oops · 21ccc793
      Anton Blanchard 提交于
      The ehea driver oopses during memory hotplug if the ports are not
      up. A simple testcase:
      
      # ifconfig ethX down
      # echo offline > /sys/devices/system/memory/memory32/state
      
      Oops: Kernel access of bad area, sig: 11 [#1]
      last sysfs file: /sys/devices/system/memory/memory32/state
      REGS: c000000709393110 TRAP: 0300   Not tainted  (2.6.39-rc2-01385-g7ef73bca-dirty)
      DAR: 0000000000000000, DSISR: 40000000
      ...
      NIP [c000000000067c98] .__wake_up_common+0x48/0xf0
      LR [c00000000006d034] .__wake_up+0x54/0x90
      Call Trace:
      [c00000000006d034] .__wake_up+0x54/0x90
      [d000000006bb6270] .ehea_rereg_mrs+0x140/0x730 [ehea]
      [d000000006bb69c4] .ehea_mem_notifier+0x164/0x170 [ehea]
      [c0000000006fc8a8] .notifier_call_chain+0x78/0xf0
      [c0000000000b3d70] .__blocking_notifier_call_chain+0x70/0xb0
      [c000000000458d78] .memory_notify+0x28/0x40
      [c0000000001871d8] .remove_memory+0x208/0x6d0
      [c000000000458264] .memory_section_action+0x94/0x140
      [c0000000004583ec] .memory_block_change_state+0xdc/0x1d0
      [c0000000004585cc] .store_mem_state+0xec/0x160
      [c00000000044768c] .sysdev_store+0x3c/0x50
      [c00000000020b48c] .sysfs_write_file+0xec/0x1f0
      [c00000000018f86c] .vfs_write+0xec/0x1e0
      [c00000000018fa88] .SyS_write+0x58/0xd0
      
      To fix this, initialise the waitqueues during port probe instead
      of port open.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable@kernel.org
      Acked-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21ccc793
    • B
      drivers/rtc/rtc-s3c.c: fixup wake support for rtc · 52cd4e5c
      Ben Dooks 提交于
      The driver is not balancing set_irq and disable_irq_wake() calls, so
      ensure that it keeps track of whether the wake is enabled.
      
      The fixes the following error on S3C6410 devices:
      
        WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x84/0xec()
        Unbalanced IRQ 92 wake disable
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52cd4e5c
  6. 11 5月, 2011 11 次提交
  7. 10 5月, 2011 5 次提交