<daniels>
anarsoul: I don't know what's going on with the BayLibre CI stuff :( we might be able to put it into our lab but are currently working on Bifrost, AMD, and Intel machines so it'd have to go into the queue after those
Net147 has quit [*.net *.split]
gcl has quit [*.net *.split]
champagneg has quit [*.net *.split]
Net147 has joined #lima
gcl has joined #lima
champagneg has joined #lima
Ntemis has joined #lima
Ntemis has quit [Read error: Connection reset by peer]
Barada has quit [Quit: Barada]
<anarsoul>
narmstrong: ping?
<anarsoul>
enunes: maybe it's time to bring up our own CI? :)
<enunes>
anarsoul: it is a possibility, I have 4 boards currently set up as my own jenkins pipeline for nightly tests with mesa master
<enunes>
they seem to be running fairly stable with container tests 19:58:04 up 107 days, 2:07, 1 user, load average: 0.00, 0.00, 0.00
<anarsoul>
I'm not sure if 4 is enough for gitlab CI
<enunes>
yeah it's also more load on them to be there I guess
<enunes>
I have 2 more but I reserved 1 for testing changes and 1 to replace in case one failed
<anarsoul>
btw, you recently mentioned that you have 2916 failures in deqp
<anarsoul>
do you have any GPU errors?
<anarsoul>
if yes, likely some of these failures are caused by tainted GPU context (once we get a GPU error kernel driver stops executing any jobs for the context)
<anarsoul>
I believe we had only couple hundreds failures in gitlab CI
<enunes>
on kernel there are no errors
<enunes>
I might just have a different set of skips
<enunes>
I haven't been looking at them looking for errors, only for regressions while working on something else
<anarsoul>
maybe
<anarsoul>
although there were not a lot of skips
<anarsoul>
maybe there's a state leak somewhere
<enunes>
the results I posted to some issue were from a run on a freshly booted board, I don't think there is something like that
<anarsoul>
enunes: I mean state leak between the tests
<anarsoul>
IIRC dEQP reuses GPU context
<enunes>
ah I see, well in that case it might be
<enunes>
but then I'd expect gitlab CI to hit the same
<enunes>
unless the runner there runs differently than the regular deqp runner
<anarsoul>
enunes: unless we skip tests that leak the state
<enunes>
I guess a script can be made to run with each individual test per launch, and leave it running overnight, to see if there is any difference
<anarsoul>
rellla may have something like that
<narmstrong>
anarsoul: hi, I know but I don’t have time now to fix it and I hoped at the time I was not the only provider for Lima and t820 ci to avoid a punctual lab failure
<narmstrong>
daniels: the failure occurs when the lab is filled up with kCI jobs and the Mesa jobs are too long to be scheduled
<narmstrong>
daniels: since everything is under a single master and the slave runs Mesa and kCi jobs it’s inevitable
<narmstrong>
It would be safer to a have a Mesa dedicated slave/board but I have not extra time nor HW to spend on this right now
<narmstrong>
And I would have hoped to see vim2 and Lima HW on another lab, but the way gitlab-ci and lava are interconnected is crap and would need a full rework to make it effective
<narmstrong>
But same, I have no extra time to investigate the docker-machine over lava stuff I wanted to implement
<anarsoul>
narmstrong: how many boards do you have in the lab?