Created attachment 369249 [details] dmesg with debugging on Description of problem: A few seconds after the kernel boots (at kms init), the screen goes blank and nothing ever displays. The laptop is still on and responds to keypresses (ctrl-alt-del, etc) and I can ssh in. Version-Release number of selected component (if applicable): kernel-2.6.31.5-122.fc12.i686 mesa-libGL-7.6-0.13.fc12.i686 libdrm-2.4.15-4.fc12.i686 xorg-x11-server-Xorg-1.7.1-7.fc12.i686 mesa-dri-drivers-7.6-0.13.fc12.i686 xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.i686 mesa-libGLU-7.6-0.13.fc12.i686 How reproducible: install f12 rc, boot Actual results: blank screen (power is still on, dpms kicks in after a few minutes and panel then goes dark/off) Expected results: gdm login screen or a vt depending on runlevel
Created attachment 369250 [details] nomodeset, avivorool regmatch *
Created attachment 369251 [details] nomodeset, radeontool regmatch *
Created attachment 369252 [details] kms, avivotool regmatch *
Created attachment 369253 [details] kms, radeontool regmatch *
Created attachment 369254 [details] xorg log a few runs ago I let it go to runlevel 5 (the above *tool regmatch files should all be from runlevel 3)
this looks similar to bug 522362
try boot from kernel-2.6.31.5-91.rc1.fc12 (http://koji.fedoraproject.org/koji/buildinfo?buildID=137800), does it ok? I found 91.rc1 is the last stable kernel for my 200m, 2.6.31.5-96 is the first buggy kernel. bug #532308
Created attachment 369472 [details] kms, radeontool regmatch * Woohooo! I got it working, kind of! I have also been debugging suspend/resume via ssh on this laptop - it has never worked, but the advent of KMS made me want to try to get it working again. After trying lots random things, adding "acpi_sleep=s3_bios" to the kernel command line and then doing a suspend/resume cycle brought the display up. Attached is the radeontool regmatch * output... if you need anything else, let me know - I want to see the display the first time and not have to suspend/resume every boot ;)
Hm, unfortunately it's not very reproducible. The acpi_sleep may or may not have been the thing that fixed it, and I seem to have had more luck bringing it back from a .debug kernel.
Created attachment 369630 [details] image: weird black/white gradient Today my computer did something a little different from a cold boot going to runlevel 5 - attached is a "screen shot"
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 369789 [details] kms, radeontool regmatch * <agd5f> roysjosh: does glisse's rmx patch help? https://bugzilla.redhat.com/attachment.cgi?id=369204 I compiled a kernel with the following patches from drm-radeon-testing: 4170a6c1 drm/radeon/kms/atom/dce3: fix up usPixelClock calculation for Transmitter tables 5a9dbb7e drm/radeon/kms: fix typo in legacy internal tmds mode fixup 3c55c4aa drm/radeon/kms: rework scaler handling but nothing changed. Attached is the `radeontool regmatch *' under this kernel.
Created attachment 369798 [details] kms, radeontool regmatch * I got bored and ./radeontool regset'd a few things and the screen came became visible. I'll do more testing when I get home to pinpoint the exact registers. Here's the current regmatch \*. I'm still under the above-mentioned kernel.
Created attachment 369805 [details] kms (working), radeontool regmatch * I can change 2 registers and it works: OVR_WID_LEFT_RIGHT (0234) 0x00000000 (0) OVR_WID_TOP_BOTTOM (0238) 0x00000000 (0) I set both of those to 0, from other random larger values, and the screen appeared. Here's the full diff from when I started poking registers to when it worked: 47,48c47,48 < CLOCK_CNTL_DATA (000c) 0x000000c3 (195) < CLOCK_CNTL_INDEX (0008) 0x00000388 (904) --- > CLOCK_CNTL_DATA (000c) 0x0000f8c0 (63680) > CLOCK_CNTL_INDEX (0008) 0x000003ad (941) 70c70 < CRTC_CRNT_FRAME (0214) 0x000071a9 (29097) --- > CRTC_CRNT_FRAME (0214) 0x0000d636 (54838) 87c87 < CRTC_STATUS (005c) 0x00000006 (6) --- > CRTC_STATUS (005c) 0x0000000a (10) 92c92 < CRTC_VLINE_CRNT_VLINE (0210) 0x011403ff (18088959) --- > CRTC_VLINE_CRNT_VLINE (0210) 0x002303ff (2294783) 96c96 < CRTC2_STATUS (03fc) 0x00000009 (9) --- > CRTC2_STATUS (03fc) 0x0000000b (11) 197c197 < GEN_INT_STATUS (0044) 0x00080000 (524288) --- > GEN_INT_STATUS (0044) 0x00080005 (524293) 251c251 < MC_STATUS (0150) 0x0009000b (589835) --- > MC_STATUS (0150) 0x0009001f (589855) 277,278c277,278 < OVR_WID_LEFT_RIGHT (0234) 0x00180018 (1572888) < OVR_WID_TOP_BOTTOM (0238) 0x00b800b8 (12058808) --- > OVR_WID_LEFT_RIGHT (0234) 0x00000000 (0) > OVR_WID_TOP_BOTTOM (0238) 0x00000000 (0) Here's all the registers I poked: [root@jericho ~]# cd radeontool/ [root@jericho radeontool]# ./radeontool regset CRTC_H_SYNC_STRT_WID 0x00910410 OLD: CRTC_H_SYNC_STRT_WID (0204) 0x00110408 (1115144) NEW: CRTC_H_SYNC_STRT_WID (0204) 0x00910410 (9503760) [root@jericho radeontool]# ./radeontool regset CRTC_H_SYNC_STRT_WID 0x00110408 OLD: CRTC_H_SYNC_STRT_WID (0204) 0x00910410 (9503760) NEW: CRTC_H_SYNC_STRT_WID (0204) 0x00110408 (1115144) [root@jericho radeontool]# ./radeontool regset SURFACE_CNTL 0x00000100 OLD: SURFACE_CNTL (0b00) 0x00000000 (0) NEW: SURFACE_CNTL (0b00) 0x00000100 (256) [root@jericho radeontool]# ./radeontool regset SURFACE_CNTL 0x00000000 OLD: SURFACE_CNTL (0b00) 0x00000100 (256) NEW: SURFACE_CNTL (0b00) 0x00000000 (0) [root@jericho radeontool]# ./radeontool regset OVR_WID_LEFT_RIGHT 0 OLD: OVR_WID_LEFT_RIGHT (0234) 0x00180018 (1572888) NEW: OVR_WID_LEFT_RIGHT (0234) 0x00000000 (0) [root@jericho radeontool]# ./radeontool regset OVR_WID_TOP_BOTTOM 0 OLD: OVR_WID_TOP_BOTTOM (0238) 0x00b800b8 (12058808) NEW: OVR_WID_TOP_BOTTOM (0238) 0x00000000 (0)
Created attachment 375056 [details] patch to set overscan regs to 0 This is probably not the right place to put this piece of code, but it works for me. I looked in xf86-video-ati/src/legacy_crtc.c in legacy_crtc_mode_set and noticed that it calls RADEONInitCommonRegisters (which sets the ovr_wid_... variables to 0) and then RADEONRestoreCommonRegisters (which does OUTREG on the OVR_WID_... regs from the ovr_wid_... variables). So this is a code regression from UMS to KMS. The thing I am wondering is why are those regs getting set to those values? Is something poking them that shouldn't be? Anyway, I hope this helps.
A quick search through the kernel code shows similar pieces all over: linux-2.6$ grep -r OVR_WID_LEFT_RIGHT . e.g. drivers/video/aty/radeon_base.c: /* these common regs are cleared before mode setting so they do not * interfere with anything */ static reg_val common_regs[] = { { OVR_CLR, 0 }, { OVR_WID_LEFT_RIGHT, 0 }, { OVR_WID_TOP_BOTTOM, 0 }, { OV0_SCALE_CNTL, 0 }, { SUBPIC_CNTL, 0 }, { VIPH_CONTROL, 0 }, { I2C_CNTL_1, 0 }, { GEN_INT_CNTL, 0 }, { CAP0_TRIG_CNTL, 0 }, { CAP1_TRIG_CNTL, 0 }, };
Fixed: http://marc.info/?l=dri-devel&m=125994270301875&w=4 Thanks!