(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 -- Mobile: +61 422 166 708, Email:
james_AT_rcpt.to
|