Created attachment 343656 [details] Xorg.0.log with boot args "nomodeset", with X started via "startx" at run level 3 Description of problem: In preparation for submitting another bug, I realized I should retry the failure with "nomodeset". I changed the boot args from "quiet rhgb" to "nomodeset". This hung the system. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.6.1-11.fc11.i586 xorg-x11-server-common-1.6.1-11.fc11.i586 xorg-x11-server-utils-7.4-7.fc11.i586 xorg-x11-drv-ati-6.12.2-13.fc11.i586 Kernel: 2.6.29.2-129.fc11.i686.PAE How reproducible: ALWAYS. 100% Steps to Reproduce: 1. Change boot args from "quiet rhgb" to "nomodeset". 2. Boot. Actual results: Screen goes blank, no response to keyboard. Requires power-cycle to recover Expected results: Working X display. Additional info: I get the same behavior if I start at run level 3, log in and do: startx
Created attachment 343657 [details] Xorg.0.log of successful startup with default kernel modeset enabled.
Created attachment 343659 [details] dmesg output from default boot-up.
I see that it's not strictly true that the system is hung. I brought up the network at run level 3 (and I still don't like how gdm wants to be the thing that brings up my network, but I digress.) So I ssh'd in as a normal user, and logged in from a console VT as root. I issued "startx" from the root console VT and got the hangup AND the following output on my seemingly unrelated ssh connection: [wdc@localhost ~]$ Message from syslogd@localhost at May 12 17:01:38 ... kernel:Oops: 0000 [#1] SMP Message from syslogd@localhost at May 12 17:01:38 ... kernel:last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/enable Message from syslogd@localhost at May 12 17:01:38 ... kernel:Process X (pid: 2271, ti=f2ce8000 task=f34d71a0 task.ti=f2ce8000) Message from syslogd@localhost at May 12 17:01:38 ... kernel:Stack: Message from syslogd@localhost at May 12 17:01:38 ... kernel: f2ce9db4 f80bc86f 00000000 f2ce9d8c c0547826 00000000 00000000 00000000 Message from syslogd@localhost at May 12 17:01:38 ... kernel: 00000004 f283a66c f283a678 f66a9800 f66a9814 f283a600 f668c840 f2d3ed00 Message from syslogd@localhost at May 12 17:01:38 ... kernel:Call Trace: Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f80bb02e>] ? list_add_tail+0x12/0x14 [drm] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f80bb061>] ? drm_bo_add_to_lru+0x31/0x3f [drm] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f80bc86f>] ? drm_bo_do_validate+0x466/0x4c2 [drm] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c0547826>] ? security_transition_sid+0x15/0x17 Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f80bd47f>] ? drm_buffer_object_create+0x2a4/0x2d5 [drm] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f817204b>] ? radeon_gem_object_alloc+0xb0/0xe9 [radeon] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f81720d1>] ? radeon_gem_create_ioctl+0x4d/0xec [radeon] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c0567f71>] ? copy_from_user+0x32/0x119 Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f80ad73f>] ? drm_ioctl+0x202/0x296 [drm] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<f8172084>] ? radeon_gem_create_ioctl+0x0/0xec [radeon] Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c053ac14>] ? inode_has_perm+0x60/0x6a Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c04b2b82>] ? vfs_ioctl+0x5c/0x76 Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c04b3389>] ? do_vfs_ioctl+0x480/0x4ba Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c053afd1>] ? selinux_file_ioctl+0x43/0x46 Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c04b3409>] ? sys_ioctl+0x46/0x66 Message from syslogd@localhost at May 12 17:01:38 ... kernel: [<c040945f>] ? sysenter_do_call+0x12/0x34 Message from syslogd@localhost at May 12 17:01:38 ... kernel:Code: c3 55 89 e5 57 89 cf 56 89 d6 53 89 c3 8b 41 04 39 d0 74 17 51 50 52 68 17 2a 81 c0 6a 1a 68 cc 29 81 c0 e8 cf aa ec ff 83 c4 18 <8b> 06 39 f8 74 17 56 50 57 68 64 2a 81 c0 6a 1e 68 cc 29 81 c0 Message from syslogd@localhost at May 12 17:01:38 ... kernel:EIP: [<c056aeb6>] __list_add+0x2a/0x5c SS:ESP 0068:f2ce9d34 [wdc@localhost ~]$
Although the ssh connection can do stuff, killing X doesn't work. ps ax shows these three processes. 2151 tty1 S+ 0:00 /bin/sh /usr/bin/startx 2167 tty1 S+ 0:00 xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -auth / 2168 tty7 D<s+ 0:00 [X] kill -TERM has no effect. The "D<s+" state of X apparently sez that we're in high priority un-interruptable IO wait. Oh well. So this is effectively a system crashing event. Please let me know what else I can do to help further isolate and repair this problem.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.
Macej, Did you close the wrong bug? I opened this case less than an hour ago, and saw NO request for additional information. I'll gladly provide additional information, if you tell me what you need.
(In reply to comment #6) > Did you close the wrong bug? Yes, I did. I am sorry.
Try xorg-x11-drv-ati 6.12.2-14 ?
Good news! I just installed xorg-x11-drv-ati 6.12.2-14 from koji and nomodeset now works. You can mark this bug as fixed as of that version.