[Intel-gfx] Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 )

[Matt Roper]

On Tue, Mar 31, 2015 at 08:54:19AM +0200, Daniel Vetter wrote:
> Adding mailing lists (and hooray for me mixing up addresses, so now
> there's a disclaimer at the bottom).
> -Daniel

It looks like this is caused by 3.19.3 having

        commit 77f7ef95e2cf09150e5777454fd5df69af39edcd
        Author: Chris Wilson <chris at chris-wilson.co.uk>
        Date:   Wed Feb 25 13:45:26 2015 +0000

            drm: Don't assign fbs for universal cursor support to files

without also having

        commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1
        Author: Daniel Vetter <daniel.vetter at ffwll.ch>
        Date:   Fri Feb 27 12:58:13 2015 +0100

            drm: Fixup racy refcounting in plane_force_disable


Can you try cherry-picking 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 and
see if it solves the problem?


Matt

> 
> On 30/03/2015 21:04, Steven Honeyman wrote:
> >Since updating from 3.19.2 to 3.19.3 I can repeatedly cause a kernel
> >panic just by rebooting or powering off, but it only happens every
> >alternate time!
> >
> >I have a full vmcore kdump (completely new to me, apologies if any of
> >this terminology is off)
> >Hopefully I'm looking in the right place - your names were on the
> >patch affecting the file mentioned here:
> >
> >       KERNEL: /usr/src/linux/vmlinux
> >     DUMPFILE: /home/steven/vmcore.dump
> >         CPUS: 4
> >         DATE: Thu Jan  1 01:00:00 1970
> >       UPTIME: 00:00:38
> >LOAD AVERAGE: 0.20, 0.05, 0.02
> >        TASKS: 163
> >     NODENAME: e6540
> >      RELEASE: 3.19.3-e6540
> >      VERSION: #8 SMP PREEMPT Mon Mar 30 18:32:29 BST 2015
> >      MACHINE: x86_64  (2594 Mhz)
> >       MEMORY: 15.9 GB
> >        PANIC: "kernel BUG at drivers/gpu/drm/drm_crtc.c:536!"
> >          PID: 1
> >      COMMAND: "systemd"
> >         TASK: ffff88040c978000  [THREAD_INFO: ffff88040c94c000]
> >          CPU: 1
> >        STATE: TASK_RUNNING (PANIC)
> >
> >PID: 1      TASK: ffff88040c978000  CPU: 1   COMMAND: "systemd"
> >  #0 [ffff88040c94f780] machine_kexec at ffffffff81039d95
> >  #1 [ffff88040c94f7e0] crash_kexec at ffffffff810fa41a
> >  #2 [ffff88040c94f8b0] oops_end at ffffffff81006590
> >  #3 [ffff88040c94f910] get_parent_ip at ffffffff810af749
> >  #4 [ffff88040c94f920] preempt_count_add at ffffffff810af7a7
> >  #5 [ffff88040c94f930] _raw_spin_lock_irqsave at ffffffff81889466
> >  #6 [ffff88040c94f950] gen6_read32 at ffffffff8146d875
> >  #7 [ffff88040c94fa40] drm_plane_force_disable at ffffffff8140d3d5
> >  #8 [ffff88040c94fa60] restore_fbdev_mode at ffffffff813fbab1
> >  #9 [ffff88040c94fa90] drm_fb_helper_restore_fbdev_mode_unlocked at
> >ffffffff813fdadb
> >#10 [ffff88040c94fab0] drm_fb_helper_set_par at ffffffff813fdb3d
> >#11 [ffff88040c94fac0] intel_fbdev_set_par at ffffffff81498f21
> >#12 [ffff88040c94fae0] fb_set_var at ffffffff8135d3a2
> >#13 [ffff88040c94fc60] fbcon_blank at ffffffff81357a15
> >#14 [ffff88040c94fd60] do_unblank_screen at ffffffff813c5fb2
> >#15 [ffff88040c94fd80] vt_ioctl at ffffffff813bcae8
> >#16 [ffff88040c94fe10] tty_ioctl at ffffffff813b0eae
> >#17 [ffff88040c94fed0] do_vfs_ioctl at ffffffff8119b218
> >#18 [ffff88040c94ff40] sys_ioctl at ffffffff8119b499
> >#19 [ffff88040c94ff80] system_call_fastpath at ffffffff81889df2
> >     RIP: 00007f20c372bb27  RSP: 00007ffed013a2e0  RFLAGS: 00000293
> >     RAX: ffffffffffffffda  RBX: ffffffff81889df2  RCX: ffffffffffffffff
> >     RDX: 0000000000000000  RSI: 0000000000004b3a  RDI: 0000000000000037
> >     RBP: 00007f20c57ec690   R8: 00007ffed013a2a0   R9: 00007ffed0139b30
> >     R10: 0000000000000008  R11: 0000000000000246  R12: 0000000000000004
> >     R13: 0000000000000009  R14: 0000000000000158  R15: 0000000000000001
> >     ORIG_RAX: 0000000000000010  CS: 0033  SS: 002b
> >
> >
> >That's what "crash" tells me from the dump. If I'm looking in the
> >wrong place (it could be systemd to blame... or X... or Dell... or
> >mesa...) then a push in the right direction would be appreciated.
> >If I boot to 3.19.2 then it works as expected.
> >
> >
> >Thanks,
> >Steven
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795