Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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 <konrad.wilk@xxxxxxxxxx>
> > > 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 to
> > > 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
> > > 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 xen-fbfront.

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.
> > > 
> > > For xen-devel, the first two mails in this thread are
> > > https://lists.debian.org/debian-kernel/2014/09/msg00229.html and 
> > > https://lists.debian.org/debian-kernel/2014/09/msg00233.html
> > 
> > The wait stuff for xenbus devices looks like pre-dates distros handling
> > asynchronous devices with suitable initrds etc.
> 
> Perhaps, but I think most distros still don't use rootwait by default so
> unless / turns up reasonably promptly (single digit seconds) the boot
> may fail.
> 
> > I think we need a command line configurable white list of device types
> > to wait for.  The default should be (to match what was done historically):
> > 
> > PV: vbd, vif, pci, vfb, vkbd.
> > HVM: vbd, vif.
> > 
> > I also think it should be possible to default (via a config option) to
> > an empty white list.
> 
> Irrespective of the above this seems like a reasonable enough idea to
> me.

What about ARM?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel