Date: Mon, 15 Sep 2014 21:05:21 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 193500] Interrupt storm after loading i915kms module on Gen4 Intel GPU Message-ID: <bug-193500-8-LTfkB00300@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193500-8@https.bugs.freebsd.org/bugzilla/> References: <bug-193500-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193500 --- Comment #16 from Jan Kokem=C3=BCller <jan.kokemueller@gmail.com> --- Created attachment 147363 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147363&action= =3Dedit ktrdump while loading i915kms (debug.ktr.mask=3D4) (In reply to Konstantin Belousov from comment #15) > So can you describe what the problem is and why your patch help ? My best guess is that it's some kind of initialization problem regarding the interrupts, because the behavior stops after a suspend/resume cycle. The problem started with (or was uncovered by) the opregion code changes. If I = stub out intel_enable_asle the problem goes away. The patch makes it so that intel_enable_asle gets first called only after I disable/enable the interru= pts of the card. Then there is no interrupt storm anymore. I'll try to debug th= is further. > To see what kind of interrupt causes the storm, compile kernel with KTR_D= RM > and enable ktr(4) tracing for it. I compiled the kernel with KTR, and enabled KTR_DRM by setting "sysctl debug.ktr.mask=3D4". Then I loaded an unpatched i915kms module. I've attach= ed the log (interesting events are from 34 to 48). It seems only the interrupts on irq260 are accounted for. Any way I can trace the interrupts on irq16? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193500-8-LTfkB00300>