[Bug 106832] [i915]Kernel panic occurs after ECHO 15 to /sys/kernel/debug/dri/0/i915_wedged

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106832

Joonas Lahtinen <joonas.lahtinen at linux.intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #6 from Joonas Lahtinen <joonas.lahtinen at linux.intel.com> ---
As discussed, the resulting logs need to be from an actual real-world use case,
so that we can make sure we're working to fix the actual issue, not just what
appears to be a similar synthetic use case through debugfs.

And that use case needs to be valid for the LTS to consider backporting
non-trivial patches. At the time of any kernel release, we can't really predict
all the future usecases but expect testing to take place during development
window and release candidates. For LTS the promise is to keep supporting the
existing use cases per name (long-term support). It's not long-term development
kernel, where we introduce stuff that had never been thought of before.

The referred to media solution here did not even exist in Open Source at the
time of 4.14 development, so it should not come as a surprise that a kernel
preceding it in time is not supporting it out of the box.

We continually improve the upstream driver, but we can't duplicate all the
improvements into the LTS/stable kernels just because "they might help" some
userspace that comes in the future. Because that would make the LTS kernel
equal the drm-tip and take away the benefits of the LTS release for the users
who have provided testing during the development and release candidates, and
are relying on the stability of that tree for the usecase they have. That is
very much the danger with the patches like bisected here, which literally
changes how the driver interacts with the hardware.

But, after seeing the real world use case, we can still actually *try* to see
what can be done to mitigate the issue with minimal changes.

Thus, the reporter has been instructed to re-open a bug with a real use case
and description of that issue.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180606/308de965/attachment.html>