Bug 623956 - VESA driver fails in qemu/kvm machines, system hangs at X init
VESA driver fails in qemu/kvm machines, system hangs at X init
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Triaged
Depends On:
Blocks: F14-accepted/F14FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2010-08-13 05:23 EDT by He Rui
Modified: 2010-10-06 16:06 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-06 15:38:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
var logs after text-mode installation (60.78 KB, application/x-gzip)
2010-09-16 06:23 EDT, He Rui
no flags Details
Xorg.0.log (24.52 KB, text/plain)
2010-09-17 05:43 EDT, He Rui
no flags Details
dmesg.txt (25.88 KB, text/plain)
2010-09-17 05:48 EDT, He Rui
no flags Details
/var/log/messages (136.32 KB, text/plain)
2010-09-17 05:51 EDT, He Rui
no flags Details
Xorg.0.log from Rawhide while the display is in a loop, trying to start (32.82 KB, text/plain)
2010-10-05 15:03 EDT, Andre Robatino
no flags Details

  None (edit)
Description He Rui 2010-08-13 05:23:50 EDT
Description of problem:
Boot F14-alpha-rc4 in kvm with boot parameter: xdriver=vesa, then graphical anaconda(stage2) failed to display and the screen fell to black without anything. It's also unable to turn to other VTs to debug. 

But xdriver=vesa worked normally on my bare metal(ATI Technologies Inc RV620 LE [Radeon HD 3450]). 

Version-Release number of selected component (if applicable):
F14-Alpha-RC4
anaconda 14.15

How reproducible:
100%

Steps to Reproduce:
1. Boot images
2. choose 'install with basic video'
  
Actual results:
It could be display failure or hanged system. The screen turned to black and no inputs worked.
Comment 1 He Rui 2010-08-13 05:47:19 EDT
Version is: xorg-x11-drv-vesa-2.3.0-1.fc14
Comment 2 James Laska 2010-09-15 08:28:26 EDT
Hurry, can you post some additional logs when attempting xdriver=vesa in a KVM guest?  I believe mcepl will need /tmp/syslog and /tmp/X.log.  Attaching /tmp/anaconda.log couldn't hurt either.

If you are not able to grab those logs, an alternative is to install the system with text-mode (or VNC), and post /var/log/{dmesg,messages,Xorg*} from the installed system.  Thanks!
Comment 3 He Rui 2010-09-16 06:23:46 EDT
Created attachment 447709 [details]
var logs after text-mode installation

Thanks, James. I can't turn to other ttys to get logs coz all of them are black. So I installed in text-mode and attached /var/logs/ of installed system. Hope it's helpful.


Another concern is: should we mark it as F14blocker? It's not a serious problem, but it's a big option provided in grub entries, some ones will attempt it in kvm and it should work.
Comment 4 James Laska 2010-09-16 10:11:45 EDT
I'm not aware of any criteria we can explicitly cite ... but I've seen discussion in other similar xdriver=vesa bugs and I think this certainly would warrant further discussion.

mcepl: Let us know if there are any additional logs or system specifications you'd like to see in this report.
Comment 5 Matěj Cepl 2010-09-16 17:09:17 EDT
(In reply to comment #3)
> Thanks, James. I can't turn to other ttys to get logs coz all of them are
> black. So I installed in text-mode and attached /var/logs/ of installed system.
> Hope it's helpful.

Apparently, you have really done just that ... there are no traits of an attempt to run Xorg on this computer. Could you please remove (or rename) /etc/X11/xorg.conf to something else, and log as a normal user (not root) and run command 

startx

Whether it fail or not (of course, let us know the result of the attempt) it should generate logs we are after:

* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* fresh system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 6 He Rui 2010-09-17 05:42:00 EDT
(In reply to comment #5)
> (In reply to comment #3)
> > Thanks, James. I can't turn to other ttys to get logs coz all of them are
> > black. So I installed in text-mode and attached /var/logs/ of installed system.
> > Hope it's helpful.
> 
> Apparently, you have really done just that ... there are no traits of an
> attempt to run Xorg on this computer. Could you please remove (or rename)
> /etc/X11/xorg.conf to something else, and log as a normal user (not root) and
> run command 
> 
> startx
> Whether it fail or not (of course, let us know the result of the attempt)


I installed in test-mode, so the group 'x window system' was not installed by default. After groupinstalled it, I could startx as a normal user.

> it should generate logs we are after:
> 
> * X server log file (/var/log/Xorg.*.log)
> * output of the dmesg command, and
> * fresh system log (/var/log/messages)
> 
> to the bug report as individual uncompressed file attachments using the
> bugzilla file attachment link above.

Please see attached.
Comment 7 He Rui 2010-09-17 05:43:00 EDT
Created attachment 447959 [details]
Xorg.0.log
Comment 8 He Rui 2010-09-17 05:48:08 EDT
Created attachment 447963 [details]
dmesg.txt
Comment 9 He Rui 2010-09-17 05:51:12 EDT
Created attachment 447965 [details]
/var/log/messages
Comment 10 Matěj Cepl 2010-09-17 10:14:35 EDT
I see

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/1:
 #0:  (net_mutex){+.+.+.}, at: [<ffffffff813e8130>] register_pernet_subsys+0x1f/0x47

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-12.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff813df5d9>] sock_update_classid+0x7c/0xa2
 [<ffffffff813df66a>] sk_alloc+0x6b/0x77
 [<ffffffff8140a3b9>] __netlink_create+0x37/0xab
 [<ffffffff813f853c>] ? rtnetlink_rcv+0x0/0x2d
 [<ffffffff8140c019>] netlink_kernel_create+0x74/0x19d
 [<ffffffff8149b4ba>] ? __mutex_lock_common+0x339/0x35b
 [<ffffffff813f6fbc>] rtnetlink_net_init+0x2e/0x48
 [<ffffffff813e7e9a>] ops_init+0xe9/0xff
 [<ffffffff813e802d>] register_pernet_operations+0xab/0x130
 [<ffffffff813e813f>] register_pernet_subsys+0x2e/0x47
 [<ffffffff81db7b95>] rtnetlink_init+0x53/0x102
 [<ffffffff81db8327>] netlink_proto_init+0x126/0x143
 [<ffffffff81db8201>] ? netlink_proto_init+0x0/0x143
 [<ffffffff810021b8>] do_one_initcall+0x72/0x186
 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8149d390>] ? restore_args+0x0/0x30
 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10

but that's quite certainly not Xorg-related.
Comment 11 Matěj Cepl 2010-09-17 10:17:18 EDT
(In reply to comment #6)
> I installed in test-mode, so the group 'x window system' was not installed by
> default. After groupinstalled it, I could startx as a normal user.

So, what problems remain relevant for you now? And BTW, were you able to install WITHOUT xdriver=vesa just with automatically selected driver (xorg-x11-drv-cirrus in this case, because it is apparently kvm machine)?

Thank you for reporting the bug
Comment 12 Andre Robatino 2010-09-17 10:37:11 EDT
I had no trouble doing a F14 Beta TC1 KVM install using default graphical mode in either 32- or 64-bit. But basic video mode fails in both. I don't think I checked it earlier so it may not be a new issue.
Comment 13 Andre Robatino 2010-09-18 05:20:24 EDT
Still fails in Beta RC1 in both i386 and x86_64.
Comment 14 Andre Robatino 2010-09-21 09:58:33 EDT
Still fails in Beta RC3 in both i386 and x86_64.
Comment 15 Adam Williamson 2010-09-22 04:43:17 EDT
vesa is known not to work in KVM. We've had a bug about it open for years - 533879. Not sure if this is actually the same fail, but the basic bug has been around a long time, the vesa driver just doesn't work with KVM's 'graphics card'.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 Matěj Cepl 2010-09-22 06:30:20 EDT
(In reply to comment #15)
> vesa is known not to work in KVM. We've had a bug about it open for years -
> 533879. Not sure if this is actually the same fail, but the basic bug has been
> around a long time, the vesa driver just doesn't work with KVM's 'graphics
> card'.

So, Adam, why this isn't a duplicate of the bug 533879? And BTW, why this isn't a qemu/kvm bug (apparently they are not doing their virtual cirrus card enough compatible with VESA)?
Comment 17 Adam Williamson 2010-09-22 07:12:21 EDT
"So, Adam, why this isn't a duplicate of the bug 533879?"

It may be, but I don't know if it's actually the _same_ crash. They may be different, that bug's from F12, quite a lot has changed since then. If you check the traces and conclude that it's the same crash, please mark as a dupe.

"And BTW, why this isn't
a qemu/kvm bug (apparently they are not doing their virtual cirrus card enough
compatible with VESA)?"

Ajax generally works off the principle that -vesa should work with just about anything capable of rendering pixels to a monitor, so even if technically the problem is that the card implementation is broken, he'd want to fix vesa to work with it. AIUI.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 He Rui 2010-09-26 01:13:41 EDT
(In reply to comment #11)
> (In reply to comment #6)
> > I installed in test-mode, so the group 'x window system' was not installed by
> > default. After groupinstalled it, I could startx as a normal user.
> 
> So, what problems remain relevant for you now? And BTW, were you able to
> install WITHOUT xdriver=vesa just with automatically selected driver
> (xorg-x11-drv-cirrus in this case, because it is apparently kvm machine)?
> 
> Thank you for reporting the bug

Sorry for the late reply. I meant after groupinstalled 'x window system' and  removed (or renamed) /etc/X11/xorg.conf to something else as you suggested, I could startx, or I couldn't start with vesa driver. 

I am able to install without xdriver=vesa in kvm. And I can also install F12 and F13 with basic video driver in the same kvm. Thanks.
Comment 19 Adam Williamson 2010-09-28 11:27:04 EDT
I'm not sure it's worth having this in Common Bugs. There's no actual use case for running vesa in KVM besides testing it, AFAIK.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 20 He Rui 2010-09-28 22:33:45 EDT
(In reply to comment #19)
> I'm not sure it's worth having this in Common Bugs. There's no actual use case
> for running vesa in KVM besides testing it, AFAIK.
> 

That's right, but someone may just try the 'install with basic video driver' option in kvm. I sometimes saw a few people talking about this on IRC.
Comment 21 Adam Williamson 2010-10-01 16:38:44 EDT
This was discussed at the 2010-10-01 blocker review meeting. We agreed it doesn't meet the criteria to be a blocker as there's no practical reason to use vesa in a kvm, the native support for the 'cirrus' video adapter in the qemu/KVM machines works fine. However, we accept it as an nth, if the fix is not too messy.
Comment 22 Eric Hopper 2010-10-03 10:04:00 EDT
I cannot install Fedora 14 in VirtualBox because of this bug.  The text mode install doesn't give me the partitioning options I need and the graphical install hangs on a blank screen regardless of whether I use VESA mode or not.
Comment 23 Andre Robatino 2010-10-03 10:14:16 EDT
Eric: the problem with VirtualBox is bug 621893, not this one.
Comment 24 Frank Mehnert 2010-10-04 02:57:30 EDT
I think Fedora 14 on KVM/Qemu is affected by the same problem as described in bug 621893 -- KVM/qemu supports only VESA 2.0 (like VirtualBox).
Comment 25 Andre Robatino 2010-10-05 07:00:15 EDT
Tested both the latest Rawhide and F14 builds for xorg-x11-server which were supposed to fix this bug, but they don't work. See the last comments in bug 621893. Please push properly fixed versions ASAP so this can get into Final TC1. Thanks.
Comment 26 Andre Robatino 2010-10-05 14:45:51 EDT
The latest F14 Koji build

http://koji.fedoraproject.org/koji/buildinfo?buildID=199046

seems to fix the problem. However, the corresponding Rawhide build

http://koji.fedoraproject.org/koji/buildinfo?buildID=199045

doesn't seem to work properly. It looks like the display is trying to come up, but it's in a loop repeating every few seconds. At least it's not dead with a black screen like before.
Comment 27 Andre Robatino 2010-10-05 15:03:27 EDT
Created attachment 451747 [details]
Xorg.0.log from Rawhide while the display is in a loop, trying to start

The xorg.conf file used with this is just 4 lines:

Section "Device"
  Identifier "Videocard0"
  Driver "vesa"
EndSection

I tried using "Xorg -configure" and "system-config-display --noui" to generate an xorg.conf automatically, but neither method worked.
Comment 28 Andre Robatino 2010-10-06 11:04:32 EDT
The above attachment contains a backtrace and a segfault. If no one has any ideas why the same xorg.conf that works in my F14 KVM guest doesn't work in Rawhide KVM, I'll be deleting the guest in a few days to recover the space, as my Rawhide VirtualBox guest is working fine now.
Comment 29 Adam Jackson 2010-10-06 15:38:57 EDT
xorg-x11-server-Xorg-1.9.0-13.fc14.x86_64 works for me in local testing.  Closing.
Comment 30 Andre Robatino 2010-10-06 16:06:38 EDT
Adam: have you tested it in Rawhide (since you closed it as "CLOSED RAWHIDE", and I'm still not 100% sure it's fixed in Rawhide)?

Note You need to log in before you can comment on or make changes to this bug.