On Mon, Nov 11, 2013 at 04:25:36PM -0200, Paulo Zanoni wrote: > 2013/11/11 Daniel Vetter <daniel@xxxxxxxx>: > > On Mon, Nov 11, 2013 at 03:06:10PM -0200, Paulo Zanoni wrote: > >> From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > >> > >> We recently fixed a bug where it was impossible to do I2C transactions > >> on eDP panels when they were disabled. Now it should be possible to do > >> these transactions when the panel is disabled, but there's a race > >> condition that triggers dmesg errors if we try do do the I2C > >> transactions and set a mode on the panel at the same time. This > >> program should reproduce this bug and check dmesg for errors. > >> > >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > > > > Like I've said in the previous mail I think the generic dmesg error > > checking should be somewhere generic (and probably in piglit). Otherwise > > the test looks good. And the naming also matches the new convention ;-) > > Then this test will always give a SUCCESS. Not really what I wanted :( It's not the only one. We have tests that only annoy the in-kernel debug features like lockdep, object use-after-free and other stuff. Or all the WARN backtraces from testdisplay. And very often they all "succeed". Checking dmesg in individual tests really doesn't make much sense imo and needs to be somewhere where it's done for _all_ testcases. QA already has that in their own testrunner infrastructure, unfortunately that's not shared with developers so we get to invent a new wheel. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
