Alberto Milone wrote:
> On Wednesday 09 Dec 2009 14:52:41 you wrote:
>> Alberto Milone wrote:
>>> Hi all,
>>> SRU Justification:
>>> The problem described in this email was reported in a private OEM bug
>>> report for Dell and has been solved by upstream. It's a regression in the
>>> drm code which causes a massive system slowdown if we turn off the VGA
>>> The patch is sane and minimal and is available in the drm-intel branch
>>> and in the linux-next branch (see the link to the commit in the bug
>>> I have applied (and slightly adapted, as it didn't apply cleanly to our
>>> lucid and karmic git branches) and tested the patch successfully in
>>> The integration of this patch is very important for our Dell projects and
>>> for the Ubuntu desktop at large.
>>> Please include the attached patch in both Karmic and Lucid ASAP.
>>> Bug #494461
>>> Thanks in advance for your time.
>> This should actually have gone to stable as well as it fixes a regression.
>> Also the description sounds like the integration path should be stable as
>> well (as long as that is open).
>> The patch itself looks like it changes semantics of an exported function.
>> Before additional calls to drm_vblank_get() would return ok and increment
>> the ref count. After the change, additional calls will return an error and
>> not increment the count. On the good side it seems that function is only
>> used within drm_irq.c and the usage seems to be ok to handle that change.
>> Currently not 100% convinced to ack, but might get convinced.
> Hi Stefan,
> I discussed this with Jesse (who reviewed the patch). It's ok to return an
> error in drm_vblank_get().
> Think of the case in which a client (a direct rendered 3d app such as compiz
> or a game) tries to wait on a pipe that is off (e.g. due to dpms), the client
> would do so, but if the pipe went off after a client waited, the client might
> never wake up. Furthermore if a pipe went off we might not catch it for a
> while. For this reason it's ok to return the error to the client.
> Furthermore the patch seems to be in the stable branch too:
> stable.git;a=commit;h=778c902640530371a169ad1c0356 6e7c51b09874
Just to note, this is the unified stable tree, which is not
stable. I believe it has Linus tree as master and stable branches
which, as I was told, get automatically created from the real
> I hope both facts (especially the latter) can fully convince you, and if they
> don't, I'll try harder
kernel-team mailing list