Summary: | xf86-video-ati-6.6.192 segfaults when a client makes it enter RADEONDisplayPowerManagementSet() on a r200 card | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Thierry Vignaud <thierry.vignaud> | ||||||
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
Severity: | major | ||||||||
Priority: | medium | CC: | airlied, burnus, lukaswu, mat, sndirsch, yoshi314 | ||||||
Version: | 7.2 (2007.02) | ||||||||
Hardware: | x86 (IA32) | ||||||||
OS: | Linux (All) | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 11749 | ||||||||
Attachments: |
|
Description
Thierry Vignaud
2007-04-26 09:06:00 UTC
My card is an ATI Radeon 8500 QL (r200 driven). Would be great if you could get a full backtrace with gdb, preferably with a radeon_drv.so with debugging symbols. I'll try > Would be great if you could get a full backtrace with gdb, preferably with a > radeon_drv.so with debugging symbols. At https://bugzilla.novell.com/show_bug.cgi?id=264720#c28 on can find the following backtrace: RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237 2237 MonType = pPort->MonType; (gdb) bt #0 RADEONDPMSSetOff (pScrn=0x7ffb30, pPort=0x0) at radeon_display.c:2237 #1 0x00002ac2af42aeb0 in RADEONDisplayPowerManagementSet (pScrn=0x7ffb30, PowerManagementMode=1, flags=0) at radeon_display.c:2373 #2 0x00000000004944fe in DPMSSet (level=1) at xf86DPMS.c:168 #3 0x00002ac2aedb3069 in ProcDPMSForceLevel (client=0xcbb790) at dpms.c:256 #4 0x0000000000450d6b in Dispatch () at dispatch.c:457 #5 0x0000000000439a8d in main (argc=10, argv=0x7ffffdca6cd8, envp=<value optimized out>) at main.c:445 (gdb) p pPort $1 = (RADEONConnector *) 0x0 Created attachment 10203 [details] [review] Workaround? Does this patch help? Not that I understand how RADEONGetCrtcConnector() could ever return NULL, or why that doesn't cause a crash earlier on... I suspect there could be some memory corruption going on. I've tried this patch. At least "mplayer -vo xv" doesn't crash anymore (though, its display is black) (which was a new side effect of drivers 6.6.19x). I've left openarena to run during the night. When I woke up, the X server was freezed and I had to use the magic keys in order to sync, remount ro and reboot my machine :-( There was nothing usefull in trace I'll try to get you a debug trace through gdb -x... I'ven't been able to get a backtrace with gdb. It didn't even appeared in Xorg.0.log like in the old days (In reply to comment #6) > At least "mplayer -vo xv" doesn't crash anymore (though, its display is > black) (which was a new side effect of drivers 6.6.19x). The log files I could find following the links from here show the driver detecting two connected monitors. Is that the case for you as well (if you're not sure, please attach (as opposed to paste) the full Xorg.0.log file)? If so, do you actually have two monitors connected? > I've left openarena to run during the night. > When I woke up, the X server was freezed and I had to use the magic keys in > order to sync, remount ro and reboot my machine :-( > There was nothing usefull in trace Sounds like a GPU lockup, i.e. a different problem. Please follow up to another report about this or file a new one if there's none. Created attachment 10238 [details]
6.6.192's log
No, I've only one CRT monitor.
Though this change of behaviour between 6.6.3 and 6.6.192 *may* tell us the new driver does detect a ghost monitor: @@ -571,22 +581,24 @@ (II) RADEON(0): 363639310a20202020202020000000fd (II) RADEON(0): 0032781e480b000a2020202020200031 (II) RADEON(0): -(II) RADEON(0): Primary: +(II) RADEON(0): Port1: + Monitor -- CRT + Connector -- VGA + DAC Type -- Primary + TMDS Type -- External + DDC Type -- VGA_DDC +(II) RADEON(0): Port2: Monitor -- CRT Connector -- VGA DAC Type -- Primary - TMDS Type -- NONE + TMDS Type -- External DDC Type -- VGA_DDC -(II) RADEON(0): Secondary: - Monitor -- NONE - Connector -- None - DAC Type -- Unknown - TMDS Type -- NONE - DDC Type -- NONE +(II) RADEON(0): ---- Primary Head: Port1 ---- +(II) RADEON(0): ---- Secondary Head: Port2 ---- (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=35000; xclk=25000 -(WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) RADEON(0): Validating modes on Primary head --------- +(II) RADEON(0): Total number of valid DDC mode(s) found: 0 (II) RADEON(0): monitor1: Using hsync range of 30.00-72.00 kHz (II) RADEON(0): monitor1: Using vrefresh range of 50.00-120.00 Hz (II) RADEON(0): Clock range: 20.00 to 350.00 MHz (In reply to comment #8) > Sounds like a GPU lockup, i.e. a different problem. Please follow up > to another report about this or file a new one if there's none. This lockup is already reported in bug #10224 The sister bug at SUSE, https://bugzilla.novell.com/show_bug.cgi?id=264720#c39 contains as attachment the 0001-Clean-up-PortInfo-to-CRTC-mapping.txt patch by Luc, which is presumably also in the current git version at X.org. (In reply to comment #12) > The sister bug at SUSE, > https://bugzilla.novell.com/show_bug.cgi?id=264720#c39 > contains as attachment the 0001-Clean-up-PortInfo-to-CRTC-mapping.txt patch by > Luc, which is presumably also in the current git version at X.org. It isn't, because nobody's pushed it upstream... *sigh* Does it fix the problem? > It isn't, because nobody's pushed it upstream... At least the attachment to the SUSE bugzilla was not even one hour old when I pointed to the patch ;-) > *sigh* Does it fix the problem? A quick test indicates that is solves the problem on my PC. *** Bug 9892 has been marked as a duplicate of this bug. *** the patch doesn't segfault the driver anymore on my pc as well. but my display still goes into powersaving mode, and the video mode is not restored when going back to console (i could shut down the system cleanly by typing "poweroff" command). there are no errors in the Xorg log (as described in duplicate 9892 bug). > the patch doesn't segfault the driver anymore on my pc as well. > but my display still goes into powersaving mode, You mean it does not recover? Otherwise going to the powersave mode is ok. > and the video mode is not restored when going back to console. This was later fixed, see additional one-liner patch at https://bugzilla.novell.com/show_bug.cgi?id=264720#c52 Do you have still problems after applying *both* patches? Because here everything seems to work. > You mean it does not recover? Otherwise going to the powersave mode is ok.
definitely not if it's all you get after launching X. and the display does not restore, even when killing the X server.
i tried the patch. my display still goes off. this time i managed to return to the console. i'll try the dpms forcing trick mentioned in the link, maybe this'll help (or maybe i have to disable dpms?)
It definitively looks better now (though still mplayer -vo xv still doesn't display anything). maplyer & 3D apps do not crash anymore (I've tested screensaver yet). Will someone commit those patches ? However krandrtray make it segfaults when changing the resolution but I'll enter a new bug report for that: (**) RADEON(0): RADEONSaveScreen(2) (**) RADEON(0): RADEONSaveScreen(2) (**) RADEON(0): RADEONSaveScreen(2) Backtrace: 0: /etc/X11/X(xf86SigHandler+0x85) [0x80c46e5] 1: [0xffffe420] 2: /etc/X11/X(RRCrtcSet+0x2a) [0x816a91a] 3: /etc/X11/X(ProcRRSetScreenConfig+0x600) [0x816f8d0] 4: /etc/X11/X [0x81692a3] 5: /etc/X11/X [0x81527f7] 6: /etc/X11/X(Dispatch+0x1af) [0x8089d6f] 7: /etc/X11/X(main+0x465) [0x8071025] 8: /lib/i686/libc.so.6(__libc_start_main+0xe0) [0xb7cbff90] 9: /etc/X11/X(FontFileCompleteXLFD+0x1e5) [0x80703a1] Fatal server error: Caught signal 11. Server aborting (II) AIGLX: Suspending AIGLX clients for VT switch (**) RADEON(0): RADEONLeaveVT (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode(0x8238bc8) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC2, offset: 0x00000000 (**) RADEON(0): Wrote: 0x00000000 0x00000000 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=0, fd=0, pd=0 (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Ok, leaving now... I opened bugs #11780 and #11781 for the new crash and the XV issue. Will these patches be commited into git? I've checked the patches from Luc and Novell bug into ati is anyone still seeing the issue? i'm not getting crashes/segfaults now, but i'm still not getting anything on screen as well. i guess i'll reopen my bug then. *** Bug 11898 has been marked as a duplicate of this bug. *** Since now I am using Slackware 12 and my bugs (ie 11898) related to ATI driver were marked duplicate, i did some additional tests with later versions of driver provided by Patric Volkerding. Slackware 12 is normally provided with 6.6.192 ati driver version, fortunately there exists version 6.6.3 which seems to solve all my problems with stability, resolution and DPMS (bugs 11898, 11911, 11897). I would suggest to close this bug then. 6.6.3 is an *older* driver... (In reply to comment #26) > 6.6.3 is an *older* driver... > Yeahh.. You right- friday, late afternoon :(( The crash should be fixed, other issues should be tracked in other bugs. |
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.