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 :)
change to xorg component
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.
Created attachment 17523 [details] the config file and log for S3 issue
(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
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.
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
The latest commit appears to fix this bug: commit d82f2938f69402c641a1c8362fdc513419b27659 Author: Alex Deucher <alexdeucher@gmail.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.
ignore what i said, more testing showed the garbling is still there :(
as of xorg 1.6 this behaviour doesnt appear anymore, i can now resume normally without any workarounds. closing this bug.
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. :(
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.
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.
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?
(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.
Created attachment 25863 [details] states from avivotool aka radeontool.
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 :)
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
Created attachment 25880 [details] states from radeontool for 485 (200m)
ok alex, new attachment using radeontool, please take a look when you have the time :)
(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?
(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.
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
(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
Created attachment 26010 [details] rs485 rom dump here ya go alex.. rom dump from my rs485
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.
Created attachment 26342 [details] Dump of ATI Radeon X700 M26 PCIE VBIOS
(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.
(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
> 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
(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.
(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.
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!
(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 2.6.29.5-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... :(
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.
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.