On 24/09/14 11:23, Stefano Stabellini wrote:
> On Tue, 23 Sep 2014, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 23, 2014 at 04:57:26PM +0100, Ian Campbell wrote:
>>> On Tue, 2014-09-23 at 16:43 +0100, David Vrabel wrote:
>>>> On 23/09/14 15:30, Ian Campbell wrote:
>>>>> create !
>>>>> title it "30s delay loading xenfb driver on some systems"
>>>>> owner it Konrad Rzeszutek Wilk
>>>>> Hi James,
>>>>> Some of the other Xen devs were discussing an issue which sounded
>>>>> awfully similar to this one, so I am copying the xen-devel list and
>>>>> creating a Xen bug to track the issue, please CC xen-devel (no need
>>>>> subscribe but you may be moderated the first time), since the tracker
>>>>> slurps mails from the list.
>>>>> I'm not sure of the details of the other issue but it involved
hopefully Konrad or one of the others will follow up.
>> That was with an HVM guest running under Xen 4.1 in which this
>> guest config was used:
>> vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
>> Xend would create an XenStore keys for the PV framebuffer and also
>> sure that QEMU VGA driver was running. The end result was that the guest
>> would boot up to Xorg VGA driver, but the frame buffer console (so from
>> the moment GRUB2 started Linux up to Xorg) would try to use the
>> And since this is HVM guest and VNCviewer was slurping contents from the
>> VGA buffer - which was not used at all - we wouldn't get anything.
>> Reverting the above patch fixed the issue.
> If you have a vfb line in your config file, aren't you actually
> explicitly requesting a vfb frontend/backend pair?
> XenD is just doing what the user asked him to do, I wouldn't call this a
> What is strange is that given that there is no running vfb backend for
> HVM guests in a regular Xen 4.1 installation, xen-fbfront could never
> reach the "connected" state ("4" on xenstore): so why is Linux trying to
> use vfb when the frontend is not even connected?
> The reason is that xenfb_probe calls register_framebuffer and
> xenfb_make_preferred_console too early, before even knowing if the
> backend is alive.
> I would move the register_framebuffer and xenfb_make_preferred_console
> calls in xenfb_backend_changed, case XenbusStateConnected. That should
> fix it.
I don't think that will help. Registering the frontend driver will
still wait for CONNECTED, regardless of whether the frame buffer will
actually be used.