Piglit was changed to consider stderr output as WARN, and this exposed problem with kms_flip@basic-flip-vs-wf_blank test on older gens (Gens 4 to 7) Affected testhosts: Broadwater, Eagle Lake, Cantiga, Iron Lake, Sandy Bridge, Ivy Lake, Haswell-R (curiously, not Haswell K-CPUs) Errors are in form: (kms_flip:2174) WARNING: vblank interval differs from modeline! expected 16665.6us, measured 16717us +- 0.000us, difference 51.4us (inf sigma) (kms_flip:2174) WARNING: vblank interval differs from modeline! expected 16665.6us, measured 16717us +- 0.250us, difference 51.5us (205.9 sigma) (kms_flip:2174) WARNING: vblank interval differs from modeline! expected 16666.7us, measured 16633us +- 0.250us, difference 33.6us (134.4 sigma) (kms_flip:2174) WARNING: vblank interval differs from modeline! expected 16666.7us, measured 16633us +- 0.250us, difference 33.6us (134.4 sigma)
I've seen this error in bug 100215 too. It appears to be that with 36 bpp the fake dongle gets a clock speed slightly different from the expected vblank interval, so this is a real bug. Is kms_setmode.basic consistently failing with the same error too btw?
(In reply to Maarten Lankhorst from comment #1) > I've seen this error in bug 100215 too. It appears to be that with 36 bpp > the fake dongle gets a clock speed slightly different from the expected > vblank interval, so this is a real bug. Good to know. > > Is kms_setmode.basic consistently failing with the same error too btw? Well, whenever it fails, it has this warning. So, I guess it must always be there!
(In reply to Maarten Lankhorst from comment #1) > I've seen this error in bug 100215 too. It appears to be that with 36 bpp > the fake dongle gets a clock speed slightly different from the expected > vblank interval, so this is a real bug. I wouldn't go as far as claiming this is a bug. The difference (at least in the snippets in comment #1) is .2%-.3%, which well within the .5% limit that VESA has specified in some standard. There is a real bug in the driver in that it doesn't actually check if the clock we got is close enough or not. But if we had such a check (and it used the .5% as its guideline) then it wouldn't have tripped in this case. The state readout does do a check like that but I think it allows the error to be quite big.
Fixed in IGT (https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=1345a21886d7606b59225d3c4f5e03fa913e1ac7).
Yeah, but note it's still broken in kms_setmode.basic, but I guess it's good enough for this specific bug. :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.