2013/11/11 Daniel Vetter <daniel@xxxxxxxx>: > 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". And that's the problem I'm trying to solve. We have a solution, it's useful not just for me - you just gave examples of where it would be useful too -, yet, IMHO, you still didn't give a good technical reason on why you're rejecting it. > > Checking dmesg in individual tests really doesn't make much sense imo Well, IMHO it makes a lot of sense. It's even helping me write code, as I already explained. > and > needs to be somewhere where it's done for _all_ testcases. My code is not preventing that. In fact, I think it's helping us get to that point. > QA already has > that in their own testrunner infrastructure, unfortunately that's not > shared with developers so we get to invent a new wheel. I just proposed these new wheels... > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
