|Summary:||radeon R485 (mobile 200m) gets garbled display when resuming from resume to ram (s3 state)|
|Product:||xorg||Reporter:||Paulo Dias <paulo.miguel.dias>|
|Component:||Driver/Radeon||Assignee:||xf86-video-ati maintainers <xorg-driver-ati>|
|Status:||RESOLVED INVALID||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||high||CC:||paulo.miguel.dias, scd, the.dmol|
|i915 platform:||i915 features:|
Description Paulo Dias 2008-06-26 19:32:17 UTC
Created attachment 17410 [details] tar.bz2 with small video of the problem, xorg.conf and xorg.log The summary says it all. Suspend and resume works just fine BUT when the card resumes, the screen is complete garbled. vbetool post just hangs the card with error: RS485MC - test BR# 18675 DRM from git 25/06/2008 Xorg cvs (see attached xorg.log) xorg ati driver 6.9.0 going back and forth between console and desktop doesnt work, console is garbled also, like a old tv with bad signal frequency. resume to disk works just fine (which has some logic since the computer is turned off and the card is reseted). i'm adding a small video of the problem, xorg.conf and X11.log. hope this helps, besides this, the driver is rock solid :) compiz too :)
Comment 1 Dave Airlie 2008-07-03 20:41:47 UTC
change to xorg component
Comment 2 Dave Airlie 2008-07-03 20:46:26 UTC
story so far, happens with DRI off and no accel. happens on VGA monitor plugged into laptop as well on LVDS screen. I've added some of the more obvious plls to radeontool but nothing showing up yet. interesting is that vt switch won't help and ls on the VT stabilises it for a bit.
Comment 3 Liu Xinyun 2008-07-03 23:17:58 UTC
Created attachment 17523 [details] the config file and log for S3 issue
Comment 4 Liu Xinyun 2008-07-03 23:19:58 UTC
(In reply to comment #3) > Created an attachment (id=17523) [details] > the config file and log for S3 issue I have a fujitsu lifebook 2210 with Ubuntu 8.04. I have tested the X and custom build X, both can suspend OK. see attachment. http://bugs.freedesktop.org/attachment.cgi?id=17523
Comment 5 Alex Deucher 2008-07-04 10:48:27 UTC
Created attachment 17533 [details] [review] possible fix This patch may fix the issue. It may fix some other LVDS issues as this is the preferred generic method for enabling LVDS. The DispPwrMan stuff should probably be done in EnterVT/LeaveVT() rather than at every dpms event.
Comment 6 Paulo Dias 2008-07-04 23:44:46 UTC
Hi alex, applied the patch against latest git (05072008), same behaviour remains :( the patch didnt fix the problem, screen remains garbled after resume from ram :( Do you need any info? best regards
Comment 7 Paulo Dias 2008-09-26 16:48:31 UTC
The latest commit appears to fix this bug: commit d82f2938f69402c641a1c8362fdc513419b27659 Author: Alex Deucher <email@example.com> Date: Fri Sep 26 13:51:24 2008 -0400 atombios updates from upstream if no one elses complains i believe we can close this bug.
Comment 8 Paulo Dias 2008-09-26 17:02:43 UTC
ignore what i said, more testing showed the garbling is still there :(
Comment 9 Paulo Dias 2009-04-16 12:27:15 UTC
as of xorg 1.6 this behaviour doesnt appear anymore, i can now resume normally without any workarounds. closing this bug.
Comment 10 Paulo Dias 2009-05-10 12:58:11 UTC
As of latest xorg 1.6.0 and radeon 6.1.2, this bug regressed and im having the same problem. also with kms/dri2 when i resume the screen is garbled, so kms doesnt solve it. :(
Comment 11 Paulo Dias 2009-05-10 13:00:07 UTC
Also, without using kms/dri2, using default vga=791 and 2.6.28 (ubuntu jaunty), the only workaround is to force pm-suspend with: pm-suspend --quirk-vbe-post --quirk-vbemode-restore --quirk-vbestate-restore vbetool then is able to fix the garbled screen. maybe a look at the vbetool could shed some light why default radeon isnt reseting the registers correctly.
Comment 12 Paulo Dias 2009-05-10 13:01:55 UTC
just to make it clear, the dri2/kms and stock jaunty/radeon where tested WITHOUT vbetool, i just mentioned it because if i use it in jaunty/radeon i can workaround this bug. no luck with vbetool adn kms/dri2 thought.
Comment 13 Paulo Dias 2009-05-12 09:45:11 UTC
I did a few more testing, something that is confusing me (as usual) is that lspci reports my card is a 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M], but a vbetool post command says: rs485mc - test bios br#18675 so what gives? any ideas?
Comment 14 Alex Deucher 2009-05-12 10:37:26 UTC
(In reply to comment #13) > I did a few more testing, something that is confusing me (as usual) is that > lspci reports my card is a 01:05.0 VGA compatible controller: ATI Technologies > Inc RS482 [Radeon Xpress 200M], but a vbetool post command says: > rs485mc - test bios br#18675 > > so what gives? any ideas? > Probably someone entered the name wrong on the pci ids site. Doesn't really matter though, from the driver's perspective they are the same chip.
Comment 15 Paulo Dias 2009-05-14 09:16:40 UTC
Created attachment 25863 [details] states from avivotool aka radeontool.
Comment 16 Paulo Dias 2009-05-14 09:22:09 UTC
Last night i've downloaded teh latest avivotool, aka radeontool from airlied git and performed a state dump for regmatch, i2c and romtables, before and after the suspend. The suspend worked but with the already state of affairs, the garbled screen. i'm using kernel 2.6.29 with kms/ddx, mesa and radeon driver, all from glisse git tree. the only activated radeon configuration in my xorg is pageflips and backing store (same behaviour with or without this settings). the new attachment is called "states from avivotool aka radeontool" please comment on this, this bug is very hard to catch and VERY annoying :P best regards and keep up the good work, dri2/kms is a marvel to use already :)
Comment 17 Alex Deucher 2009-05-14 10:38:18 UTC
RS4xx chips are not avivo based so you need to use radeontool rather than avivotool. They are both in the same repo: http://cgit.freedesktop.org/~airlied/radeontool when your system is working: (as root) ./radeontool regmatch '*' > working.regs after resume when your system is not working: (as root) ./radeontool regmatch '*' > broken.regs
Comment 18 Paulo Dias 2009-05-14 19:56:56 UTC
Created attachment 25880 [details] states from radeontool for 485 (200m)
Comment 19 Paulo Dias 2009-05-14 19:57:44 UTC
ok alex, new attachment using radeontool, please take a look when you have the time :)
Comment 20 Alex Deucher 2009-05-14 22:47:17 UTC
(In reply to comment #18) > Created an attachment (id=25880) [details] > states from radeontool for 485 (200m) > I'm assuming before_regmatch.txt is the dump of the working state and after_regmatch.txt is the broken state?
Comment 21 Paulo Dias 2009-05-15 08:46:41 UTC
(In reply to comment #20) > (In reply to comment #18) > > Created an attachment (id=25880) [details] [details] > > states from radeontool for 485 (200m) > > > > I'm assuming before_regmatch.txt is the dump of the working state and > after_regmatch.txt is the broken state? > That is correct, before is the default state and after is the broken/garbled state.
Comment 22 Alex Deucher 2009-05-19 11:14:59 UTC
Can you attach your video bios? As root: cd /sys/bus/pci/devices/<pci bus id of video card>/ echo 1 > rom cat rom > /tmp/vbios.rom echo 1 > rom
Comment 23 Alex Deucher 2009-05-19 11:15:34 UTC
(In reply to comment #22) > Can you attach your video bios? > > As root: > cd /sys/bus/pci/devices/<pci bus id of video card>/ > echo 1 > rom > cat rom > /tmp/vbios.rom > echo 1 > rom > should be: cd /sys/bus/pci/devices/<pci bus id of video card>/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Comment 24 Paulo Dias 2009-05-19 11:35:10 UTC
Created attachment 26010 [details] rs485 rom dump here ya go alex.. rom dump from my rs485
Comment 25 Alex Deucher 2009-05-30 17:08:34 UTC
As I suggested on IRC, please try Dave's version of vbetool (http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz) to post the card which will dump the regs that are configured during post.
Comment 26 Stefan Dalibor 2009-06-01 14:24:42 UTC
Created attachment 26342 [details] Dump of ATI Radeon X700 M26 PCIE VBIOS
Comment 27 Stefan Dalibor 2009-06-01 14:48:21 UTC
(In reply to comment #26) > Created an attachment (id=26342) [details] > Dump of ATI Radeon X700 M26 PCIE VBIOS Sorry, here the bug description: I have an HP nw8240 w/ Radeon X700 M26 PCIE (chip ID 0x5653), running Fedora 11 rc1 (kernel 2.6.29, Xorg ATI driver version 6.12.2). My thawing experience is much worse than that of Paolo -- on resuming from both S3 and S4, the display goes completely south, on X display and text console, rendering suspend/resume completely unuseable. After rebooting the laptop, a kernel oops is reproducably reported: http://www.kerneloops.org/submitresult.php?email=scd%40lst.de&number=432778 I tried several of the pm-hibernate quirks (included that of Paolo), but with no effect. As far as I have read in the pm-utils 1.2.5 scripts (98smart-kernel-video), the vbetools quirks are not executed on resume with KMS enabled kernels as the drivers are assumed to be "smart" enough to make this unnecessary.
Comment 28 Alex Deucher 2009-06-01 22:09:52 UTC
(In reply to comment #27) > (In reply to comment #26) > > Created an attachment (id=26342) [details] [details] > > Dump of ATI Radeon X700 M26 PCIE VBIOS > > Sorry, here the bug description: > I have an HP nw8240 w/ Radeon X700 M26 PCIE (chip ID 0x5653), running Fedora 11 > rc1 (kernel 2.6.29, Xorg ATI driver version 6.12.2). > > My thawing experience is much worse than that of Paolo -- on resuming from both > S3 and S4, the display goes completely south, on X display and text console, > rendering suspend/resume completely unuseable. Does setting the radeon drm module option r4xx_atom=1 help? Also you might have better luck with Jerome's kms drm tree: http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-radeon
Comment 29 Paulo Dias 2009-06-02 12:59:33 UTC
> Does setting the radeon drm module option r4xx_atom=1 help? Also you might > have better luck with Jerome's kms drm tree: > http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-radeon for the record, i'm using glisses tree and r4xx_atom doesnt change anything of the above behaviour, still garbled screen. best regards
Comment 30 Alex Deucher 2009-06-02 13:23:25 UTC
(In reply to comment #29) > for the record, i'm using glisses tree and r4xx_atom doesnt change anything of > the above behaviour, still garbled screen. That option isn't relevant for your card.
Comment 31 Stefan Dalibor 2009-06-03 13:14:59 UTC
(In reply to comment #28) > Does setting the radeon drm module option r4xx_atom=1 help? Also you might > have better luck with Jerome's kms drm tree: > http://cgit.freedesktop.org/~glisse/drm-next/log/?h=drm-next-radeon Thanks for the hint, but the ATOM BIOS option doesn't fix it -- same display failure and kernel oops after resume. To clarify the failure: on resume, the display starts fine...I use encrypted FSs, and get to the password prompt fine. It seems that the bug is triggerd after userland (the pm-tools wakeup scripts??) take over. Also, I get the same garbled screen if I boot only to run level 3 w/o X, and the weirdo stripes look a little bit different when switching between VTs. Another observation is that the garbled display already shows /before/ hibernation poweroff -- I can see some of the shutdown messages on the text console, than the display get"s garbled, than the machine pwoers down. Seems that this really is a KMS-related problem... I'll try to get the patched version you refer above installed on the weekend.
Comment 32 Paulo Dias 2009-07-10 11:39:03 UTC
with latest patches for linus tree based on kms branch (sent to me by airlied), i still have thos incredibly annoying bug :( no luck dave!
Comment 33 Stefan Dalibor 2009-07-12 14:21:00 UTC
(In reply to comment #32) > with latest patches for linus tree based on kms branch (sent to me by airlied), > i still have thos incredibly annoying bug :( no luck dave! Same for me w/ Fedora kernel 220.127.116.11-191 (which as far as I can see also contains some of the new DRM improvements). Three additional observations: 1. If I have the nw8240 in the docking station, with an external LCD attached to the DVI port of the docking station, the notebook seems to wake up fine -- but on closer examination, there is "pixel debris" on the screen, and some font glyphs are rendered garbled. 2. Each time I reboot after a wakeup from hibernation, I get a message about a kernel oops with kernel error messages: hres_timers_resume() called with IRQs enabled! and Kernel failure message 2: BUG: sleeping function called from invalid context at kernel/workqueue.c:440 See also http://www.kerneloops.org/submitresult.php?number=534049 for traceback details. 3. With the "Tux on Ice" alternate hibernation subsystem, I have the same problems as with the standard kernel hibernation. Something seems to be completely wrong with Linux hibernation... :(
Comment 34 Adam Jackson 2018-06-12 19:09:30 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.