Skip to content
  1. Dec 09, 2014
    • Sylwester Nawrocki's avatar
      ASoC: samsung: i2s: Add missing assignment of variant_regs · 7e5d8706
      Sylwester Nawrocki authored
      Add assignment of the variant_regs field which is missing in commit
      a5a56871
      
       ("ASoC: samsung: add support
      for exynos7 I2S controller"). Without this attempting to probe the
      secondary DAI fails with an error like:
      
      [    1.763026] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [    1.780895] pgd = c0004000
      [    1.783606] [0000000c] *pgd=00000000
      [    1.838255] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      [    1.843514] Modules linked in:
      [    1.846558] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc1-00009-g5dcb01e-dirty #1521
      [    1.854887] task: ee00a800 ti: ee088000 task.ti: ee088000
      [    1.860284] PC is at i2s_txctrl+0x40/0x2d4
      [    1.864350] LR is at i2s_txctrl+0x28/0x2d4
      [    1.868428] pc : [<c036ffd4>]    lr : [<c036ffbc>]    psr: 60000153
      [    1.868428] sp : ee089dc0  ip : 00000000  fp : ee21f000
      [    1.879883] r10: 00000000  r9 : ee21fb00  r8 : c06406c4
      [    1.885091] r7 : ee21fb00  r6 : 00000000  r5 : f00f6000  r4 : ed943410
      [    1.891601] r3 : 0000016c  r2 : c0464550  r1 : c055cef8  r0 : ed943610
      [    1.898113] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    1.905490] Control: 10c5387d  Table: 4000404a  DAC: 00000015
      [    1.911218] Process swapper/0 (pid: 1, stack limit = 0xee088240)
      [    1.917208] Stack: (0xee089dc0 to 0xee08a000)
      ...
      [    2.068431] [<c036ffd4>] (i2s_txctrl) from [<c03719fc>] (samsung_i2s_dai_probe+0xb8/0x450)
      [    2.076676] [<c03719fc>] (samsung_i2s_dai_probe) from [<c03607e0>] (snd_soc_register_card+0xd98/0x1348)
      [    2.086044] [<c03607e0>] (snd_soc_register_card) from [<c03726e4>] (odroidx2_audio_probe+0xa8/0x11c)
      [    2.095160] [<c03726e4>] (odroidx2_audio_probe) from [<c0249dd0>] (platform_drv_probe+0x48/0xa4)
      [    2.103922] [<c0249dd0>] (platform_drv_probe) from [<c0248988>] (driver_probe_device+0x10c/0x22c)
      [    2.112773] [<c0248988>] (driver_probe_device) from [<c0248b34>] (__driver_attach+0x8c/0x90)
      [    2.121192] [<c0248b34>] (__driver_attach) from [<c02471c8>] (bus_for_each_dev+0x54/0x88)
      [    2.129352] [<c02471c8>] (bus_for_each_dev) from [<c0248188>] (bus_add_driver+0xd4/0x1d0)
      [    2.137510] [<c0248188>] (bus_add_driver) from [<c024915c>] (driver_register+0x78/0xf4)
      [    2.145499] [<c024915c>] (driver_register) from [<c0008924>] (do_one_initcall+0x80/0x1b8)
      [    2.153670] [<c0008924>] (do_one_initcall) from [<c05b7d40>] (kernel_init_freeable+0xfc/0x1c8)
      [    2.162260] [<c05b7d40>] (kernel_init_freeable) from [<c04146c0>] (kernel_init+0x8/0xec)
      [    2.170330] [<c04146c0>] (kernel_init) from [<c000e7f8>] (ret_from_fork+0x14/0x3c)
      [    2.177873] Code: e5940000 e59f128c e59f228c e2800010 (e59c700c)
      
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      7e5d8706
  2. Dec 08, 2014
  3. Dec 07, 2014
  4. Dec 06, 2014
  5. Dec 05, 2014
  6. Dec 04, 2014
  7. Dec 03, 2014
    • Hariprasad Shenai's avatar
    • Seth Forshee's avatar
      xen-netfront: Remove BUGs on paged skb data which crosses a page boundary · 8d609725
      Seth Forshee authored
      These BUGs can be erroneously triggered by frags which refer to
      tail pages within a compound page. The data in these pages may
      overrun the hardware page while still being contained within the
      compound page, but since compound_order() evaluates to 0 for tail
      pages the assertion fails. The code already iterates through
      subsequent pages correctly in this scenario, so the BUGs are
      unnecessary and can be removed.
      
      Fixes: f36c3747
      
       ("xen/netfront: handle compound page fragments on transmit")
      Cc: <stable@vger.kernel.org> # 3.7+
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d609725
    • Andrew Morton's avatar
      mm/vmpressure.c: fix race in vmpressure_work_fn() · 91b57191
      Andrew Morton authored
      In some android devices, there will be a "divide by zero" exception.
      vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock).
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051
      
      
      
      [akpm@linux-foundation.org: neaten]
      Reported-by: default avatarji_ang <ji_ang@163.com>
      Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      91b57191
    • Weijie Yang's avatar
      mm: frontswap: invalidate expired data on a dup-store failure · fb993fa1
      Weijie Yang authored
      
      
      If a frontswap dup-store failed, it should invalidate the expired page
      in the backend, or it could trigger some data corruption issue.
      Such as:
       1. use zswap as the frontswap backend with writeback feature
       2. store a swap page(version_1) to entry A, success
       3. dup-store a newer page(version_2) to the same entry A, fail
       4. use __swap_writepage() write version_2 page to swapfile, success
       5. zswap do shrink, writeback version_1 page to swapfile
       6. version_2 page is overwrited by version_1, data corrupt.
      
      This patch fixes this issue by invalidating expired data immediately
      when meet a dup-store failure.
      
      Signed-off-by: default avatarWeijie Yang <weijie.yang@samsung.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Seth Jennings <sjennings@variantweb.net>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Bob Liu <bob.liu@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fb993fa1
    • Rafael Aquini's avatar
      mm: do not overwrite reserved pages counter at show_mem() · bc127bda
      Rafael Aquini authored
      
      
      Minor fixlet to perform the reserved pages counter aggregation for each
      node, at show_mem()
      
      Signed-off-by: default avatarRafael Aquini <aquini@redhat.com>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarJohannes Weiner <jweiner@redhat.com>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bc127bda
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 00d6a9b6
      Dave Airlie authored
      A few more small fixes for 3.18.
      
      * 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
        drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
        drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86
        drm/radeon: sync all BOs involved in a CS v2
      00d6a9b6
    • 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