<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] Fix_stuck_on_bsd_ring for Clarkdale/Ironlake and kernel 4.4.x" href="https://bugs.freedesktop.org/show_bug.cgi?id=99737#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] Fix_stuck_on_bsd_ring for Clarkdale/Ironlake and kernel 4.4.x" href="https://bugs.freedesktop.org/show_bug.cgi?id=99737">bug 99737</a> from <a class="email" href="mailto:jrf@mailbox.org" title="Rainer Fiebig <jrf@mailbox.org>"> Rainer Fiebig</a> <pre>(In reply to Jani Nikula from <a href="show_bug.cgi?id=99737#c4">comment #4</a>) > This bugzilla is about bugs that are unresolved in our current upstream > kernel tree. I'll take your word for how long it took to fix the bug, it > certainly seems it took too long, but as I understand it, it's fixed now. > Lapsus memoriae on my side: "stuck on bsd ring" started with 4.3 not 4.2 (I kept a log). So, only 5 instead of 6 kernels until fix. But given the amount of time and quality of life I lost due to "stuck...", I won't apologize. ;) > The stable kernels (with the three level version numbers x.y.z) are based on > released upstream kernels (x.y) with backports of fixes from later kernels. > How big the .z is merely the number of times a batch of fixes has been > backported to the stable kernel. It's not a measure of quality or how much > development effort has been put to it. > > The fixes to be backported to stable kernels must adhere to a pretty strict > set of rules [1]. For example, the fix must exist in a later upstream > kernel, and it cannot be bigger than 100 lines, with context. Your proposed > fix is 500+ lines, and as such won't be considered. (And we don't maintain > the stable kernels or backports.) > Alright, then it won't get fixed. The a/m 2 committs cannot be backported easily, the differences between 4.7/4.8 and 4.4 are too big. The patch is 500 lines for a reason. That doesn't mean that it cannot be compressed down to 100 lines. You i915-devs surely can but I can't. > The kernel is a fast moving target, and from upstream perspective v4.4 is > old. Just in drm/i915 the diffstat since then is 211 files changed, 103334 > insertions(+), 48260 deletions(-). It's not trivial to assess the validity > of a backport across such a diff. > Not trivial but not impossible either. If *I* as average user could analyze the problem, find the 2 committs, solve the puzzle between vastly apart kernels and come up with a patch despite huge differences in code, any of you experienced i915-devs should be able to check and improve that patch with significantly less effort and time than it took me to produce it. > I can only recommend to consider upgrading to a more recent kernel release > (and that does not mean a more recent stable .z release of an old kernel). > The "stuck on bsd ring"-story recommends exactly the contrary. For me it's no longer a problem: I have a patch - and I can easily switch to post-4.7 or pre-4.3. But not all users of affected distros can. I wouldn't mind if you closed this well-intentioned but obviously ill-placed report. > [1] <a href="https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html">https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>