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
> > > > thanks
> > > >
> > > > 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
> > > > slurps mails from the list.
> > > >
> > > > I'm not sure of the details of the other issue but it involved
> > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1a3b1c8a8d963424c4699efa64dd8986b2f76d7
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 making
> 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
> > > >
> > > > For xen-devel, the first two mails in this thread are
> > > > https://lists.debian.org/debian-kernel/2014/09/msg00229.html
> > > > https://lists.debian.org/debian-kernel/2014/09/msg00233.html
> > >
> > > The wait stuff for xenbus devices looks like pre-dates distros
> > > asynchronous devices with suitable initrds etc.
> > Perhaps, but I think most distros still don't use rootwait by default
> > unless / turns up reasonably promptly (single digit seconds) the boot
> > may fail.
> > > I think we need a command line configurable white list of device
> > > to wait for. The default should be (to match what was done
> > >
> > > PV: vbd, vif, pci, vfb, vkbd.
> > > HVM: vbd, vif.
> > >
> > > I also think it should be possible to default (via a config option)
> > > an empty white list.
> > Irrespective of the above this seems like a reasonable enough idea to
> > me.
> What about ARM?
On ARM (and on PV on HVM x86) we want vfb to work by default if the
xenstore keys are there. But I don't think that it means we need to
wait 30 secs for it at boot. What is a reasonable amount of time to
wait for on a slow and overcommitted system? Maybe 5 to 10 secs?