1. 09 11月, 2013 7 次提交
    • P
      rsxx: Handling failed pci_map_page on PowerPC and double free. · e5feab22
      Philip J Kelleher 提交于
      The rsxx driver was not checking the correct value during a
      pci_map_page failure. Fixing this also uncovered a
      double free if the bio was returned before it was
      broken up into indiviadual 4k dmas, that is also
      fixed here.
      Signed-off-by: NPhilip J Kelleher <pjk1939@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      e5feab22
    • M
      loop: fix crash when using unassigned loop device · ef7e7c82
      Mikulas Patocka 提交于
      When the loop module is loaded, it creates 8 loop devices /dev/loop[0-7].
      The devices have no request routine and thus, when they are used without
      being assigned, a crash happens.
      
      For example, these commands cause crash (assuming there are no used loop
      devices):
      
      Kernel Fault: Code=26 regs=000000007f420980 (Addr=0000000000000010)
      CPU: 1 PID: 50 Comm: kworker/1:1 Not tainted 3.11.0 #1
      Workqueue: ksnaphd do_metadata [dm_snapshot]
      task: 000000007fcf4078 ti: 000000007f420000 task.ti: 000000007f420000
      [  116.319988]
           YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      PSW: 00001000000001001111111100001111 Not tainted
      r00-03  000000ff0804ff0f 00000000408bf5d0 00000000402d8204 000000007b7ff6c0
      r04-07  00000000408a95d0 000000007f420950 000000007b7ff6c0 000000007d06c930
      r08-11  000000007f4205c0 0000000000000001 000000007f4205c0 000000007f4204b8
      r12-15  0000000000000010 0000000000000000 0000000000000000 0000000000000000
      r16-19  000000001108dd48 000000004061cd7c 000000007d859800 000000000800000f
      r20-23  0000000000000000 0000000000000008 0000000000000000 0000000000000000
      r24-27  00000000ffffffff 000000007b7ff6c0 000000007d859800 00000000408a95d0
      r28-31  0000000000000000 000000007f420950 000000007f420980 000000007f4208e8
      sr00-03  0000000000000000 0000000000000000 0000000000000000 0000000000303000
      sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  117.549988]
      IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000402d82fc 00000000402d8300
       IIR: 53820020    ISR: 0000000000000000  IOR: 0000000000000010
       CPU:        1   CR30: 000000007f420000 CR31: ffffffffffffffff
       ORIG_R28: 0000000000000001
       IAOQ[0]: generic_make_request+0x11c/0x1a0
       IAOQ[1]: generic_make_request+0x120/0x1a0
       RP(r2): generic_make_request+0x24/0x1a0
      Backtrace:
       [<00000000402d83f0>] submit_bio+0x70/0x140
       [<0000000011087c4c>] dispatch_io+0x234/0x478 [dm_mod]
       [<0000000011087f44>] sync_io+0xb4/0x190 [dm_mod]
       [<00000000110883bc>] dm_io+0x2c4/0x310 [dm_mod]
       [<00000000110bfcd0>] do_metadata+0x28/0xb0 [dm_snapshot]
       [<00000000401591d8>] process_one_work+0x160/0x460
       [<0000000040159bc0>] worker_thread+0x300/0x478
       [<0000000040161a70>] kthread+0x118/0x128
       [<0000000040104020>] end_fault_vector+0x20/0x28
       [<0000000040177220>] task_tick_fair+0x420/0x4d0
       [<00000000401aa048>] invoke_rcu_core+0x50/0x60
       [<00000000401ad5b8>] rcu_check_callbacks+0x210/0x8d8
       [<000000004014aaa0>] update_process_times+0xa8/0xc0
       [<00000000401ab86c>] rcu_process_callbacks+0x4b4/0x598
       [<0000000040142408>] __do_softirq+0x250/0x2c0
       [<00000000401789d0>] find_busiest_group+0x3c0/0xc70
      [  119.379988]
      Kernel panic - not syncing: Kernel Fault
      Rebooting in 1 seconds..
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ef7e7c82
    • V
      xen/blkback: fix reference counting · ea5ec76d
      Vegard Nossum 提交于
      If the permission check fails, we drop a reference to the blkif without
      having taken it in the first place. The bug was introduced in commit
      604c499c (xen/blkback: Check device
      permissions before allowing OP_DISCARD).
      
      Cc: stable@vger.kernel.org
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ea5ec76d
    • R
      xen-blkfront: improve aproximation of required grants per request · c47206e2
      Roger Pau Monne 提交于
      Improve the calculation of required grants to process a request by
      using nr_phys_segments instead of always assuming a request is going
      to use all posible segments.
      
      nr_phys_segments contains the number of scatter-gather DMA addr+len
      pairs, which is basically what we put at every granted page.
      for_each_sg iterates over the DMA addr+len pairs and uses a grant
      page for each of them.
      Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c47206e2
    • R
      xen-blkfront: revoke foreign access for grants not mapped by the backend · fbe363c4
      Roger Pau Monne 提交于
      There's no need to keep the foreign access in a grant if it is not
      persistently mapped by the backend. This allows us to free grants that
      are not mapped by the backend, thus preventing blkfront from hoarding
      all grants.
      
      The main effect of this is that blkfront will only persistently map
      the same grants as the backend, and it will always try to use grants
      that are already mapped by the backend. Also the number of persistent
      grants in blkfront is the same as in blkback (and is controlled by the
      value in blkback).
      Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NMatt Wilson <msw@amazon.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      fbe363c4
    • M
      mg_disk: remove deprecated IRQF_DISABLED · 370d6686
      Michael Opdenacker 提交于
      This patch proposes to remove the use of the IRQF_DISABLED flag
      
      It's a NOOP since 2.6.35 and it will be removed one day.
      Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      370d6686
    • K
      block: Consolidate duplicated bio_trim() implementations · 6678d83f
      Kent Overstreet 提交于
      Someone cut and pasted md's md_trim_bio() into xen-blkfront.c. Come on,
      we should know better than this.
      Signed-off-by: NKent Overstreet <kmo@daterainc.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      6678d83f
  2. 08 11月, 2013 2 次提交
    • M
      block: fix a probe argument to blk_register_region · a207f593
      Mikulas Patocka 提交于
      The probe function is supposed to return NULL on failure (as we can see in
      kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj;
      
      However, in loop and brd, it returns negative error from ERR_PTR.
      
      This causes a crash if we simulate disk allocation failure and run
      less -f /dev/loop0 because the negative number is interpreted as a pointer:
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002b4
      IP: [<ffffffff8118b188>] __blkdev_get+0x28/0x450
      PGD 23c677067 PUD 23d6d1067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia]
      CPU: 1 PID: 6831 Comm: less Tainted: P        W  O 3.10.15-devel #18
      Hardware name: empty empty/S3992-E, BIOS 'V1.06   ' 06/09/2009
      task: ffff880203cc6bc0 ti: ffff88023e47c000 task.ti: ffff88023e47c000
      RIP: 0010:[<ffffffff8118b188>]  [<ffffffff8118b188>] __blkdev_get+0x28/0x450
      RSP: 0018:ffff88023e47dbd8  EFLAGS: 00010286
      RAX: ffffffffffffff74 RBX: ffffffffffffff74 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001
      RBP: ffff88023e47dc18 R08: 0000000000000002 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff88023f519658
      R13: ffffffff8118c300 R14: 0000000000000000 R15: ffff88023f519640
      FS:  00007f2070bf7700(0000) GS:ffff880247400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000002b4 CR3: 000000023da1d000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640
       ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60
       ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292
      Call Trace:
       [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
       [<ffffffff8118c10d>] blkdev_get+0x1dd/0x370
       [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
       [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
       [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
       [<ffffffff8118c365>] blkdev_open+0x65/0x80
       [<ffffffff8114d12e>] do_dentry_open.isra.18+0x23e/0x2f0
       [<ffffffff8114d214>] finish_open+0x34/0x50
       [<ffffffff8115e122>] do_last.isra.62+0x2d2/0xc50
       [<ffffffff8115eb58>] path_openat.isra.63+0xb8/0x4d0
       [<ffffffff81115a8e>] ? might_fault+0x4e/0xa0
       [<ffffffff8115f4f0>] do_filp_open+0x40/0x90
       [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
       [<ffffffff8116db85>] ? __alloc_fd+0xa5/0x1f0
       [<ffffffff8114e45f>] do_sys_open+0xef/0x1d0
       [<ffffffff8114e559>] SyS_open+0x19/0x20
       [<ffffffff813cff16>] system_call_fastpath+0x1a/0x1f
      Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5
      a4 07 00 44 89
      RIP  [<ffffffff8118b188>] __blkdev_get+0x28/0x450
       RSP <ffff88023e47dbd8>
      CR2: 00000000000002b4
      ---[ end trace bb7f32dbf02398dc ]---
      
      The brd change should be backported to stable kernels starting with 2.6.25.
      The loop change should be backported to stable kernels starting with 2.6.22.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: stable@kernel.org	# 2.6.22+
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      a207f593
    • M
      loop: fix crash if blk_alloc_queue fails · 3ec981e3
      Mikulas Patocka 提交于
      loop: fix crash if blk_alloc_queue fails
      
      If blk_alloc_queue fails, loop_add cleans up, but it doesn't clean up the
      identifier allocated with idr_alloc. That causes crash on module unload in
      idr_for_each(&loop_index_idr, &loop_exit_cb, NULL); where we attempt to
      remove non-existed device with that id.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000380
      IP: [<ffffffff812057c9>] del_gendisk+0x19/0x2d0
      PGD 43d399067 PUD 43d0ad067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: loop(-) dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_loop dm_mod ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_userspace cpufreq_stats cpufreq_ondemand cpufreq_conservative cpufreq_powersave spadfs fuse hid_generic usbhid hid raid0 md_mod dmi_sysfs nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc lm85 hwmon_vid snd_hwdep snd_usbmidi_lib snd_rawmidi snd soundcore acpi_cpufreq ohci_hcd freq_table tg3 ehci_pci mperf ehci_hcd kvm_amd kvm sata_svw serverworks libphy libata ide_core k10temp usbcore hwmon microcode ptp pcspkr pps_core e100 skge mii usb_common i2c_piix4 floppy evdev rtc_cmos i2c_core processor but!
       ton unix
      CPU: 7 PID: 2735 Comm: rmmod Tainted: G        W    3.10.15-devel #15
      Hardware name: empty empty/S3992-E, BIOS 'V1.06   ' 06/09/2009
      task: ffff88043d38e780 ti: ffff88043d21e000 task.ti: ffff88043d21e000
      RIP: 0010:[<ffffffff812057c9>]  [<ffffffff812057c9>] del_gendisk+0x19/0x2d0
      RSP: 0018:ffff88043d21fe10  EFLAGS: 00010282
      RAX: ffffffffa05102e0 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffff88043ea82800 RDI: 0000000000000000
      RBP: ffff88043d21fe48 R08: 0000000000000000 R09: 0000000000000001
      R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000ff
      R13: 0000000000000080 R14: 0000000000000000 R15: ffff88043ea82800
      FS:  00007ff646534700(0000) GS:ffff880447000000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000380 CR3: 000000043e9bf000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Stack:
       ffffffff8100aba4 0000000000000092 ffff88043d21fe48 ffff88043ea82800
       00000000000000ff ffff88043d21fe98 0000000000000000 ffff88043d21fe60
       ffffffffa05102b4 0000000000000000 ffff88043d21fe70 ffffffffa05102ec
      Call Trace:
       [<ffffffff8100aba4>] ? native_sched_clock+0x24/0x80
       [<ffffffffa05102b4>] loop_remove+0x14/0x40 [loop]
       [<ffffffffa05102ec>] loop_exit_cb+0xc/0x10 [loop]
       [<ffffffff81217b74>] idr_for_each+0x104/0x190
       [<ffffffffa05102e0>] ? loop_remove+0x40/0x40 [loop]
       [<ffffffff8109adc5>] ? trace_hardirqs_on_caller+0x105/0x1d0
       [<ffffffffa05135dc>] loop_exit+0x34/0xa58 [loop]
       [<ffffffff810a98ea>] SyS_delete_module+0x13a/0x260
       [<ffffffff81221d5e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff813cff16>] system_call_fastpath+0x1a/0x1f
      Code: f0 4c 8b 6d f8 c9 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 56 41 55 4c 8d af 80 00 00 00 41 54 53 48 89 fb 48 83 ec 18 <48> 83 bf 80 03 00
      00 00 74 4d e8 98 fe ff ff 31 f6 48 c7 c7 20
      RIP  [<ffffffff812057c9>] del_gendisk+0x19/0x2d0
       RSP <ffff88043d21fe10>
      CR2: 0000000000000380
      ---[ end trace 64ec069ec70f1309 ]---
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: stable@kernel.org	# 3.1+
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      3ec981e3
  3. 02 11月, 2013 13 次提交
  4. 01 11月, 2013 1 次提交
    • L
      i915: fix compiler warning · 0baab4fd
      Linus Torvalds 提交于
      The last i915 drm update brought with it this annoying warning
      
        drivers/gpu/drm/i915/intel_crt.c: In function ‘intel_crt_get_config’:
        drivers/gpu/drm/i915/intel_crt.c:110:21: warning: unused variable ‘dev’ [-Wunused-variable]
          struct drm_device *dev = encoder->base.dev;
                             ^
      
      introduced by commit 7195a50b ("drm/i915: Add HSW CRT output readout
      support").
      
      Remove the offending pointless variable.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0baab4fd
  5. 31 10月, 2013 6 次提交
  6. 30 10月, 2013 3 次提交
  7. 29 10月, 2013 4 次提交
    • D
      drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb · 1fbc0d78
      Daniel Vetter 提交于
      Originally I've thought that this is leftover hw state dirt from the
      BIOS. But after way too much helpless flailing around on my part I've
      noticed that the actual bug is when we change the state of an already
      active pipe.
      
      For example when we change the fdi lines from 2 to 3 without switching
      off outputs in-between we'll never see the crucial on->off transition
      in the ->modeset_global_resources hook the current logic relies on.
      
      Patch version 2 got this right by instead also checking whether the
      pipe is indeed active. But that in turn broke things when pipes have
      been turned off through dpms since the bifurcate enabling is done in
      the ->crtc_mode_set callback.
      
      To address this issues discussed with Ville in the patch review move
      the setting of the bifurcate bit into the ->crtc_enable hook. That way
      we won't wreak havoc with this state when userspace puts all other
      outputs into dpms off state. This also moves us forward with our
      overall goal to unify the modeset and dpms on paths (which we need to
      have to allow runtime pm in the dpms off state).
      
      Unfortunately this requires us to move the bifurcate helpers around a
      bit.
      
      Also update the commit message, I've misanalyzed the bug rather badly.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507Tested-by: NJan-Michael Brummer <jan.brummer@tabos.org>
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1fbc0d78
    • R
      drm/i915: No LVDS hardware on Intel D410PT and D425KT · 645378d8
      Rob Pearce 提交于
      The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
      having LVDS but the hardware is not populated. This patch adds them to
      the list of such systems. Patch is against 3.11.4
      
      v2: Patch revised to match the D425KT exactly as the D425KTW does have
      LVDS.  According to Intel's documentation, the D410PTL and D410PLTW
      don't.
      Signed-off-by: NRob Pearce <rob@flitspace.org.uk>
      Cc: stable@vger.kernel.org
      [danvet: Pimp commit message to my liking and add cc: stable.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      645378d8
    • J
      drm/i915/dp: workaround BIOS eDP bpp clamping issue · c6cd2ee2
      Jani Nikula 提交于
      This isn't a real fix to the problem, but rather a stopgap measure while
      trying to find a proper solution.
      
      There are several laptops out there that fail to light up the eDP panel
      in UEFI boot mode. They seem to be mostly IVB machines, including but
      apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
      UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
      
      The difference between UEFI and CSM is that the BIOS provides a
      different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
      1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
      up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
      link, and for reasons yet unknown fail to light up the panel.
      
      Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
      2.7 GHz link, the eDP panel lights up. So essentially this is a link
      speed issue, and *not* a bpp clamping issue.
      
      The bug raised its head since
      commit 657445fe
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat May 4 10:09:18 2013 +0200
      
          Revert "drm/i915: revert eDP bpp clamping code changes"
      
      which started clamping bpp *before* computing the link requirements, and
      thus affecting the required bandwidth. Clamping after the computations
      kept the link at 2.7 GHz.
      
      Even though the BIOS tells us to use 18 bpp through the VBT, it happily
      boots up at 24 bpp and 2.7 GHz itself! Use this information to
      selectively ignore the VBT provided value.
      
      We can't ignore the VBT eDP bpp altogether, as there are other laptops
      that do require the clamping to be used due to EDID reporting higher bpp
      than the panel can support.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950Tested-by: NUlf Winkelvos <ulf@winkelvos.de>
      Tested-by: Njkp <jkp@iki.fi>
      CC: stable@vger.kernel.org
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c6cd2ee2
    • V
      drm/i915: Add HSW CRT output readout support · 7195a50b
      Ville Syrjälä 提交于
      Call intel_ddi_get_config() to get the pipe_bpp settings from
      DDI.
      
      The sync polarity settings from DDI are irrelevant for CRT
      output, so override them with data from the ADPA register.
      
      Note: This is already merged in drm-intel-next-queued as
      
      commit 6801c18c
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Tue Sep 24 14:24:05 2013 +0300
      
          drm/i915: Add HSW CRT output readout support
      
      but is required for the following edp bpp bugfix.
      
      v2: Extract intel_crt_get_flags()
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691Tested-by: NQingshuai Tian <qingshuai.tian@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7195a50b
  8. 28 10月, 2013 1 次提交
  9. 26 10月, 2013 3 次提交
    • N
      vhost/scsi: Fix incorrect usage of get_user_pages_fast write parameter · 60a01f55
      Nicholas Bellinger 提交于
      This patch addresses a long-standing bug where the get_user_pages_fast()
      write parameter used for setting the underlying page table entry permission
      bits was incorrectly set to write=1 for data_direction=DMA_TO_DEVICE, and
      passed into get_user_pages_fast() via vhost_scsi_map_iov_to_sgl().
      
      However, this parameter is intended to signal WRITEs to pinned userspace
      PTEs for the virtio-scsi DMA_FROM_DEVICE -> READ payload case, and *not*
      for the virtio-scsi DMA_TO_DEVICE -> WRITE payload case.
      
      This bug would manifest itself as random process segmentation faults on
      KVM host after repeated vhost starts + stops and/or with lots of vhost
      endpoints + LUNs.
      
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Asias He <asias@redhat.com>
      Cc: <stable@vger.kernel.org> # 3.6+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      60a01f55
    • W
      target/pscsi: fix return value check · 58932e96
      Wei Yongjun 提交于
      In case of error, the function scsi_host_lookup() returns NULL
      pointer not ERR_PTR(). The IS_ERR() test in the return value check
      should be replaced with NULL test.
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      58932e96
    • D
      mtd: gpmi: fix ECC regression · 031e2777
      David Woodhouse 提交于
      The "legacy" ECC layout used until 3.12-rc1 uses all the OOB area by
      computing the ECC strength and ECC step size ourselves.
      
      Commit 2febcdf8 ("mtd: gpmi: set the BCHs geometry with the ecc info")
      makes the driver use the ECC info (ECC strength and ECC step size)
      provided by the MTD code, and creates a different NAND ECC layout
      for the BCH, and use the new ECC layout. This causes a regression:
      
         We can not mount the ubifs which was created by the old NAND ECC layout.
      
      This patch fixes this issue by reverting to the legacy ECC layout.
      
      We will probably introduce a new device-tree property to indicate that
      the new ECC layout can be used. For now though, for the imminent 3.12
      release, we just unconditionally revert to the 3.11 behaviour.
      
      This leaves a harmless cosmetic warning about an unused function. At
      this point in the cycle I really don't care.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Acked-by: NHuang Shijie <b32955@freescale.com>
      Acked-by: NMarek Vasut <marex@denx.de>
      Tested-by: NMarek Vasut <marex@denx.de>
      031e2777