|
Description
eruditehermit
2009-08-03 03:29:38 UTC
Created attachment 28288 [details]
/var/log/debug
Created attachment 28289 [details]
/var/log/messages
This is the output of radeontool regs: RADEON_DAC_CNTL ff008002 RADEON_DAC_EXT_CNTL 00000000 RADEON_DAC_MACRO_CNTL 00070705 RADEON_DAC_CNTL2 00000000 RADEON_TV_DAC_CNTL 07770142 RADEON_DISP_OUTPUT_CNTL 1000000a RADEON_CONFIG_MEMSIZE 08000000 RADEON_AUX_SC_CNTL 00000000 RADEON_CRTC_EXT_CNTL 00000041 RADEON_CRTC_GEN_CNTL 03200600 RADEON_CRTC2_GEN_CNTL 36800000 RADEON_DEVICE_ID 00004e50 RADEON_DISP_MISC_CNTL 5b300600 RADEON_GPIO_MONID 00000300 RADEON_GPIO_MONIDB 00000000 RADEON_GPIO_CRT2_DDC 00000000 RADEON_GPIO_DVI_DDC 00000300 RADEON_GPIO_VGA_DDC 00000300 RADEON_LVDS_GEN_CNTL 003cffa5 RADEON_LVDS_PLL_CNTL 00091282 RADEON_FP_GEN_CNTL 01430000 RADEON_FP2_GEN_CNTL 1000000a RADEON_PIXCLKS_CNTL 3310f8c0 RADEON_MEM_TIMING_CNTL 1a251a12 Can you use the git version of radeontool: http://cgit.freedesktop.org/~airlied/radeontool before suspending, run: radeontool regmatch '*' > working.regs then after resume, run: radeontool regmatch '*' > broken.regs and attach the reg dumps to this bug. Created attachment 28325 [details] [review] working.regs (register dump before suspend) Here is the register dump before suspend from radeontool as requested in comment #4 Created attachment 28326 [details] [review] broken.regs (register dump after resume) This is the radeontool dump after resume from suspend. I had to ssh into the machine to get this dump as the screen is black. This is in response to comment #4. Of the registers dumped, these look like possible candidates: --- working.regs 2009-08-03 22:18:01.000000000 -0400 +++ broken.regs 2009-08-03 22:18:15.000000000 -0400 -CONFIG_CNTL (00e0) 0x000c0100 (786688) +CONFIG_CNTL (00e0) 0x000c0000 (786432) -FP_GEN_CNTL (0284) 0x01430000 (21168128) +FP_GEN_CNTL (0284) 0x00004008 (16392) -CLK_PIN_CNTL (CL: 0001) 0x0a098015 (168394773) +CLK_PIN_CNTL (CL: 0001) 0x00018015 (98325) -SS_INT_CNTL (CL: 0033) 0x00200271 (2097777) +SS_INT_CNTL (CL: 0033) 0x00200000 (2097152) -LVDS_PLL_CNTL (02d4) 0x00091282 (594562) +LVDS_PLL_CNTL (02d4) 0x0009128c (594572) You can try setting the working value of the reg with radeontool, e.g.: radeontool regset LVDS_PLL_CNTL 0x00091282 And see if changing any of them help. I tried setting all of the registers and none were able to restore the screen.(In reply to comment #7) Airlied and glisse suggested connecting an external monitor and then performing suspend and resume. Upon resume, the external LCD does turn on, but the output is corrupted as shown in the attachment labeled resume_corruption. Created attachment 29408 [details]
resume_corruption picture
Similar symptoms to bug #23290 and bug #23273 Created attachment 31055 [details]
dmesg upon resume
This is the dmesg output when performing a resume from suspend. This was requested by airlied on IRC.
Created attachment 31056 [details]
output from vbetool post 2>m10.regs
Here is the m10.regs file from the command vbetool post 2>m10.regs as requested by airlied on IRC.
http://people.freedesktop.org/~airlied/scratch/0001-drm-radeon-kms-add-legacy-LVDS-spread-spectrum-suppo.patch cane you try that patch on top of a newish drm-next kernel Let me know if you stop booting, if resume still fails can you dump the broken.regs file again and attach. Created attachment 31125 [details]
working regs after airlied 0001 patch
This is the dump from radeontool of the working regs before I suspend using a kernel with kms enabled patched with airlied 0001-drm-radeon-kms-add-legacy-LVDS-spread-spectrum-suppo.patch
Created attachment 31126 [details]
registers after resume from suspend.
This is the radeontool dump after resuming from suspend on a kernel with kms enabled and airlied's 0001-drm-radeon-kms-add-legacy-LVDS-spread-spectrum-suppo.patch. With this kernel and kms the screen has corruption even before suspend, on the left side. It is fuzzy and there is some doubling of pixels that shifts the right edge of the display off the right edge of the physical screen.
http://people.freedesktop.org/~airlied/scratch/combios_readback.diff please try this. I followed this bug issue since some days, cause on my system thinkpad T30 Ati Radeon Mobility M7 7500 20091112\2.6.31-rc9_drm-next --- regs.before 2009-11-12 16:51:53.000000000 +0100 +++ regs.after 2009-11-12 18:24:12.000000000 +0100 @@ -4,8 +4,8 @@ RADEON_DISP_OUTPUT_CNTL=10000002 RADEON_CONFIG_MEMSIZE=01000000 RADEON_AUX_SC_CNTL=00000000 -RADEON_CRTC_EXT_CNTL=0d000040 -RADEON_CRTC_GEN_CNTL=03200600 +RADEON_CRTC_EXT_CNTL=0b000040 +RADEON_CRTC_GEN_CNTL=03000600 RADEON_CRTC2_GEN_CNTL=36800000 RADEON_DEVICE_ID=00004c57 RADEON_DISP_MISC_CNTL=5b300600 attaching dmesg before and the working + the broken regs Created attachment 31147 [details]
dmesg before
Created attachment 31148 [details]
broken.regs.txt
Created attachment 31149 [details]
working.regs.txt
Created attachment 31150 [details]
dmesg after resume
I will produce another dmesg with more information, these dmesgs are truncated cause (near oos)
Created attachment 31166 [details]
working.regs
update from today.
Created attachment 31167 [details]
broken.regs after resume
* resume works, but using X not possible, I see a square mouse pointer flickering as everytime trying to resume. I can see my desktop as before resume. but no input is possible, so going into the console and shutting down gdm/xorg
restarting Xorg/gdm does not help
After reboot everytghing is fine.
Created attachment 31168 [details]
kern.log
this kern.log contains the boot before suspend to disk and the resume.
have to stop X, cause of many
[drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(6).
[drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
(In reply to comment #17) > http://people.freedesktop.org/~airlied/scratch/combios_readback.diff > > please try this. > I tried this patch with a kernel built from drm-next. It did not work. It exhibits the same behavior as that described earlier in the bug (i.e. the backlight for the display doesn't turn on after resume). Please advise about what to try next. http://people.freedesktop.org/~airlied/scratch/combios-readback.patch another revision of this patch to test. Also get the latest radeontool and redump the before/after regs, I added some more regs (use regmatch '*') Created attachment 31360 [details] broken.regs after resume from suspend running kernel drm-next with patch in comment 27. Created attachment 31361 [details] working.regs before suspend/resume on drm-next kernel with patch from comment 27. (In reply to comment #27) > http://people.freedesktop.org/~airlied/scratch/combios-readback.patch > > another revision of this patch to test. > > > Also get the latest radeontool and redump the before/after regs, I added some > more regs (use regmatch '*') > I attached the broken.regs and working.regs while running the kernel in drm-next (kernel 2.6.32-rc6) with the patch in comment 27. The result was the same as before. I am able to suspend but upon resume, the backlight for the screen doesn't turn back on for the LVDS. Created attachment 31398 [details] working.regs before suspend/resume on drm-next kernel with patch from comment 27. Real version. Created attachment 31399 [details] broken.regs after resume from suspend running kernel drm-next with patch in comment 27. Real version. http://people.freedesktop.org/~airlied/scratch/combios-readback-v3.patch yet another patch attempt. Created attachment 31400 [details]
registers before suspend with combios-v3 patch.
Registers before suspend when using kernel with the combios-v3 patch.
Created attachment 31401 [details]
Registers after resume from suspend with combios-v3 patch.
Registers after resume from suspend with kernel build with combios-v3 patch.
Created attachment 31402 [details]
Registers after resume from suspend with combios-v3 patch. 2nd try.
Created attachment 31403 [details]
registers before suspend with combios-v3 patch. 2nd try.
Created attachment 31410 [details]
kms Xorg.0.conf before suspending.
Created attachment 31411 [details]
kms Xorg.0.conf after resuming.
What I did to get these 2 kms Xorg.0.conf logs:
1) Boot into kms
2) copy Xorg.0.conf to Xorg.0.conf.beforesuspend
3) switch to VT and as root service gdm stop
4) echo 0 > /sys/class/vtconsole/vtcon1/bind
5) modprobe -r radeon
6) echo -n mem > /sys/power/state
7) resume
8) vbetool post
9) modprobe radeon modeset=1 agpmode=-1
10) servide gdm start
11) copy Xorg.0.conf to Xorg.0.conf.afterresume
Created attachment 31430 [details]
Here are the registers before suspend.
These are the working registers. This was taken after the discussion on IRC with tormod and airlied about the radeon kms module problems with DDX.
Created attachment 31431 [details]
Broken registers after resume.
These are the registers after resume. The LVDS backlight is still not on. This was taken after the discussion with airlied and tormod about kms and DDX race condition. The workaround was to put radeon in /etc/modules to ensure it loaded before the DDX or X loaded.
Created attachment 31439 [details] dmesg after a resume last nightly build from git with combios_readback_v3 + applied patch from Jerome Glisse ( commit 28590df27d40ff101dc1533654a3ea972f7d3679 Author: christian hartmann <cornogle@googlemail.com> Date: Tue Nov 24 10:12:13 2009 +0100 applying the Add_range_validation_function_v2.patch from Jerome Glisse Signed-off-by: christian hartmann <cornogle@googlemail.com> commit 587d36f3209ed046f55e6ad5dfc9747012664ba2 Author: christian hartmann <cornogle@googlemail.com> Date: Tue Nov 24 10:11:01 2009 +0100 applying the patch combios_readback.patch.V3 from airlied Signed-off-by: christian hartmann <cornogle@googlemail.com> commit a8a8a669ea13d792296737505adc43ccacf3a648 Merge: 931ed94 a7d73d8 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Nov 19 20:29:34 2009 -0800 Merge branch 'i2c-pnx-fixes' of git://git.fluff.org/bjdooks/linux The screen is not black, but I have problems to login in x with compiz, see last lines, but I do not know if there is already another bug entry for these error message Created attachment 31440 [details]
working.regs before suspend
Created attachment 31441 [details]
broken.regs after resume
Update of 2.6.32-rc8: a) s2disk and s2ram works perfectly for me now after pulling drm-2.6 drm-linus commit 1d33047c9f0ad5a5e3cacf496557aa1672d95d41 Merge: 28590df 5349ef3 Author: christian hartmann <cornogle@googlemail.com> Date: Tue Nov 24 15:13:51 2009 +0100 Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 into rc8_drm_readback b) therefore some icons (the gnome-panel icons) are now screwed up now. c) echo mem > /sys/power/state will suspend and resume, but the screen looks very strange, I can see for a few miliseconds a message "codec_read 0: read timeout for register 0x2", the screen looks like it will burn / flame, it look cool too :) Xorg is running opkay, after the resume from mem. d) I tried also vbetool post in the console, but this is horrible, cause black screen as it is described above from eruditehermit. Switching to X looks show me a very big mouse pointer, but I can not see anything else. I was able to blindly type "rcgdm stopt" or to login blindly via gdm and perform a rcgdm stop. When I switch back from Xorg here, the console is not resetted as it should be. It is lighted up, but I see the whole screen is flashing with random chars in darkgrey like a cursor does in the console. Restarting gdm/xorg gives me the same error as before the latest git pull: [ 2320.550802] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(11). [ 2320.559919] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! [ 2321.352296] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(11). [ 2321.361484] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! So vbetool does not work for me too, yet. (But s2disk does his job now, great.) e) whenever I have the boot option "splash" enabled, i cannot enter anymore the uswsup-key to encrypt my suspended image. have to reboot and set the nosplash option. sysrequest gives me only help message, but no task, no regs, no mem. only sysrq + O (poweroff) works at this state. this is all the time I have KMS enabled. using so far no splash until it it would be fixed. (In reply to comment #45) > Update of 2.6.32-rc8: > d) I tried also vbetool post in the console, but this is horrible, cause black > screen as it is described above from eruditehermit. Switching to X looks show > me a very big mouse pointer, but I can not see anything else. I was able to > blindly type "rcgdm stopt" or to login blindly via gdm and perform a rcgdm > stop. > When I switch back from Xorg here, the console is not resetted as it should be. > It is lighted up, but I see the whole screen is flashing with random chars in > darkgrey like a cursor does in the console. Restarting gdm/xorg gives me the > same error as before the latest git pull: > [ 2320.550802] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule > IB(11). > [ 2320.559919] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! > [ 2321.352296] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule > IB(11). > [ 2321.361484] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB ! > > So vbetool does not work for me too, yet. (But s2disk does his job now, great.) The only solution for me of this mess up is to %echo -n mem > /sys/power/state again, and resume again -> console is back as it should be. Xorg is usless until reboot cause of the IB schedule errors ( since the vbetool post) Comment on attachment 31441 [details]
broken.regs after resume
was before pulling drm-linus
Comment on attachment 31440 [details]
working.regs before suspend
was before pulling drm-linus
Comment on attachment 31439 [details]
dmesg after a resume
was before pulling drm-linus
Created attachment 31447 [details]
echo -n mem > sys/power/state
c) message "codec_read 0: read
timeout for register 0x2", the screen looks like it will burn / flame, it look
cool too :) Xorg is running opkay, after the resume from mem.
Created attachment 31449 [details]
b) therefore some icons (the gnome-panel icons) are now screwed up now.
Created attachment 33917 [details]
dmesg upon resume 2.6.33 drm linus branch of airlied tree
Here is the dmesg when s/r on 2.6.33 drm-linus branch of tree at git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus on 20100310.
Created attachment 33935 [details]
radeontool register dump before suspend (working state) 20100310 with VGA plugged in.
radeontool register dump before suspend (working state) 20100310 with VGA plugged in.
Created attachment 33936 [details]
radeontool register dump after resume (broken state) 20100310 with VGA plugged in.
radeontool register dump after resume (broken state) 20100310 with VGA plugged in.
Created attachment 33937 [details]
lspci output before suspend (working state) with VGA plugged in.
lspci output before suspend (working state) with VGA plugged in.
Created attachment 33938 [details]
lspci output after resume (broken state) with VGA plugged in.
lspci output after resume (broken state) with VGA plugged in.
Created attachment 33940 [details]
register dumps and mmapr command output
The radeontool register dumps were performed using the following script I created.
#!/bin/bash
for x in 0x220 0x224 0x228 0x320 0x324 0x328 0x32c 0x23c 0x33c
do
./radeontool regmatch $x > 20100310_regmatch_$x\_LVDS_VGA_broken.reg
done
cd /sys/bus/pci/devices/0000:01:00.0
mmapr resource0 0 256 | xxd > /home/user/20100310_mmapr_LVDS_VGA_broken
cd /home/user
repeated for working state as well
Also included are the lspci and reg dumps from the previous posts on 20100310 for convenience.
Created attachment 33945 [details]
Register dumps and radeon_vram_mm radeon_pm_info
output from registers 0xe0, 0x130, 0xb00, 0xb0c, 0x148, 0x108
cat /sys/kernel/debug/dri/0/radeon_pm_info
cat /sys/kernel/debug/dri/0/radeon_vram_mm
when mount -t debugfs none /sys/kernel/debug
This was performed with X running. Kernel is 2.6.33 drm-linus branch of airlied tree.
Created attachment 33946 [details]
Register dumps and radeon_vram_mm radeon_pm_info using VT ONLY (NO X SERVER)
output from registers 0xe0, 0x130, 0xb00, 0xb0c, 0x148, 0x108
cat /sys/kernel/debug/dri/0/radeon_pm_info
cat /sys/kernel/debug/dri/0/radeon_vram_mm
when mount -t debugfs none /sys/kernel/debug
This was performed WITHOUT X running. Kernel is 2.6.33 drm-linus branch of airlied
tree.
Created attachment 34340 [details]
all registers with agpmode=-1 VGA and LVDS plugged in after resume.
Created attachment 34341 [details]
all registers with agpmode=-1 VGA and LVDS plugged in before suspend.
Created attachment 34342 [details]
all registers with agpmode=-1 VGA and LVDS plugged in after resume.
Created attachment 34343 [details]
all registers with agpmode=-1 VGA and LVDS plugged in before suspend.
Created attachment 34344 [details]
all registers with colortiling off agpmode=-1 VGA and LVDS plugged in after resume.
Created attachment 34345 [details]
all registers with agpmode=-1 colortiling off, VGA and LVDS plugged in before suspend.
Created attachment 34346 [details]
all registers with agpmode=-1 colortiling off VGA and LVDS plugged in before suspend new registers + switched to VT with X running.
Created attachment 34347 [details]
all registers with agpmode=-1 colortiling off VGA and LVDS plugged in after resume new registers + switched to VT with X running.
git clone git://people.freedesktop.org/~stuart/vbtracetool cd vbtracetool; make kill X, suspend, resume, echo 0 > /sys/class/vtconsole/vtcon1/bind rmmod radeon vbtracetool -p -l 2> mytracelog gzip mytracelog stick it here. Created attachment 34349 [details]
log from vbtracetool obtained using airlied's instructions posted above
Created attachment 34350 [details]
unloading radeon before suspend, resuming and if no text mode comes up, running vbtracetool, then loading radeon
http://people.freedesktop.org/~airlied/scratch/bios_post_test.patch can you try with the attached patch. if that doesn't help, can you suspend/resume, unload radeon radeontool regset CONFIG_CNTL 0x0xc0100 then vbetool post and see if text mode comes back. What is the status on this issue? It looks like there was some pretty furious activity for a while then a sudden stop. Is there anything I can do to help track it down? I've had this issue for a couple of years, but have just lived with it (same hardware). *** Bug 24097 has been marked as a duplicate of this bug. *** -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/54. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.