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.
Version is: xorg-x11-drv-vesa-2.3.0-1.fc14
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!
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.
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.
(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.
(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.
Created attachment 447959 [details] Xorg.0.log
Created attachment 447963 [details] dmesg.txt
Created attachment 447965 [details] /var/log/messages
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.
(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
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.
Still fails in Beta RC1 in both i386 and x86_64.
Still fails in Beta RC3 in both i386 and x86_64.
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
(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)?
"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
(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.
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
(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.
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.
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.
Eric: the problem with VirtualBox is bug 621893, not this one.
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).
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.
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.
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.
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.
xorg-x11-server-Xorg-1.9.0-13.fc14.x86_64 works for me in local testing. Closing.
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)?