From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel.vetter@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
Dave Airlie <airlied@redhat.com>,
Steven Honeyman <stevenhoneyman@gmail.com>
Subject: Re: Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 )
Date: Tue, 31 Mar 2015 09:50:30 -0700 [thread overview]
Message-ID: <20150331165030.GC28205@intel.com> (raw)
In-Reply-To: <551A449B.8020300@intel.com>
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@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-03-31 16:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABz95_ATwGVL+dKoO8UWdd=kLOrTt+C7x9U9JsAZXHZaUt4UdQ@mail.gmail.com>
2015-03-31 6:54 ` Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 ) Daniel Vetter
2015-03-31 16:50 ` Matt Roper [this message]
2015-03-31 17:17 ` Steven Honeyman
2015-04-02 11:02 ` [Intel-gfx] " Jani Nikula
2015-04-13 18:36 ` Steven Honeyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150331165030.GC28205@intel.com \
--to=matthew.d.roper@intel.com \
--cc=airlied@redhat.com \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stevenhoneyman@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.