graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)

reproducible with alternate installer as well.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1038055

Dmitrijs,

Which video driver are you using in your VM?

Installing from a quantal alpha 3 server image, I see the following in dmesg in KVM:

[ 2.900838] [drm] Initialized drm 1.1.0 20060810
[ 2.975879] checking generic (fc000000 160000) vs hw (fc000000 2000000)
[ 2.975885] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
[ 2.975914] Console: switching to colour dummy device 80x25
[ 3.010796] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
[ 3.010805] cirrus 0000:00:02.0: Fatal error during GPU init: -6
[ 3.010809] Trying to free nonexistent resource <00000000febf4000-00000000febf4fff>
[ 3.010814] Trying to free nonexistent resource <00000000fc000000-00000000fc3fffff>

This is when using gfxpayload=keep. If I manually switch to gfxpayload=text, I don't see this problem - there is no "EFI VGA" mentioned in dmesg.

When the problem occurs, I get a plymouth full-screen text splash, which can't be cleared (because the console is apparently dead). ssh'ing in and using chvt doesn't work. /proc/fb is empty. plymouth has run and exited successfully, leaving no error logs in /var/log/upstart.

> Disabling splash, brings up text interface to unlock the drive & allows to boot.
How did you disable splash? For me, disabling the 'splash' commandline option is insufficient unless I also disable the grub fb handoff.

Anyway, the bug I'm seeing is definitely a kernel bug, but I don't know if it's the same as your bug.

> How did you disable splash? For me, disabling the 'splash' commandline option is insufficient unless I also disable the grub fb
> handoff.

Edit /etc/default/grub && update-grub

Fetching the driver info now.

Also I did:
sudo cp /usr/shre/grub/unicode.pf2 /boot/grub/

Let me try gfxpayload=keep

For reference, configuring the handoff is done by setting GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub.

precise guest works fine
quantal guest does not

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1038055

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

plymouth itself doesn't seem to be doing anything wrong; it just doesn't have a usable video device. So this is a bug in the kernel cirrus driver.

AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.5.1-0ubuntu2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info: Error: [Errno 2] No such file or directory
Card0.Amixer.values: Error: [Errno 2] No such file or directory
CurrentDmesg:

DistroRelease: Ubuntu 12.10
HibernationDevice: RESUME=UUID=990f3177-9cff-4b64-80fb-fdeb8750436b
InstallationMedia: Ubuntu-Server 12.10 "Quantal Quetzal" - Alpha amd64 (20120724.5)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Bochs Bochs
Package: linux (not installed)
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-11-generic root=UUID=5dea3f0f-f517-4bdc-9066-dd11770e5e79 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.5.0-11.11-generic 3.5.2
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-11-generic N/A
 linux-backports-modules-3.5.0-11-generic N/A
 linux-firmware 1.90
RfKill: Error: [Errno 2] No such file or directory
Tags: quantal
Uname: Linux 3.5.0-11-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 01/01/2007
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr:
dmi.product.name: Bochs
dmi.sys.vendor: Bochs

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1038055

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/

Using:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/
 linux-headers-3.6.0-030600rc3-generic_3.6.0-030600rc3.201208221735_amd64.deb
 linux-headers-3.6.0-030600rc3_3.6.0-030600rc3.201208221735_all.deb
 linux-image-3.6.0-030600rc3-generic_3.6.0-030600rc3.201208221735_amd64.deb
 linux-image-extra-3.6.0-030600rc3-generic_3.6.0-030600rc3.201208221735_amd64.deb

The bug is still there.

Steve, if you can could you please test it in your VM as well... cause I don't feel like triggering full git bisect against precise -> quantal kernel.

Hmm. So I just installed http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/linux-image-3.6.0-030600rc3-generic_3.6.0-030600rc3.201208221735_amd64.deb and it worked fine for me.

$ cat /proc/fb
0 EFI VGA
$

The cirrus drm fb driver doesn't get mentioned in dmesg at all.

Whoops, I didn't have linux-image-extra installed. Once I install this (bringing in the cirrus drm driver again), it breaks in the same way. So yes, I confirm Dmitrijs's result.

Is this cirrus drm driver new? Perhaps it should be disabled in the package for now?

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Also, this has been added to the kernel team hot list for review.

As a work-around, you may be able to blacklist the cirrus kernel module.

On Tue, Aug 28, 2012 at 07:09:14PM -0000, Joseph Salisbury wrote:
> As a work-around, you may be able to blacklist the cirrus kernel module.

Given that KVM is the dominant use case for the cirrus driver, can I suggest
that this be done in the kernel package itself by not building the broken
driver until this is resolved?

I'm seeing this without LUKS as well (server install using the 2012-09-01 iso); first reboot after install fails
(stick at the text mode purple screen with 0-1 dot lit); using an LVM (but no luks) install.
It did boot after about the 3rd try on one vm, and the 2nd try on the other vm, but I can see the cannot reverse vram

Note also I couldn't get a Grub menu up, which makes me wonder if it's just the guest kernel that's to blame.

The other observation is that the VM is now getting a 1280x1024 display, while I'm sure it used to be smaller;
not sure where the larger size has come from, but perhaps that's more of a problem for the VRAM allocation
(although I think it's supposed to have 9MB so should be fine)

The cirrus driver is build out of the CONFIG_DRM_CIRRUS_QEMU configuration option which is new in Quantal. It may well be worth bashing it off for the moment. That said another bug on this issue claims to have fixes for the X server for this: LP#1039648. Perhaps someone could test the packages implied there and confirm/deny this.

Andy,

On Tue, Sep 04, 2012 at 05:09:28PM -0000, Andy Whitcroft wrote:
> The cirrus driver is build out of the CONFIG_DRM_CIRRUS_QEMU
> configuration option which is new in Quantal. It may well be worth
> bashing it off for the moment. That said another bug on this issue
> claims to have fixes for the X server for this: LP#1039648. Perhaps
> someone could test the packages implied there and confirm/deny this.

This isn't an X server issue. The framebuffer is completely bustificated
and leaves the system with no console.

I wonder whether that is to some degree related to the doings of the x driver, too. When there still was a clash, I got a drm'ed console as the fallback of lightdm not starting (slightly unusable because it chooses quite a high resolution). I can confirm now that lightdm comes up readable but the desktop won't start and switching to the vt causes corrupted output. Switching back to vt7 and lightdm is possible (sure it is not very helpful).

No, this has *nothing* to do with X. This is breaking the console way before X would ever start - it's preventing *plymouth* from running.

So maybe some interaction with plymouth? Unfortunately it is not really consistent in behaviour. This morning I got the usual lightdm ok and switch to vt shows corruption. Then I played with some config options:

remove "splash and vt_handoff" resulted in lightdm ok and vt ok (though high resolution)
adding "nomodeset" resulted in lightdm ok and vt ok (standard vga resolution)

however after that booting with the default config options (twice) still works as if "splash vt_handoff" had been removed.

And right now even unity desktop came up with the default options. Switching from desktop to VT works and back. Apport reported a (likely previous) X crash which I let create bug #1046204. Does this miracle happen to others, too (after fiddling with the boot options like above)?

Stefan

I can reproduce this issue fairly reliably using the scripts that I wrote for testing ubuntu server on iscsi root.

I don't have to fiddle with the boot options at-all.

James, I can also reproduce it most of the time just by booting. It just is not always consistent. After the two "good" reboot runs I did shut down the guest and then start it again which brought things back to failing and this time removing "quiet vt_handoff" does not work either. In this case trying to bring up the unity desktop seems to fail as well. Currently the only consistent option seems to be "nomodeset" which allows have a ligthdm and to switch to text console, but fails to bring up the unity desktop.
Feels like a race in some of the parts involved.

Hm, I think that might be missing hint. I have a ssh server running to log in that way (using the nomodeset and the vt could be installed in the broken state). And I stumbled into the working state again. Comparing the xorg.log files I found that when things work, the cirrus module seems to have finished loading and prevents the cirrus x-driver from getting active:

[ 11.447] (EE) cirrus: The PCI device 0xb8 at 00@00:02:0 has a kernel module claiming it.
[ 11.447] (EE) cirrus: This driver cannot operate until it has been unloaded.
...
[ 11.448] (II) modesetting(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/24
[ 11.448] (==) modesetting(0): Depth 24, (==) framebuffer bpp 24

However in the case where lightdm works but switching to a text console does not, there was a problem with drm device:

[ 12.015] (EE) open /dev/dri/card0: No such file or directory
[ 12.016] (EE) open /dev/fb0: No such file or directory
...
[ 12.018] (II) CIRRUS(0): initializing int10
[ 12.020] (II) CIRRUS(0): Primary V_BIOS segment is: 0xc000
[ 12.020] (II) CIRRUS(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/24
[ 12.020] (--) CIRRUS(0): Depth 24, (==) framebuffer bpp 24

Looking at the syslog for cirrus, the current (good) run has

Sep 5 12:05:28 ubuntu-virtual-machine kernel: [ 8.609150] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
Sep 5 12:05:28 ubuntu-virtual-machine kernel: [ 8.667602] fbcon: cirrusdrmfb (fb0) is primary device
Sep 5 12:05:28 ubuntu-virtual-machine kernel: [ 8.674590] fb0: cirrusdrmfb frame buffer device
Sep 5 12:05:28 ubuntu-virtual-machine kernel: [ 8.674599] [drm] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0

but the previous (bad) one had this:

Sep 5 11:57:51 ubuntu-virtual-machine kernel: [ 9.838015] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
Sep 5 11:57:51 ubuntu-virtual-machine kernel: [ 9.865736] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
Sep 5 11:57:51 ubuntu-virtual-machine kernel: [ 9.865757] cirrus 0000:00:02.0: Fatal error during GPU init: -6

Now need to find out why this fails sometimes.

Still not exactly sure how this races, though some things are a bit odd here. Generally the approach to replace the EFI FB console looks like what i915 would do, too. Using remove_conflicting_framebuffers() the EFI FB gets removed. Then in cirrus_driver_load() it first request the resources for mmio, and then the memory region for the VRAM. This fails sometimes.
But also there is a mismatch of sizes. The pci config defines the region as 32M, the virt-manager config and the TTM message declare 9M of VRAM, but the driver requests 4M.

Even if the driver succeeds on the initial loading, the setup of a MTRR range for the video memory seems missing. If it is there it covers the 32M from the pci config space.

After an initial failure, I was able to rmmod/insmod the cirrus module and that would successfully get the VRAM resource and set up the MTRR to cover the 32M region. There was some corruption to the display but switching to VT0 and back to VT7 fixed those.

It really is the problem of remove_conflicting_framebuffers() returning before the removed fb's driver has released its resources. As it is visible below efifb seems to take quite a while (sometimes?).

[ 0.189597] efifb: probing for efifb
[ 0.189597] efifb: framebuffer region reserved
[ 0.189597] efifb: framebuffer at 0xfc000000, mapped to 0xffffc90000900000, using 1408k, total 1408k
[ 0.189597] efifb: mode is 800x600x24, linelength=2400, pages=1
[ 0.189597] efifb: scrolling: redraw
[ 0.189597] efifb: Truecolor: size=0:8:8:8, shift=0:16:8:0
[ 10.823896] fb: conflicting fb hw usage cirrusdrmfb vs EFI VGA - removing generic driver
[ 10.856476] cirrus: requestion framebuffer region
[ 10.856481] cirrus: failed to get framebuffer region
[ 11.361124] cirrus: failed to get framebuffer region
[ 11.864322] cirrus: failed to get framebuffer region
[ 12.368378] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
[ 12.368391] cirrus 0000:00:02.0: Fatal error during GPU init: -6
[ 13.934174] efifb: frambuffer region released

Not sure this is really meant to be, but it seems the efifb is initialized because grub passes this VGA type to the kernel. When I uncomment the line in /etc/default/grub that sets GRUB_TERMINAL=console, then the efifb driver is not loaded. There is a early error message that video mode could not be set but at least this results in the cirrus driver loading all the time.

The efifb initialization by grub is deliberate, to try to provide flicker-free boot on efi-capable systems.

Question is why is a kvm VM considered an EFI capable system (gfx). This sounded to be only MAC. Of course as a secondary issue we have the unsolved problem of replacing a framebuffer device which is not (rumors speak of "issues") synchronizing the release and re-acquiring of resources.

So asking around, grub (even in Precise) passes mode 0x70 (which happens to be efifb) as a generic framebuffer setup and the usage of efifb is more in a generic way than EFI. For real hw grub uses an internal VBE driver. The reason we never had any issues was that without the cirrus DRM driver efifb was the only framebuffer driver. Now there is one and we run into this race.

With the (admittedly ugly) patch, the init of the cirrusdrmfb does wait for the release of the efifb resources. But it fails on bringing up lightdm. What I think happens is that efifb does not completely go away until plymouth closes the old fb devices. Which it does at some point (in my tests there would be a delay of about 3s), likely when getting IO errors when accessing it. But it does not retry to open the (new) device. Or it does but would need to give a bit more time between retries.

If that would be working there currently would be the next issue that efifb and cirrusdrmfb use different resolutions. Probably not fatal but certainly visible on boot.

@ Stefan is there a PPA where I can test the patch? That would be great, as I am one of the affected people.

@Dmitrijs, I don't have it in a PPA or elsewhere right now because I am not really happy with the current results. Due to the delay between releasing and reacquiring the framebuffer, X rarely gets up and I saw the VTs be stuck, too (had to ssh in and restart lightdm). The best work-around right now seems to be to use GRUB_TERMINAL=console in /etc/defaults/grub. But I can also put the patches kernel packages somewhere and let you decide.

Stefan, can we please just get the cirrus drm driver disabled in the quantal kernel until this is resolved? Currently it adds nothing but bugs.

Steve, that is not correct. Actually the cirrus driver + modeset X driver is the only way not to have X crash as soon as unity starts. Though I must admit that it would at least put the users of KVM and Xen into the same pain.

Dmitrijs, if you want to play around: http://people.canonical.com/~smb/lp1038055/ (you have been warned ;))

Unsigned hand-crafted debs of linux kernel =) /me like!

Testing today (on a Xen guest) showed that the X crash on unity startup seems to be resolved. On the KVM side at least startup works, while I get occasional crashed that look similar to the initial crash (maybe that is a result of a slower machine trying to cope with llvm-pipe). But in the light of that I would also tend to disable the kernel cirrus drm driver (even more as this currently would only do anything for KVM). That way we at least face the same stacks when running Xen and KVM guests.

This bug was fixed in the package linux - 3.5.0-16.24

---------------
linux (3.5.0-16.24) quantal-proposed; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: ata_piix: add a disable_driver option
    - LP: #994870

  [ Christian König ]

  * (pre-stable) drm/radeon: make 64bit fences more robust v3 (3.5 stable)
    - LP: #1029582

  [ David Henningsson ]

  * SAUCE: ALSA: hda - use both input paths on Conexant auto parser
    - LP: #1037642
  * SAUCE: ALSA: hda - fix control names for multiple speaker out on
    IDT/STAC
    - LP: #1046734

  [ Herton Ronaldo Krzesinski ]

  * SAUCE: ALSA: hda/via - don't report presence on HPs with no presence
    support
    - LP: #1052499
  * SAUCE: ext4: fix crash when accessing /proc/mounts concurrently
    - LP: #1053019
  * SAUCE: ALSA: hda/realtek - Fix detection of ALC271X codec
    - LP: #1006690

  [ Kyle Fazzari ]

  * SAUCE: input: Cypress PS/2 Trackpad fix disabling tap-to-click
    - LP: #1048816

  [ Leann Ogasawara ]

  * [Config] Disable CONFIG_DRM_AST
    - LP: #1053290

  [ Stefan Bader ]

  * [Config] Disable the Cirrus QEMU drm driver
    - LP: #1038055

  [ Upstream Kernel Changes ]

  * Revert "KVM: VMX: Fix KVM_SET_SREGS with big real mode segments"
    - LP: #1045027
  * x86, efi: Handover Protocol
  * drm/i915: HDMI - Clear Audio Enable bit for Hot Plug
    - LP: #1056729
  * UBUNTU SAUCE: apparmor: fix IRQ stack overflow
    - LP: #1056078
  * drm/nouveau: fix booting with plymouth + dumb support
    - LP: #1043518
  * ALSA: hda - Add DeviceID for Haswell HDA
    - LP: #1057698
  * ALSA: hda - add Haswell HDMI codec id
    - LP: #1057698
  * ALSA: hda - Fix driver type of Haswell controller to AZX_DRIVER_SCH
    - LP: #1057698
  * ALSA: hda_intel: Add Device IDs for Intel Lynx Point-LP PCH
    - LP: #1011438, #1057698

  [ Wang Xingchao ]

  * SAUCE: ALSA: hda - Add another pci id for Haswell board
    - LP: #1057698

  [ Wen-chien Jesse Sung ]

  * SAUCE: drm/i915: Explicitly disable RC6 for certain models
    - LP: #1002170, #1008867
 -- Leann Ogasawara <email address hidden> Thu, 27 Sep 2012 13:55:52 -0700

This bug is back with 13.04

Tomas: It's probably best to open a new bug for it, however please make sure it includes at least the following:

Can you confirm exactly what your setup is:
   Is this under KVM - if so what host and what video card config
   What image exactly did you use as the install?
   Were you using luks?
   What exactly do you see on the screen?

and a comment saying to see this bug, and add a comment here with that bug number.

Opened a new bug for 13.04 #1177772

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.