On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote: > On Wed, 30 Aug 2023, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > > On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote: > >> On Fri, Aug 11, 2023 at 02:19:53PM -0300, Helen Koike wrote: > >> > From: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > >> > > >> > Developers can easily execute several tests on different devices > >> > by just pushing their branch to their fork in a repository hosted > >> > on gitlab.freedesktop.org which has an infrastructure to run jobs > >> > in several runners and farms with different devices. > >> > > >> > There are also other automated tools that uprev dependencies, > >> > monitor the infra, and so on that are already used by the Mesa > >> > project, and we can reuse them too. > >> > > >> > Also, store expectations about what the DRM drivers are supposed > >> > to pass in the IGT test suite. By storing the test expectations > >> > along with the code, we can make sure both stay in sync with each > >> > other so we can know when a code change breaks those expectations. > >> > > >> > Also, include a configuration file that points to the out-of-tree > >> > CI scripts. > >> > > >> > This will allow all contributors to drm to reuse the infrastructure > >> > already in gitlab.freedesktop.org to test the driver on several > >> > generations of the hardware. > >> > > >> > Signed-off-by: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > >> > Signed-off-by: Helen Koike <helen.koike@xxxxxxxxxxxxx> > >> > Acked-by: Daniel Stone <daniels@xxxxxxxxxxxxx> > >> > Acked-by: Rob Clark <robdclark@xxxxxxxxx> > >> > Tested-by: Rob Clark <robdclark@xxxxxxxxx> > >> > >> Ok I pushed this into a topic/drm-ci branch in drm.git and asked sfr to > >> include that branch in linux-next. > >> > >> But also I'd like to see a lot more acks here, we should be able to at > >> least pile up a bunch of (driver) maintainers from drm-misc in support of > >> this. Also maybe media, at least I've heard noises that they're maybe > >> interested too? Plus anyone else, the more the better. > > > > I'm not really convinced by that approach at all, and most of the issues > > I see are shown by the follow-up series here: > > I'm not fully convinced either, more like "let's see". In that narrow > sense, ack. I don't see harm in trying, if you're also open to backing > off in case it does not pan out. > > > https://lore.kernel.org/dri-devel/20230825122435.316272-1-vignesh.raman@xxxxxxxxxxxxx/ > > > > * We hardcode a CI farm setup into the kernel > > > > * We cannot trust that the code being run is actually the one being > > pushed into gitlab > > > > * IMO, and I know we disagree here, any IGT test we enable for a given > > platform should work, period. Allowing failures and flaky tests just > > sweeps whatever issue is there under the rug. If the test is at > > fault, we should fix the test, if the driver / kernel is at fault, > > then I certainly want to know about it. > > At least for display, where this also depends on peripheral hardware, > it's not an easy problem, really. Aside from the Chamelium tests, which tests actually rely on peripheral hardware? On EDID and hotplug, sure, but that can easily be set up from the userspace, or something like https://www.lindy-international.com/HDMI-2-0-EDID-Emulator.htm?websale8=ld0101.ld021102&pi=32115 > How reliable do you need it to be? How many nines? Who is going to > debug the issues that need hundreds or thousands of runs to reproduce? > If a commit makes some test less reliable, how long is it going to > take to even see that or pinpoint that? I mean, that's also true for failures or success then. How many times do you need a test to run properly to qualify it as a meaningful test? How do you know that it's not a flaky test? Ultimately, it's about trust. If, for a given test that just failed, I can't be certain that it's because of the branch I just submitted, I will just ignore the tests results after a while. This is already what plagues kernelci, and we should do better. And I'm sorry, but if some part of the kernel or driver just isn't reliable, then we shouldn't claim it is (except for all the times it isn't). If no-one has the time to look into it, fine, but flagging it under a flaky test doesn't help anyone. Like, from that patch, how can I know what is the issue with kms_hdmi_inject@inject-4k or kms_addfb_basic@addfb25-bad-modifier on mt8173. I certainly can't. And neither of those have anything to do with peripheral hardware. Maxime
Attachment:
signature.asc
Description: PGP signature
