APPLIED: [Trusty] Fix framebuffer hangs with VMs using cirrus gfx

Stefan Bader stefan.bader at canonical.com
Mon Feb 3 17:42:44 UTC 2014


On 03.02.2014 18:25, Tim Gardner wrote:
> On 02/03/2014 10:09 AM, Stefan Bader wrote:
>> On 31.01.2014 11:20, Tim Gardner wrote:
>>> Ick.
>>>
> 
>> I got the following feedback from David Herrmann:
> 
>>> This should be fixed by patches #1+#2 in this series: 
>>> http://lists.freedesktop.org/archives/dri-devel/2014-January/052584.html
>>>
>>>
>>>
> I hope we can get it applied this week. Just waiting for a rough
>>> review from airlied. As a workaround, you can always disable 
>>> CONFIG_X86_SYSFB. There is no reason to activate it right now
>>> (until SimpleDRM gets merged..).
> 
>> So we could either revert my patch and disable CONFIG_X86_SYSFB
>> (was there a special reason to enable it or just default policy?)
>> or we wait until these two patches end up in Linux tree and then
>> revert mine in favour of those. I am not sure whether they end up
>> on a stable tree if simplefb is as "in development" as it sounds to
>> me.
> 
>> -Stefan
> 
>> [1]
>> http://lists.freedesktop.org/archives/dri-devel/2014-January/052586.html
> 
> 
> [2] http://lists.freedesktop.org/archives/dri-devel/2014-January/052585.html
> 
> 
> CONFIG_X86_SYSFB likely was enabled as a matter of policy. The help
> text suggests that if you don't know what you're doing then say "Y".
> 
> I'd be inclined to drop your patch and set CONFIG_X86_SYSFB=n.
> 

That would be my thinking as well. That will at least prevent unexpected
breakage that likely will happen when we do not revert it before or when those
upstream patches arrive.
We can simply flip it back to "y" should we really need it. Is that worth an
update in either the policy or the enforcer? At least I am prone to forget why
things were done...

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20140203/eb44c698/attachment.sig>


More information about the kernel-team mailing list