<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body><a class="email" href="mailto:TomWij@gentoo.org" title="Tom Wijsman <TomWij@gentoo.org>"> Tom Wijsman</a> changed <a class="bz_bug_link bz_status_NEW " title="NEW --- - [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version" href="https://bugs.freedesktop.org/show_bug.cgi?id=58378">bug 58378</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">CC</td> <td>TomWij@live.com </td> <td>TomWij@gentoo.org </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version" href="https://bugs.freedesktop.org/show_bug.cgi?id=58378#c38">Comment # 38</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version" href="https://bugs.freedesktop.org/show_bug.cgi?id=58378">bug 58378</a> from <a class="email" href="mailto:TomWij@gentoo.org" title="Tom Wijsman <TomWij@gentoo.org>"> Tom Wijsman</a> <pre>(In reply to <a href="show_bug.cgi?id=58378#c37">comment #37</a>) > This also means that you are NOT regularly pulling the updates from Linus' > central git into the nouveau git, but typically only do this ONCE after > Linus released a new version (here: 3.4.0) That usually is done as often as necessary; if one does it more often, it could lead to situations where you have pulled a new broken commit that could slow down Nouveau development. And thus, pulling major releases is efficient. > and then NOT for any minor > subsequent release by Linus (3.4.1, 3.4.2 and so on) Note that those releases happen by Greg KH and consist of backported patches. > but ONLY shortly > before he opens the "rc" pull window for his next release series (here: > 3.5-rc1). That would be one possible moment where the conditions are ideal enough to pull. Though I am in doubt whether it matters when this was pulled from Linus. If you don't like to bisect the Nouveau development branch, you can bisect kernel git. > Besed on this, I did further testing: > > Both "5e120f6e4b3f35b741c5445dfc755f50128c3c44^" and > "5e120f6e4b3f35b741c5445dfc755f50128c3c44" do still run fine, i.e. the > commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 - which actually introduced > the nv84_fence - does NOT seem to be causing the distortion issue. > > I will now move forward (slowly, as I need to do the tarball-based rpmbuild > process), and keep you updated on my findings. You really want to be doing a git bisect to do the least amount of work; I don't see what you mean by "move forward" but I really hope that you are testing the commits in a binary tree style. You can put the tarball-based process in a script so you only need to run a single command after moving further in the bisection.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>