Comment 21 for bug 1100386
Revision history for this message
| Andy Whitcroft (apw) wrote Re: Raring server installations on VMs fail to reboot after the installations | #21 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I have managed to reproduce the apparent hangs, the recovery mode issues I have not; if they still exist they should be filed under a different bug.
For the apparent hangs, I have managed to confirm they are not hangs at all. What has happened is that we have lost the console completely. The kernel attempted to switch framebuffer devices and failed to do so, it successfully removed the efifb but failed to initialise cirrusfb. Now there is nothing to display console output. If you know the IP address of the image however it is pingable, and with openssh installed it is possible to login. Errors in the dmesg as below:
[ 2.701082] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
[ 2.704007] Console: switching to colour dummy device 80x25
[ 2.717086] [drm:cirrus_
[ 2.717093] cirrus 0000:00:02.0: Fatal error during GPU init: -6
Now this is something we have seen before. We are using efifb (a generic driver) but want to use a device specific driver to get 3d support. If plymouth opens the framebuffer before we switch over then we get into a hole where we cannot completly remove the old driver and as they share the same VRAM we cannot initialise the new one.
The correct solution would be to make the kernel able to force the open driver to close on plymouth and to allow the new one to start. We would also then need to fix plymouth to cope with the case where the framebuffer closes harshly on it and reconnect.
What we have done in the past (for vesafb) was to delay loading vesafb until after the better driver has had a chance to take and use the device, falling back to vesafb only when it did not appear. We cannot do this quite the same for efifb as it has to be builtin, but we can prevent efifb being identified as a primary framebuffer. This will mean we normally not start plymouth splash until after we have had a chance to detect the cirrus driver. If there is no alternative however, we will use efifb from the normal fallback path as used for vesafb. We have confirmed that vesafb will not load in this case as efifb has already claimed the device. Patch to follow.