On 2022-04-06 16:10, Zack Rusin wrote: > On Wed, 2022-04-06 at 10:30 +0200, Michel Dänzer wrote: >> On 2022-04-06 00:47, Zack Rusin wrote: >>> On Tue, 2022-04-05 at 19:09 +0200, Michel Dänzer wrote: >>>> On 2022-04-04 20:21, Zack Rusin wrote: >>>>> From: Zack Rusin <zackr@xxxxxxxxxx> >>>>> >>>>> By default each flip times out after 0.1 sec >>>> >>>> 10 * HZ is 10 seconds, not 0.1. >>> >>> Yea, sorry, this entire commit message is not correct. I've sent >>> out a >>> very old diff with a log the best I could remember. I recall our >>> conversation now and iirc we said that maybe an interface through >>> drm >>> atomic code to enable/disable this error is the way to go but after >>> looking at this again I'm not sure. More below. >>> >>>>> and a warning about the time out is added to the kernel log. >>>>> The >>>>> warning is >>>>> harmless because there's another flip coming right after but it >>>>> can >>>>> quickly fill up >>>>> the log, e.g. missing 2 flips every second over a 24 hour span >>>>> will >>>>> add about 172 thousand lines to the log. >>>> >>>> As we discussed before, while this might be true for the vmwgfx >>>> driver, >>>> for other drivers this message indicates that either the GPU >>>> hung, or >>>> something else went wrong spectacularly. As such, I think we do >>>> want to >>>> see these messages by default for other drivers at least. >>> >>> I'm not going to argue for or against that but I am curious what's >>> the >>> point of the message. The message is basically saying "something >>> could >>> possibly have went very wrong". OK, what's next? Especially if >>> there's >>> no visible problems and it's not reproducible. Even if it would be >>> reproducible there's nothing actionable from the message itself. If >>> the >>> system has no output connected and no users are currently logged in >>> and >>> we missed a flip, does it matter? >> >> I don't think waiting for a 10 second timeout is the appropriate >> behaviour in that case. While a KMS CRTC is enabled, the driver needs >> to make it work, in the worst case via a timer which ticks at the >> CRTC refresh rate. > > What if it isn't a driver bug Does it make a difference? It's still a bug. > and it just so happens that vmwgfx is the only one that's running on some specific system > without a display long enough? FWIW, other drivers have hit this same error before as well, but not just because no outputs were enabled. If it's really related to that, a vmwgfx bug seems most likely. >> The error means that either: >> >> * A flip actually didn't complete in 10 seconds. >> * There's some kind of time tracking issue which results in the timer >> firing after less than 10 seconds (of the system actually running). >> >> Either way, it's an issue which should be fixed rather than just >> swept under the rug. > > Without being able to reproduce or really confirm that it's an actual > problem in vmwgfx I'm going to leave this to you then. Nice try. :) This is for vmwgfx developers. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
