On Wed, Jan 13, 2016 at 10:20 AM, Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> wrote: >> But what with all the pass->dmesg-warn changes above? That's considered >> BAT failure too, we can't afford to sprinkle warnings all over ... And >> it's a bunch of different machines. >> > > Forgot to address this one in previous mail. This patchset > added more debug infra and enabled it for bsw/byt. So assumpion > is that it did uncover a real problem thus the warns. > > Is the policy that if your debug infra reveals problems, > you need to fix those problems? We should discuss this in the next meeting (adding Annie/Jesse for that), but personally I think adding new WARN/ERROR noise should never result in BAT regressions. If your patch uncovers existing failures even in BAT then imo the right approach is to first fix up things, then apply the WARN patch to make sure we don't break things. The problem is that once you have dmesg noise in a test, then no one will notice additional noise and regressions. And that's how we got into our mess last summer. Also dmesg noise is not really acceptable anyway and needs to be fixed (Linus/Dave will get grumpy). If that takes too long because there's lots of warn, then maybe we need to first add the new sanity check at debug level, just to help with tracking down issues. We might need to improve CI reporting so that debug level dmesg is still capture completely for BAT runs. > If so, there is a chicken and egg problem as you don't > always have access to hardware that your debug infra > will cover. Yeah, we need to enable manual submission to CI-machines. Abusing CI as a test facility simply means that you're ok with blocking everyone else with your CI result spam. -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
