1. 06 Dec, 2014 1 commit
  2. 05 Dec, 2014 6 commits
  3. 04 Dec, 2014 4 commits
  4. 03 Dec, 2014 21 commits
  5. 02 Dec, 2014 8 commits
    • Petr Mladek's avatar
      drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 · f5475cc4
      Petr Mladek authored
      I was unable too boot 3.18.0-rc6 because of the following kernel
      panic in drm_calc_vbltimestamp_from_scanoutpos():
      
          [drm] Initialized drm 1.1.0 20060810
          [drm] radeon kernel modesetting enabled.
          [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
          [drm] register mmio base: 0xC8400000
          [drm] register mmio size: 65536
          radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
          radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
          [drm] Detected VRAM RAM=128M, BAR=128M
          [drm] RAM width 16bits DDR
          [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
          [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
          [TTM] Initializing pool allocator
          [TTM] Initializing DMA pool allocator
          [drm] radeon: 16M of VRAM memory ready
          [drm] radeon: 512M of GTT memory ready.
          [drm] GART: num cpu pages 131072, num gpu pages 131072
          [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
          radeon 0000:0b:01.0: WB disabled
          radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
          [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
          [drm] Driver supports precise vblank timestamp query.
          [drm] radeon: irq initialized.
          [drm] Loading R100 Microcode
          radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
          radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
          [drm:r100_cp_init] *ERROR* Failed to load firmware!
          radeon 0000:0b:01.0: failed initializing CP (-2).
          radeon 0000:0b:01.0: Disabling GPU acceleration
          [drm] radeon: cp finalized
          BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
          IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          PGD 0
          Oops: 0000 [#1] SMP
          Modules linked in:
          CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
          Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
          task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
          RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          RSP: 0000:ffff880234da7918  EFLAGS: 00010086
          RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
          RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
          RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
          R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
          R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
          FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
          Stack:
           ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
           ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
           ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
          Call Trace:
           [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
           [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
           [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
           [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
           [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
           [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
           [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
           [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
           [<ffffffff8156c07e>] r100_init+0x26e/0x410
           [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
           [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
           [<ffffffff81506965>] drm_dev_register+0xb5/0x110
           [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
           [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
           [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
           [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
           [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
           [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
           [<ffffffff816340a0>] ? __device_attach+0x40/0x40
           [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
           [<ffffffff8163378e>] driver_attach+0x1e/0x20
           [<ffffffff81633390>] bus_add_driver+0x180/0x240
           [<ffffffff81634914>] driver_register+0x64/0xf0
           [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
           [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
           [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
           [<ffffffff821dc908>] radeon_init+0x97/0xb5
           [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
           [<ffffffff810e3278>] ? __wake_up+0x48/0x60
           [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
           [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
           [<ffffffff818a78fe>] kernel_init+0xe/0xf0
           [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
          Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
          RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
           RSP <ffff880234da7918>
          CR2: 000000000000025c
          ---[ end trace ad2c0aadf48e2032 ]---
          Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      
      It has helped me to add a NULL pointer check that was suggested at
      http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
      
      I am not familiar with the code. But the change looks sane
      and we need something fast at this stage of 3.18 development.
      Suggested-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.cz>
      Tested-by: default avatarPetr Mladek <pmladek@suse.cz>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f5475cc4
    • Michel Dänzer's avatar
    • Christian König's avatar
      drm/radeon: sync all BOs involved in a CS v2 · 86b27638
      Christian König authored
      Not just the userspace relocs, otherwise we won't wait
      for a swapped out page tables to be swapped in again.
      
      v2: rebased on Alex current drm-fixes-3.18
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      86b27638
    • Darrick J. Wong's avatar
      block: fix regression where bio_integrity_process uses wrong bio_vec iterator · 594416a7
      Darrick J. Wong authored
      bio integrity handling is broken on a system with LVM layered atop a
      DIF/DIX SCSI drive because device mapper clones the bio, modifies the
      clone, and sends the clone to the lower layers for processing.
      However, the clone bio has bi_vcnt == 0, which means that when the sd
      driver calls bio_integrity_process to attach DIX data, the
      for_each_segment_all() call (which uses bi_vcnt) returns immediately
      and random garbage is sent to the disk on a disk write.  The disk of
      course returns an error.
      
      Therefore, teach bio_integrity_process() to use bio_for_each_segment()
      to iterate the bio_vecs, since the per-bio iterator tracks which
      bio_vecs are associated with that particular bio.  The integrity
      handling code is effectively part of the "driver" (it's not the bio
      owner), so it must use the correct iterator function.
      
      v2: Fix a compiler warning about abandoned local variables.  This
      patch supersedes "block: bio_integrity_process uses wrong bio_vec
      iterator".  Patch applies against 3.18-rc6.
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      594416a7
    • Daniel Vetter's avatar
      drm/i915: Unlock panel even when LVDS is disabled · b0616c53
      Daniel Vetter authored
      Otherwise we'll have backtraces in assert_panel_unlocked because the
      BIOS locks the register. In the reporter's case this regression was
      introduced in
      
      commit c31407a3
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Oct 18 21:07:01 2012 +0100
      
          drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
      Reported-by: default avatarAlexey Orishko <alexey.orishko@gmail.com>
      Cc: Alexey Orishko <alexey.orishko@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Francois Tigeot <ftigeot@wolfpond.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Tested-by: default avatarAlexey Orishko <alexey.orishko@gmail.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b0616c53
    • Daniel Vetter's avatar
      drm/i915: More cautious with pch fifo underruns · b6836227
      Daniel Vetter authored
      Apparently PCH fifo underruns are tricky, we have plenty reports that
      we see the occasional underrun (especially at boot-up).
      
      So for a change let's see what happens when we don't re-enable pch
      fifo underrun reporting when the pipe is disabled. This means that the
      kernel can't catch pch fifo underruns when they happen (except when
      all pipes are on on the pch). But we'll still catch underruns when
      disabling the pipe again. So not a terrible reduction in test
      coverage.
      
      Since the DRM_ERROR is new and hence a regression plan B would be to
      revert it back to a debug output. Which would be a lot worse than this
      hack for underrun test coverage in the wild. See the referenced
      discussions for more.
      
      References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898
      References: https://bugs.freedesktop.org/show_bug.cgi?id=85898
      References: https://bugs.freedesktop.org/show_bug.cgi?id=86233
      References: https://bugs.freedesktop.org/show_bug.cgi?id=86478Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Tested-by: default avatarlu hua <huax.lu@intel.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b6836227
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add headset Mic support for new Dell machine · b734304f
      Kailang Yang authored
      Dell has new machines. It supports headset Mic and Headphone Mic.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b734304f
    • James Morris's avatar
      Merge tag 'keys-fixes-20141201' of... · 18832480
      James Morris authored
      Merge tag 'keys-fixes-20141201' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into for-linus
      18832480