Max Staudt changed bug 980750
What Removed Added
Status NEW CONFIRMED
CC   maximilian.staudt@suse.com, xorg-maintainer-bugs@forge.provo.novell.com

Comment # 1 on bug 980750 from
This bug occurs because the DRM driver for the new graphics card is not in the
initrd.

Plymouth waits for udev to clear its queue, assuming that this means "all
devices in the system have been detected and initialized". When booting the
system with the "plymouth:debug" kernel option, Plymouth's log in
/var/log/plymouth-debug.log shows this as "udev coldplug complete".

As discussed in the thread referenced in upstream bug
https://bugs.freedesktop.org/show_bug.cgi?id=95356 this situation happens when
switching root from the initrd to the real root.

At this point, Plymouth will start displaying the splash screen on the graphics
devices existing at that time. If the DRM driver for the graphics card is
included in the initrd, it will have been loaded and replaced any vesafb/efifb
used at early boot time. If, however, the DRM driver is *not* in the initrd,
Plymouth will display its splash screen via vesafb/efifb.

Next, the system will find the DRM driver for the new card on disk, after
switching to the real root. It will attempt to load it, and in the usual case
it will replace vesafb/efifb (see do_remove_conflicting_framebuffers() in the
Linux kernel). However, since Plymouth has opened /dev/fb0 from userspace, the
driver will be unloaded, but the memory region will not be freed. Thus, the DRM
driver cannot reserve all of the card's VRAM, and will error out:

 [   10.375907] fb: switching to bochsdrmfb from EFI VGA
 [   10.375929] Console: switching to colour dummy device 80x25
 [   10.377266] bochs-drm 0000:00:02.0: BAR 0: can't reserve [mem
0xfc000000-0xfdffffff pref]
 [   10.377269] [drm:bochs_hw_init [bochs_drm]] *ERROR* Cannot request
framebuffer
 [   10.377275] Trying to free nonexistent resource
<00000000fc000000-00000000fdffffff>
 [   10.377753] bochs-drm: probe of 0000:00:02.0 failed with error -16

The result is a system where X accesses the GPU directly using the VESA driver,
and the kernel is unable to display its VTs as /dev/fb0 is already gone.

As a workaround, the system can be booted once with "plymouth.enable=0", and
then the initrd can be rebuilt with "mkinitrd". On the next boot, everything
should be working as expected.


You are receiving this mail because: