Bug 14980 - commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 beaks OpenGL after hibernation
commit dd8ee1b444f4b973a1e0fadca5f943f2162b5e94 beaks OpenGL after hibernation
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
unspecified
Other All
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
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