FS#39715 - [linux] Kernel 3.14-1 problem on boot up process using kvm

Attached to Project: Arch Linux
Opened by crashbit (crashbit) - Wednesday, 02 April 2014, 00:37 GMT
Last edited by Thomas Bächler (brain0) - Wednesday, 02 April 2014, 20:28 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: When upgrade my system to linux 3.14-1 from testing, I can't access to tty



Additional info: I use archlinux under kvm, I used virt-manager to create the archlinux machine. The video card of the system virtualized is a cirrus with 9MB.


Steps to reproduce:
1) Start virtual machine from virt-manager and freezes at boot.
I don't know if complete freeze or don't show any result to screen.
2) Sending a reboot signal with virt-manager.
The machine has reboot.
3) Downgrading to old kernel 3.13.8-1-ARCH
All works fine.

I attach a log extracted with journalctl from the process of boot up

   kern.log (43.4 KiB)
This task depends upon

Closed by  Thomas Bächler (brain0)
Wednesday, 02 April 2014, 20:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 3.14-2
Comment by Doug Newgard (Scimmia) - Wednesday, 02 April 2014, 03:40 GMT
Sounds like the known bug mentioned at the end of this post: https://mailman.archlinux.org/pipermail/arch-dev-public/2014-April/026102.html?
Comment by Thomas Bächler (brain0) - Wednesday, 02 April 2014, 06:31 GMT
Try the option cirrus.modeset=0 on the kernel command line (or options cirrus modeset.0 in /etc/modprobe.d/disable-modeset.conf). If it is the same problem, everything is fine, except the KMS driver crashes the console.
Comment by crashbit (crashbit) - Wednesday, 02 April 2014, 12:15 GMT
Perfect, adding cirrus.modeset=0 to kernel command line works good.
Thx
Comment by Thomas Bächler (brain0) - Wednesday, 02 April 2014, 12:29 GMT
Can you find out the options that libvirt uses to start the qemu instance? I cannot reproduce this problem with qemu's default BIOS.

Also attach the output of dmesg from a failed boot (it should actually still be in the VM's journal, in case you don't want to break the VM again), I need to compare your error message with mine.
Comment by crashbit (crashbit) - Wednesday, 02 April 2014, 12:45 GMT
-------------
abr 02 01:43:47 venus kernel: fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver
abr 02 01:43:47 venus kernel: Console: switching to colour dummy device 80x25
abr 02 01:43:47 venus kernel: [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
abr 02 01:43:47 venus kernel: cirrus 0000:00:02.0: Fatal error during GPU init: -6
abr 02 01:43:47 venus kernel: Trying to free nonexistent resource <00000000febf1000-00000000febf1fff>
abr 02 01:43:47 venus kernel: Trying to free nonexistent resource <00000000fc000000-00000000fc3fffff>
abr 02 01:43:47 venus systemd[1]: Mounted /home.
--------------

I don't know if this is you want, in kern.log file attach before you can see all dmesg of failed boot.

I attach a venus.xml file:
   venus.xml (3.6 KiB)
Comment by Thomas Bächler (brain0) - Wednesday, 02 April 2014, 12:58 GMT
Okay, this seems to be the same error that I got, but I'll have to look it up.

I won't consider this bug a blocker for moving 3.14 to core, since it "only" affects the qemu cirrus driver. This bug might either be caused by enabling to simplefb or by a change in the cirrus driver. Need to find that out, too.
Comment by Thomas Bächler (brain0) - Wednesday, 02 April 2014, 18:00 GMT
Okay, it's in fact the same here.

[ 1.618421] fb: conflicting fb hw usage cirrusdrmfb vs simple - removing generic driver
[ 1.618432] Console: switching to colour dummy device 80x25
[ 1.618706] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM
[ 1.618712] cirrus 0000:00:02.0: Fatal error during GPU init: -6

From a bit of research, it seems that we'll have to disable CONFIG_SYSFB and CONFIG_SIMPLEFB for the moment. This problem is known and I should have caught it in time.

Loading...