On Tue, Nov 24, 2015 at 02:10:34PM +0000, Emil Velikov wrote: > Hi Yan, > > The plan of having such a module is pretty sound. > > That said I think that the actual policy/implementation could use some tweaks. > > On 24 November 2015 at 12:14, <[email protected]> wrote: > > From: Yann Argotti <[email protected]> > > Date: Tue, 24 Nov 2015 12:16:34 +0100 > > > > This adds a policy which advises when user should reboot system to avoid > > noisy test results due to system becoming unstable, for instance, and > > therefore continues testing successfully. To do this, a new Dmesg class is > > proposed which is not filtering dmesg and monitors whether or not one of > > the following event occurs: > > - gpu reset failed (not just gpu reset happened, that happens > > way too often and many tests even provoke hangs intentionally) - gpu > > crash, > > - Oops: - BUG - lockdep splat that causes the locking validator to get > > disabled If one of these issues happen, piglit test execution is stopped > > -terminating test thread pool- and exit with code 3 to inform that reboot > > is > > advised. Then test execution resume, after rebooting system or not, is done > > like usually with command line parameter "resume". > > > Shouldn't one check for the above issues and trigger only when GPU > reset was not successful ? > Otherwise the idea of robustness, webgl and friends go down the drain. > > After all I'd imagine that the kernel devs want to know when GPU reset > does not work properly, albeit in a perfect world usespace should not > be able to lockup/crash the GPU. > > From a quick look at the patterns used, it seems that we'll trigger on > any BUG/Oops, regardless of the source - gpu, wifi, fs, etc driver. > This is bound to cause a lot of false positives, esp if the human > being running these tests does not check through the actual messages.
Should the patterns be configured using piglit.conf or similar? I'm thinking about working on a laptop with two graphics cards, and having piglit stop because the other card spewed into dmesg. > These are topics for discussion, rather than a request for changing > the current patch. > > Cheers, > Emil > _______________________________________________ > Piglit mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/piglit
signature.asc
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
