Bug 14980 - commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 beaks OpenGL after hibernation
Summary: commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 beaks OpenGL after hibernation
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-12 15:11 UTC by Sebastien Valette
Modified: 2008-03-17 17:49 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
this fix the vt switching crash that happens with compiz activated (701 bytes, patch)
2008-03-16 15:51 UTC, Alban Browaeys
no flags Details | Splinter Review
possible fix (985 bytes, patch)
2008-03-17 11:12 UTC, Alex Deucher
no flags Details | Splinter Review
Xorg log (non working patch) (55.14 KB, text/plain)
2008-03-17 12:31 UTC, Sebastien Valette
no flags Details
Xorg log (working patch) (54.89 KB, text/x-log)
2008-03-17 12:32 UTC, Sebastien Valette
no flags Details
possible fix (1.20 KB, patch)
2008-03-17 14:49 UTC, Alex Deucher
no flags Details | Splinter Review
Xorg log (2nd non-working patch) (54.74 KB, text/plain)
2008-03-17 15:23 UTC, Sebastien Valette
no flags Details
possible fix (1.21 KB, patch)
2008-03-17 15:48 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Valette 2008-03-12 15:11:46 UTC
after hibernation, launching an OpenGL programs gives the following error:

drmRadeonCmdBuffer: -22

I bisected it twice because it's my first bisect, and the result was:

dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 is first bad commit
commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94
Author: Alex Deucher <alex@cube.(none)>
Date:   Sat Mar 1 16:23:51 2008 -0500

    RADEON: memmap rework 1
    
    Don't restore memmap regs on every mode switch.
    Just do memmap save/restore/setup on server start and VT switch.

:040000 040000 18282e19fca68b7c5313b2cfcf8963fc6f7eb406 b7fd89d7822cecf666de7b7b45e8cf0dbc2dbc7e M      src
Comment 1 Sebastien Valette 2008-03-12 17:29:00 UTC
after actually reading the commit log, I tried to switch terminal (ALT+CTRL+F1) after hibernation, and..... the problem is still here (restarting Xorg works of course)
Comment 2 Alban Browaeys 2008-03-16 15:51:45 UTC
Created attachment 15212 [details] [review]
this fix the vt switching crash that happens with compiz activated

I believe this is the same issue as I have except in my case using compiz it makes X crash. This patch fixed it for me. Basically it add RADEONRestoreMemMapRegisters(pScrn, info->ModeReg); even for dri on PCIE  like I believe was the case when the restore code was in atombios_crtc and legacycrtc .

Could you test to confirm this is the same issue ?
Comment 3 Sebastien Valette 2008-03-16 18:33:15 UTC
(In reply to comment #2)
> Created an attachment (id=15212) [details]
> this fix the vt switching crash that happens with compiz activated
> 
> I believe this is the same issue as I have except in my case using compiz it
> makes X crash. This patch fixed it for me. Basically it add
> RADEONRestoreMemMapRegisters(pScrn, info->ModeReg); even for dri on PCIE  like
> I believe was the case when the restore code was in atombios_crtc and
> legacycrtc .
> 
> Could you test to confirm this is the same issue ?
> 

Confirmed! The patch fixes the issue. Thanks!
Comment 4 Julien Cristau 2008-03-17 08:58:12 UTC
(In reply to comment #3)
> Confirmed! The patch fixes the issue. Thanks!
> 
please don't close the bug until a fix is actually applied, thanks (afaics this isn't the case here).
Comment 5 Sebastien Valette 2008-03-17 09:01:03 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Confirmed! The patch fixes the issue. Thanks!
> > 
> please don't close the bug until a fix is actually applied, thanks (afaics this
> isn't the case here).
> 

Oops, sorry. I did not know the exact rules for closing a bug.
Comment 6 Alex Deucher 2008-03-17 11:12:28 UTC
Created attachment 15230 [details] [review]
possible fix

(In reply to comment #2)
> Created an attachment (id=15212) [details]
> this fix the vt switching crash that happens with compiz activated
> 
> I believe this is the same issue as I have except in my case using compiz it
> makes X crash. This patch fixed it for me. Basically it add
> RADEONRestoreMemMapRegisters(pScrn, info->ModeReg); even for dri on PCIE  like
> I believe was the case when the restore code was in atombios_crtc and
> legacycrtc .

RADEONRestoreMemMapRegisters() gets called via RADEONAdjustMemMapRegisters() if the DRI is enabled regardless of whether the card is PCIE or not.  The ordering is  apparently causing the problem.  Does this patch work?
Comment 7 Sebastien Valette 2008-03-17 12:02:02 UTC
(In reply to comment #6)
> Created an attachment (id=15230) [details]
> possible fix
> 
> (In reply to comment #2)
> > Created an attachment (id=15212) [details] [details]
> > this fix the vt switching crash that happens with compiz activated
> > 
> > I believe this is the same issue as I have except in my case using compiz it
> > makes X crash. This patch fixed it for me. Basically it add
> > RADEONRestoreMemMapRegisters(pScrn, info->ModeReg); even for dri on PCIE  like
> > I believe was the case when the restore code was in atombios_crtc and
> > legacycrtc .
> 
> RADEONRestoreMemMapRegisters() gets called via RADEONAdjustMemMapRegisters() if
> the DRI is enabled regardless of whether the card is PCIE or not.  The ordering
> is  apparently causing the problem.  Does this patch work?
> 

Unfortunately, no. It is actually worse, since Xorg is broken after resume (the mouse cursor displays fine, but the windows are corrupted ( something like the lines are interleaved)

my relevant xorg bits, just in case:
Section "Device"
        Identifier      "ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]"
        Driver          "ati"
        BusID           "PCI:1:0:0"
        Option          "GARTSize" "64"
        Option          "XAANoOffscreenPixmaps" "true"
        Option          "AGPMode" "4"
        Option          "EnablePageFlip" "true"
        Option          "DynamicClocks" "true"
EndSection



Comment 8 Alex Deucher 2008-03-17 12:15:15 UTC
(In reply to comment #7)

> Unfortunately, no. It is actually worse, since Xorg is broken after resume (the
> mouse cursor displays fine, but the windows are corrupted ( something like the
> lines are interleaved)

Can you attach your logs in both the working and non-working cases?
Comment 9 Sebastien Valette 2008-03-17 12:31:33 UTC
Created attachment 15231 [details]
Xorg log (non working patch)
Comment 10 Sebastien Valette 2008-03-17 12:32:11 UTC
Created attachment 15232 [details]
Xorg log (working patch)

here are the logs
Comment 11 Alex Deucher 2008-03-17 14:49:01 UTC
Created attachment 15234 [details] [review]
possible fix

How about this patch?
Comment 12 Sebastien Valette 2008-03-17 15:21:52 UTC
(In reply to comment #11)
> Created an attachment (id=15234) [details]
> possible fix
> 
> How about this patch?
> 

no luck either. Xorg hibernation is not broken anymore, but I still get drmRadeonCmdBuffer: -22 from glxgears. Xor log following...

Comment 13 Sebastien Valette 2008-03-17 15:23:02 UTC
Created attachment 15236 [details]
Xorg log (2nd non-working patch)
Comment 14 Alex Deucher 2008-03-17 15:48:04 UTC
Created attachment 15239 [details] [review]
possible fix

How about this one?
Comment 15 Sebastien Valette 2008-03-17 15:59:54 UTC
(In reply to comment #14)
> Created an attachment (id=15239) [details]
> possible fix
> 
> How about this one?
> 

sorry, no, it doesn't work. Same error message.
Comment 16 Alex Deucher 2008-03-17 17:49:41 UTC
I went ahead and pushed Alban's fix.  This should restore the old behavior.  I'm not sure why you need to do it twice...

f71ac0e40b9d950bcb3bba42a75d41f45b6ed1bf


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.