<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [IGT] kms_frontbuffer_tracking@fbc-*draw* has inconsistent results - FBC disabled | Failed assertion: !fbc_wait_until_enabled()" href="https://bugs.freedesktop.org/show_bug.cgi?id=101623#c62">Comment # 62</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [IGT] kms_frontbuffer_tracking@fbc-*draw* has inconsistent results - FBC disabled | Failed assertion: !fbc_wait_until_enabled()" href="https://bugs.freedesktop.org/show_bug.cgi?id=101623">bug 101623</a> from <a class="email" href="mailto:przanoni@gmail.com" title="Paulo Zanoni <przanoni@gmail.com>"> Paulo Zanoni</a> <pre>(In reply to Marta Löfstedt from <a href="show_bug.cgi?id=101623#c60">comment #60</a>) > (In reply to Paulo Zanoni from <a href="show_bug.cgi?id=101623#c59">comment #59</a>) > > (In reply to Marta Löfstedt from <a href="show_bug.cgi?id=101623#c57">comment #57</a>) > > > We have pulled in more data from the shards testlist runs on BAT machines. I > > > am not going to spam all links here just some examples. For overview of the > > > results see: > > > <a href="https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html">https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html</a> > > > > > > (kms_frontbuffer_tracking:2822) WARNING: fbc_is_enabled()? > > > FBC disabled: mode too large for compression > > > > This is an entirely different bug. > > > > Please go to the BIOS of the machine and increase the amount of stolen > > memory. > > > > Thanks, > > Paulo > > Thanks for the feedback, I do agree that this bug is a big mess, but that is > what happens when bugs are not solved in reasonable time. That's not a valid excuse. If no developer has time to look into a bug, making it harder to look will only make it worse. > If you can define > exactly how you want the bug to be split up based on information given in > the results, I will do that. Different types of problems in different bugs? I mean, that is very simple. Also, joining separate bug reports for the same thing is 1000x easier than splitting a single bug report into separate bugs. But perhaps first you could look into the stolen memory BIOS solution and the current IGT patch we have (written by you), then after doing these things we see what's left. > However, the problem with the current version > of cibuglog is that once I have filed a (machine, test) pair on an issue I > will not see any new results from that pair. So, since a lot of machines > flip-flop on various failure on this test it will be random what issue I > will file on first. This will be fixed with the new cibuglog that Martin > Peres is working on. Having bad tools is not an excuse for filing bad bug reports.</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 QA Contact for the bug.</li> </ul> </body> </html>