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

[Ian Campbell <ijc@xxxxxxxxxxxxxx>]

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.

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

Ian.

On Tue, 2014-09-23 at 21:07 +0800, James Bromberger wrote:
> (Sorry for the delay, was offlist and didnt see your response Ian, so have 
> now subscribed for this discussion)
> 
> 
> > Isn't the delay actually because the host has exposed a device/vfb/0 to
> > the guest apparently without providing the corresponding backend device?
> 
> Sorry, I'm not aware. All I see is that several distros are removing this 
> module from their initrd and blacklisting it when booting in an HVM 
> environment on EC2.
> 
> 
> 
> > > [   30.969632] xenbus_probe_frontend: Timeout connecting to device:
> > > device/vfb/0 (local state 3, remote state 1)
> 
> > This means that the frontend has reached XenbusStateInitialised (3)
> > while the backend is not responding and has stayed in
> > XenbusStateInitialising (1).
> 
> > I don't know what the chances of getting the host side fixed here, maybe
> > we have to live with some sort of hack in the frontend (or live with the
> > delay). We should be careful not to break things for people with
> > correctly configured hosts though (which might rule out making it
> > modular, not sure).
> 
> 
> Agreed. I am reluctant to add another kernel binary package for EC2 (but 
> perhaps in such a beast we could bump the ixgbevf driver revision
> at http://sourceforge.net/projects/e1000/files/ixgbevf%20stable/ from 
> 2.12.1 to the EC2 recommended 2.14.1 or newer...).
> 
> 
> > FWIW it looks like the upstream kernel already special cases missing
> > pvfb and only waits 30s instead of the 270s it would wait for a more
> > critical device like a disk, so it could be worse!
> 
> > Perhaps upstream would consider a patch which adds a command line option
> > listing devices to ignore/not wait for?
> 
> The status-quo 30 sec wait is perhaps the least disruptive option, but as 
> other distros are able to boot to user space in around 5 seconds (incl 
> Ubuntu), Debian Jessie comes in at 33 seconds due to this. 
> 
> 
> The patch idea sounds nice (but beyond me to contribute). Perhaps an 
> easier patch is to customise the timer to wait for this device 
> (xen_fb_frontend_timeout=1)?
> 
> Thanks
> 
>   James
> 
> 
> 



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