Bug 500478 - Seting "nomodeset" hangs system with ATI Mobility FireGL V5200 on Thinkpad T61p
Seting "nomodeset" hangs system with ATI Mobility FireGL V5200 on Thinkpad T61p
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
rawhide
i686 Linux
low Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-12 16:35 EDT by wdc
Modified: 2009-05-16 09:10 EDT (History)
1 user (show)

See Also:
Fixed In Version: xorg-x11-drv-ati 6.12.2-14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-16 09:10:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log with boot args "nomodeset", with X started via "startx" at run level 3 (33.66 KB, text/plain)
2009-05-12 16:35 EDT, wdc
no flags Details
Xorg.0.log of successful startup with default kernel modeset enabled. (54.75 KB, text/plain)
2009-05-12 16:36 EDT, wdc
no flags Details
dmesg output from default boot-up. (45.13 KB, text/plain)
2009-05-12 16:37 EDT, wdc
no flags Details

  None (edit)
Description wdc 2009-05-12 16:35:12 EDT
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
Comment 1 wdc 2009-05-12 16:36:26 EDT
Created attachment 343657 [details]
Xorg.0.log of successful startup with default kernel modeset enabled.
Comment 2 wdc 2009-05-12 16:37:31 EDT
Created attachment 343659 [details]
dmesg output from default boot-up.
Comment 3 wdc 2009-05-12 17:10:10 EDT
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 ~]$
Comment 4 wdc 2009-05-12 17:19:26 EDT
    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.
Comment 5 Matěj Cepl 2009-05-12 18:02:08 EDT
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.
Comment 6 wdc 2009-05-12 18:09:59 EDT
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.
Comment 7 Matěj Cepl 2009-05-13 10:36:07 EDT
(In reply to comment #6)
> Did you close the wrong bug?

Yes, I did. I am sorry.
Comment 8 Adam Jackson 2009-05-15 16:41:49 EDT
Try xorg-x11-drv-ati 6.12.2-14 ?
Comment 9 wdc 2009-05-15 23:32:23 EDT
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.

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