Re: Panic in drm_calc_timestamping_constants in staging-next

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 15, 2015 at 01:17:00PM -0500, ira.weiny wrote:
> With the latest staging-testing and staging-next[*] I am getting the following panic.
> 
> [*] git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> 
> 
> [   11.232549] BUG: unable to handle kernel NULL pointer dereference at
> 00000000000000b0
> [   11.232568] IP: [<ffffffffa0103206>]
> drm_calc_timestamping_constants+0x86/0x130 [drm]

http://lists.freedesktop.org/archives/dri-devel/2015-November/094298.html

> [   11.232571] PGD 0 
> [   11.232574] Oops: 0002 [#1] SMP 
> [   11.232595] Modules linked in: ib_qib mgag200(+) drm_kms_helper isci
> syscopyarea sysfillrect sysimgblt fb_sys_fops ib_mad ttm libsas mlx4_core(+)
> ib_core igb drm ahci scsi_transport_sas libahci ptp libata firewire_ohci
> ib_addr pps_core firewire_core dca i2c_algo_bit i2c_core crc_itu_t
> [   11.232600] CPU: 13 PID: 497 Comm: systemd-udevd Not tainted 4.3.0+ #1
> [   11.232601] Hardware name: Intel Corporation W2600CR ........../W2600CR,
> BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
> [   11.232603] task: ffff8800343abfc0 ti: ffff8804244a8000 task.ti:
> ffff8804244a8000
> [   11.232618] RIP: 0010:[<ffffffffa0103206>]  [<ffffffffa0103206>]
> drm_calc_timestamping_constants+0x86/0x130 [drm]
> [   11.232620] RSP: 0018:ffff8804244ab118  EFLAGS: 00010246
> [   11.232621] RAX: 0000000000fe4c00 RBX: ffff880424b10160 RCX:
> 0000000000000540
> [   11.232623] RDX: 0000000000000000 RSI: 000000000000fde8 RDI:
> ffff880424b10000
> [   11.232624] RBP: ffff8804244ab148 R08: ffff8804244a8000 R09:
> 000000029d828339
> [   11.232626] R10: 00000000000050c4 R11: 0000000000000000 R12:
> 0000000000fe4c00
> [   11.232627] R13: ffff880424b10000 R14: 0000000000000000 R15:
> 000000000000fde8
> [   11.232629] FS:  00007fecf960d880(0000) GS:ffff88082d940000(0000)
> knlGS:0000000000000000
> [   11.232631] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   11.232632] CR2: 00000000000000b0 CR3: 0000000424493000 CR4:
> 00000000000406e0
> [   11.232634] Stack:
> [   11.232637]  ffff8804244ab148 ffff880424b10000 ffff88042a86bb40
> ffff88042a86b800
> [   11.232639]  ffff88042a86bb48 ffff88042a86bb40 ffff8804244ab378
> ffffffffa030c7e7
> [   11.232642]  ffff880424b10090 0000000000000000 ffff880424b10160
> 0000000000000000
> [   11.232642] Call Trace:
> [   11.232655]  [<ffffffffa030c7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0
> [drm_kms_helper]
> [   11.232665]  [<ffffffffa030d7d4>] drm_crtc_helper_set_config+0x8d4/0xb10
> [drm_kms_helper]
> [   11.232683]  [<ffffffffa010c874>] drm_mode_set_config_internal+0x64/0x100
> [drm]
> [   11.232694]  [<ffffffffa0319352>] drm_fb_helper_pan_display+0xa2/0x280
> [drm_kms_helper]
> [   11.232703]  [<ffffffff81395a8b>] fb_pan_display+0xbb/0x170
> [   11.232708]  [<ffffffff8138fd80>] bit_update_start+0x20/0x50
> [   11.232712]  [<ffffffff8138e62b>] fbcon_switch+0x39b/0x590
> [   11.232721]  [<ffffffff8140d260>] redraw_screen+0x1a0/0x240
> [   11.232725]  [<ffffffff8140dc28>] vc_do_resize+0x4d8/0x500
> [   11.232729]  [<ffffffff8140dc6f>] vc_resize+0x1f/0x30
> [   11.232732]  [<ffffffff8138ec32>] fbcon_init+0x342/0x530
> [   11.232737]  [<ffffffff8140b8ea>] visual_init+0xca/0x130
> [   11.232741]  [<ffffffff8140dff6>] do_bind_con_driver+0x146/0x310
> [   11.232746]  [<ffffffff8140e4e1>] do_take_over_console+0x141/0x1b0
> [   11.232750]  [<ffffffff8138a187>] do_fbcon_takeover+0x57/0xb0
> [   11.232754]  [<ffffffff8138f79b>] fbcon_event_notify+0x60b/0x750
> [   11.232760]  [<ffffffff810a5889>] notifier_call_chain+0x49/0x70
> [   11.232764]  [<ffffffff810a5bcd>] __blocking_notifier_call_chain+0x4d/0x70
> [   11.232768]  [<ffffffff810a5c06>] blocking_notifier_call_chain+0x16/0x20
> [   11.232772]  [<ffffffff8139563b>] fb_notifier_call_chain+0x1b/0x20
> [   11.232775]  [<ffffffff81397691>] register_framebuffer+0x1f1/0x330
> [   11.232784]  [<ffffffffa031a9ba>] drm_fb_helper_initial_config+0x27a/0x3d0
> [drm_kms_helper]
> [   11.232792]  [<ffffffffa0341b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
> [   11.232798]  [<ffffffffa0340586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
> [   11.232804]  [<ffffffffa033c659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
> [   11.232819]  [<ffffffffa0106007>] drm_dev_register+0xa7/0xb0 [drm]
> [   11.232834]  [<ffffffffa01084ef>] drm_get_pci_dev+0x8f/0x1e0 [drm]
> [   11.232840]  [<ffffffffa034137b>] mga_pci_probe+0x9b/0xc0 [mgag200]
> [   11.232848]  [<ffffffff813690f5>] local_pci_probe+0x45/0xa0
> [   11.232853]  [<ffffffff8136a53c>] pci_device_probe+0xfc/0x140
> [   11.232858]  [<ffffffff8145566b>] driver_probe_device+0x21b/0x460
> [   11.232861]  [<ffffffff81455935>] __driver_attach+0x85/0x90
> [   11.232864]  [<ffffffff814558b0>] ? driver_probe_device+0x460/0x460
> [   11.232868]  [<ffffffff8145337c>] bus_for_each_dev+0x6c/0xc0
> [   11.232871]  [<ffffffff81454fce>] driver_attach+0x1e/0x20
> [   11.232873]  [<ffffffff81454ae0>] bus_add_driver+0x1d0/0x290
> [   11.232876]  [<ffffffff814562e0>] driver_register+0x60/0xe0
> [   11.232880]  [<ffffffff81368a9c>] __pci_register_driver+0x4c/0x50
> [   11.232894]  [<ffffffffa0108720>] drm_pci_init+0xe0/0x110 [drm]
> [   11.232897]  [<ffffffffa0348000>] ? 0xffffffffa0348000
> [   11.232902]  [<ffffffffa0348032>] mgag200_init+0x32/0x1000 [mgag200]
> [   11.232907]  [<ffffffff8100213d>] do_one_initcall+0xcd/0x1f0
> [   11.232911]  [<ffffffff811c5e56>] ? __vunmap+0xa6/0xf0
> [   11.232918]  [<ffffffff811e2c1b>] ? kmem_cache_alloc_trace+0x17b/0x1e0
> [   11.232921]  [<ffffffff81185243>] ? do_init_module+0x27/0x1e8
> [   11.232924]  [<ffffffff8118527c>] do_init_module+0x60/0x1e8
> [   11.232930]  [<ffffffff8110a6e3>] load_module+0x12b3/0x1980
> [   11.232933]  [<ffffffff81106b10>] ? __symbol_put+0x60/0x60
> [   11.232938]  [<ffffffff81106f80>] ? copy_module_from_fd.isra.51+0x110/0x160
> [   11.232943]  [<ffffffff8110afbf>] SyS_finit_module+0x9f/0xd0
> [   11.232949]  [<ffffffff8169146e>] entry_SYSCALL_64_fastpath+0x12/0x71
> [   11.232976] Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69
> c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 fa 6f 03 00 01 <45> 89
> 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b 
> [   11.232990] RIP  [<ffffffffa0103206>]
> drm_calc_timestamping_constants+0x86/0x130 [drm]
> [   11.232991]  RSP <ffff8804244ab118>
> [   11.232992] CR2: 00000000000000b0
> [   11.232996] ---[ end trace 402fdf8659b2f760 ]---
> [   11.238445] Kernel panic - not syncing: Fatal exception
> [   11.238510] Kernel Offset: disabled
> 
> 
> I believe it is related to (but not directly caused by) this commit:
> 
> 
> commit eba1f35dfe145247c7eb690c7c32740fde8ec699
> Author: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Date:   Mon Sep 14 22:43:43 2015 +0300
> 
>     drm: Move timestamping constants into drm_vblank_crtc
>     
>     Collect the timestamping constants alongside the rest of the relevant
>     stuff under drm_vblank_crtc.
>     
>     We can now get rid of the 'refcrtc' parameter to
>     drm_calc_vbltimestamp_from_scanoutpos().
>     
>     Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>     Reviewed-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>     Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> 
> 
> 
> The reason I think it is not caused by the above commit is that when I run with
> this commit I get a __hang__ rather than a panic.  But running with the parent
> commit (below) works just fine:
> 
> commit 942840371cde152fe57c15e0e8483b760e7763e3
> Author: Matt Roper <matthew.d.roper@xxxxxxxxx>
> Date:   Mon Sep 21 17:21:48 2015 -0700
> 
>     drm/fbdev: Update legacy plane->fb refcounting for atomic restore
>     
>     Starting with commit
>     
>             commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
>             Author: Rob Clark <robdclark@xxxxxxxxx>
>             Date:   Tue Aug 25 15:36:00 2015 -0400
>     
>                 drm/i915: enable atomic fb-helper
>     
>     I've been seeing some panics on i915 when the DRM master shuts down that
> appear
>     to be caused by using an already-freed framebuffer (i.e., we're
> unexpectedly
>     dropping our initial FB's reference count to 0 and freeing it, which causes
> a
>     crash when we try to restore it later).  Digging deeper, the state FB
>     refcounting is working as expected, but we seem to be missing proper
>     refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>     
>     Tracking plane->old_fb and then doing a ref/unref at the end of the
>     fbdev restore like we do in the legacy ioctl's ensures we don't miscount
>     references on plane->fb and avoids the panics.
>     
>     v2 from Daniel:
>     
>     Really do what the atomic ioctl does:
>     - Also update plane->fb and plane->crtc.
>           - Clear out plane->old_fb on failures too.
>                 
>     v3: git add everything. Oops.
>     
>     v4: Also clear old_fb in all other failure paths, spotted by David.
>     
>     Cc: Rob Clark <robdclark@xxxxxxxxx>
>     Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx
>     Cc: David Herrmann <dh.herrmann@xxxxxxxxx>
>     Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>     Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> (v1)
>     Reviewd-by: David Herrmann <dh.herrmann@xxxxxxxxx>
>     Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> 
> 
> Because I am getting a hang I'm not quite sure where to proceed with bisect
> beyond the commit in question.
> 
> A bit of digging reveals that it may be that vblank has not been allocated at
> all. Using the following hack:
> 
>         struct drm_vblank_crtc *vblank = &crtc->dev->vblank[drm_crtc_index(crtc)];
> 
> 
> 12:46:25 > git di
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index eba6337f5860..649c32c00b36 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -641,8 +641,13 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
>                 DRM_ERROR("crtc %u: Can't calculate constants, dotclock =
> 0!\n",
>                           crtc->base.id);
>  
> -       vblank->linedur_ns  = linedur_ns;
> -       vblank->framedur_ns = framedur_ns;
> +       if ((u64)vblank < 1000) {
> +               DRM_ERROR("crtc %u: Can't calculate linedur_ns or framedur_ns; vblank %p; drm_crtc_index(crtc) %d\n",
> +                         crtc->base.id, vblank, drm_crtc_index(crtc));
> +       } else {
> +               vblank->linedur_ns  = linedur_ns;
> +               vblank->framedur_ns = framedur_ns;
> +       }
>  
>         DRM_DEBUG("crtc %u: hwmode: htotal %d, vtotal %d, vdisplay %d\n",
>                   crtc->base.id, mode->crtc_htotal,
> 
> 
> I got the following output.
> 
> kernel: [drm:drm_calc_timestamping_constants [drm]]
> *ERROR* crtc 19: Can't calculate linedur_ns or framedur_ns; vblank (null); drm_crtc_index(crtc) 0
> 
> So this must mean that the vblank array is not allocated yet?
> 
> What intervening patch between 4.3 and the current staging-next might change
> where/how vblank is allocated?
> 
> Thanks,
> Ira

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux