Description of problem: Enable KMS leads to totally frozen of the X-window, but the machine (HP Compaq nx6125) can still accessable via SSH. # cat /proc/cmdline ro root=UUID=63f5071e-45a2-41b4-aec1-7578b59cb52d rhgb quiet LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=uk rd_plytheme=charge # dmesg ... [TTM] Failed moving buffer. Proposed placement 0x00060004 [TTM] Out of aperture space or DRM memory quota. [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate. [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation ! # lspci -xxxvvv ... 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company MX6125 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B+ DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (2000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at c0000000 (32-bit, prefetchable) [size=64M] Region 1: I/O ports at 2000 [size=256] Region 2: Memory at c4400000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at c4420000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: radeon Kernel modules: radeon, radeonfb 00: 02 10 55 59 07 02 b0 02 00 00 00 03 10 40 00 00 10: 08 00 00 c0 01 20 00 00 00 00 40 c4 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 8b 30 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 08 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 8b 30 50: 01 00 02 06 00 00 00 00 02 50 20 00 30 02 00 4f 60: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Version-Release number of selected component (if applicable): kernel-2.6.31-0.190.rc8.fc12.x86_64 How reproducible: always Steps to Reproduce: 1. boot the kernel with KMS enabled. 2. start firefox to open a few websites. Actual results: X Window frozen. There is no response from either keyboard or touchpad. Expected results: Working fine. Additional info: Full /var/log/messages can be found at the external bugzilla.
xorg-x11-drv-ati-6.13.0-0.2.20090821gitb1b77a4d6.fc12.x86_64
Created attachment 360223 [details] Xorg.0.log -- drm.debug=1 with KMS
Created attachment 360224 [details] dmesg -- drm.debug=1 with KMS
Created attachment 360230 [details] Smolt Profile
Created attachment 360231 [details] Xorg.0.log -- nomodeset
Created attachment 360233 [details] dmesg -- nomodeset
Propose for F12 blocker, since this bug along with bug 522129 seem going to make Radeon XPRESS 200M based systems unusable in F12.
Did you tested KMS again after an update ? The 32GTT limitation shouldn't exist anymore and this should allow your configuration to work properly.
The problem seems still there using the latest rawhide from the F12 Beta installation testing. Also, the modesetting is incorrect here. 1) boot screen is restricted at the top left corner only occupied 1/4 of the screen. 2) firstboot screen stretch out of the screen. Although the GDM screen restores to its original mode, but then there is a black screen, and VT switch has no effect. I think the kernel is dead, since it does not response to keyboard/mouse/ping.
Try booting in init 3 and attach new dmesg please.
Created attachment 363483 [details] dmesg -- drm.debug=1 with KMS
Created attachment 363551 [details] messages - drm.debug=1 with KMS on drm-testing kernel Tried the latest drm-testing tree, and seems the problem goes away.
However, even with the latest drm-testing tree, there still have the problem of incorrect modesetting outlined in the comment #9 occasionally. 1) boot screen is restricted at the top left corner only occupied 1/4 of the screen.
Created attachment 363783 [details] corrupted background In addition, there is then a corrupted background image view after login.
Created attachment 363784 [details] Boot screen only occupied 1/4 of the screen. Seen on both fedora and drm-testing kernels.
Created attachment 363785 [details] Firstboot box went beyond the screen.
Seems the original issue is fixed. CAI can you file a new bug with the new issue you are seeing (if you're still seeing it?)
Jesse, the problem has not been resolved in F12. Even if using the latest upstream drm-testing kernel, there seems better, but still seems some other issues and occasionally system deadlock during the start of the X window.
Discussed at today's blocker bug review. We agree that this should be a blocker, it's a commonly-found chipset. Dave, Jerome, can you investigate the potential fix from the drm-next tree? Cai, is there any chance you can isolate the fix more specifically? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
CAI can you test if kernel at : http://koji.fedoraproject.org/koji/buildinfo?buildID=138011 Fixes it the issue the same drm-test does ? So to sumup with drm-next what is not working ? (we know suspend/resume fails on this chipset) ? Also i am not sure the first ncurse screen is our bug, maybe ncurse doesn't use the full resolution as kernel dmesg show a fb which should be fullscreen (and graphical installation process use the full screen properly).
Tested again use the above packages. * the system is running well so far with KMS. * still have the screen out-of-sync problem mentioned in comment #15. * no virtual consoles any more with KMS -- bug 530692 (proposed as a blocker)
(In reply to comment #21) > * no virtual consoles any more with KMS -- bug 530692 (proposed as a blocker) This has been removed from the blocker list, since it was using the VESA driver from the installation with the basic video driver. However, the VT switch seems still have problem that it needs to relogin every time after VT switch.
kernel 96 has been tagged into F12 final, so can we close this one now? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Can you use the BZ to track the annoying problem mentioned in comment #22 -- the VT switch seems still have problem that it needs to relogin every time after VT switch? or you would like a new BZ? I'll open a new BZ for the problem mentioned in comment #15.
I think it's better to open a separate bug for VT switch issue. Just to make sure i understand it properly. You boot with KMS and with no vga= cmd appended to your kernel boot parameter ? Then when you are on X if you switch away to some console, when you switch back to X you did loose your session and you back to gdm ? Does process of your previous session still runs ?
(In reply to comment #25) > I think it's better to open a separate bug for VT switch issue. Just to make > sure i understand it properly. You boot with KMS and with no vga= cmd appended > to your kernel boot parameter ? Yes. > Then when you are on X if you switch away to > some console, when you switch back to X you did loose your session and you back > to gdm ? Yes. > Does process of your previous session still runs ? No.
BZ 531383 has been created for it. This bug can be closed.
Thanks a lot. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers