Video memory corruption during suspend

Video memory corruption during suspend

[Karol Kozimor]

Hi,
I'm having an odd problem with video memory being corrupted during suspend.

My setup is:
ASUS L3800C laptop, Radeon M7, i845 chipset, using DRI and radeonfb.

Note that this is not specific to the kernel used, as I've been seeing 
similar corruption every now and then, most recently under 2.6.7 +
ACPICA20040715 + swsusp2.0.0.100 (S3, S4), but also under 2.4 with S1 (but 
not with S4/swsusp2).

I have a very simple script I use to suspend (i.e. basically echo $arg >
/proc/acpi/sleep), which is usually started by acpid. Once the script is
triggered (by pressing power / sleep button) and an X session is running, 
various red and green patches appear on the screen (the background image
and the tinted terminal emulator), followed by the VT switch the PM code
does. After resume and subsequent VT switch by the PM code the corruption
is still visible. The screen is properly restored by a manual VT switch.
The corruption is clearly related to the existing background pixmap, as
moving the windows does not change its pattern. Oddly enough, starting a GL
app such as glxgears and moving it into and out of focus also properly
restores the screen.

I'll be happy to provide any useful information.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: Video memory corruption during suspend

[Pavel Machek]

Hi!

> My setup is:
> ASUS L3800C laptop, Radeon M7, i845 chipset, using DRI and radeonfb.
> 
> Note that this is not specific to the kernel used, as I've been seeing 
> similar corruption every now and then, most recently under 2.6.7 +
> ACPICA20040715 + swsusp2.0.0.100 (S3, S4), but also under 2.4 with S1 (but 
> not with S4/swsusp2).
> 
> I have a very simple script I use to suspend (i.e. basically echo $arg >
> /proc/acpi/sleep), which is usually started by acpid. Once the script is
> triggered (by pressing power / sleep button) and an X session is running, 
> various red and green patches appear on the screen (the background image
> and the tinted terminal emulator), followed by the VT switch the PM code
> does. After resume and subsequent VT switch by the PM code the corruption
> is still visible. The screen is properly restored by a manual VT switch.
> The corruption is clearly related to the existing background pixmap, as
> moving the windows does not change its pattern. Oddly enough, starting a GL
> app such as glxgears and moving it into and out of focus also properly
> restores the screen.

So what happens on 2.6.7 with swsusp1? Can you try vesafb (and fbdev
Xserver)?

								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: Video memory corruption during suspend

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 4051 bytes --]

Just as a side note, all of the notebooks I have owned or worked on have 
had suspend issues.  Linux just doesn't handle it very well.  The common 
problems on resume are:

1. the screen is somehow switched to the external VGA port or port other 
than the LCD
2. the screen is 50% rolled; i.e. the whole screen has been shifted 
halfway down the screen with the bottom wrapping back up to the top
3. on a text console, the characters are garbage/high ascii/blocks
4. the back light is off and can't be turned back on

Of these I'm currently dealing with #1, 2, and 3.  I can fix #1 by using 
the Function-Display key to step through displays until I have selected 
the LCD display again.  I fix #2 by ctrl-alt-f1 and then back to X tty.  
I fix #3 by running setfont.  I haven't had to deal with #4 in over a 
year, but I no longer have that notebook.

Chris root # lspci -vvv -s 0:00.0
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host 
Bridge (rev 04)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [e4] #09 [d104]
        Capabilities: [a0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- 
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=<none>

Chris root # lspci -vvv -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 
Go] (rev a3) (prog-if 00 [VGA])
        Subsystem: Dell Computer Corporation: Unknown device 00d4
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
        Region 2: Memory at dff80000 (32-bit, prefetchable) [size=512K]
        Expansion ROM at 80000000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- 
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=<none>

no DRI/FB.

David

Pavel Machek wrote:

>Hi!
>
>  
>
>>My setup is:
>>ASUS L3800C laptop, Radeon M7, i845 chipset, using DRI and radeonfb.
>>
>>Note that this is not specific to the kernel used, as I've been seeing 
>>similar corruption every now and then, most recently under 2.6.7 +
>>ACPICA20040715 + swsusp2.0.0.100 (S3, S4), but also under 2.4 with S1 (but 
>>not with S4/swsusp2).
>>
>>I have a very simple script I use to suspend (i.e. basically echo $arg >
>>/proc/acpi/sleep), which is usually started by acpid. Once the script is
>>triggered (by pressing power / sleep button) and an X session is running, 
>>various red and green patches appear on the screen (the background image
>>and the tinted terminal emulator), followed by the VT switch the PM code
>>does. After resume and subsequent VT switch by the PM code the corruption
>>is still visible. The screen is properly restored by a manual VT switch.
>>The corruption is clearly related to the existing background pixmap, as
>>moving the windows does not change its pattern. Oddly enough, starting a GL
>>app such as glxgears and moving it into and out of focus also properly
>>restores the screen.
>>    
>>
>
>So what happens on 2.6.7 with swsusp1? Can you try vesafb (and fbdev
>Xserver)?
>
>								Pavel
>  
>

[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [ACPI] Re: Video memory corruption during suspend

[Karol Kozimor]

Thus wrote Pavel Machek:
> > My setup is:
> > ASUS L3800C laptop, Radeon M7, i845 chipset, using DRI and radeonfb.
[...]
> So what happens on 2.6.7 with swsusp1? Can you try vesafb (and fbdev
> Xserver)?

I don't have 2.6.7-vanilla at hand, but if 2.6.7-mm6 counts then yes,
swsusp1 also triggers that. Note that it doesn't seem to occur when DRI is
not actively used -- the radeon driver code takes quite a long time (up to
4 secs.) to switch to a text VT depending on circumstances, namely when KDE
is up. A plain windowmaker dekstop takes much shorter to switch.

As I'm leaving tomorrow, I won't have time to test with vesafb / fbdev
until next week.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] Re: Video memory corruption during suspend

[Micha Feigin]

On Thu, Jul 22, 2004 at 01:36:00PM -0400, David Ford wrote:
> Just as a side note, all of the notebooks I have owned or worked on have 
> had suspend issues.  Linux just doesn't handle it very well.  The common 
> problems on resume are:
> 

Actually all computers I worked with functioned great with software
suspend (up to solving dri issues), none of them managed to suspend
properly with windows (XP was worse them w2k).

> 1. the screen is somehow switched to the external VGA port or port other 
> than the LCD
> 2. the screen is 50% rolled; i.e. the whole screen has been shifted 
> halfway down the screen with the bottom wrapping back up to the top
> 3. on a text console, the characters are garbage/high ascii/blocks
> 4. the back light is off and can't be turned back on
> 
> Of these I'm currently dealing with #1, 2, and 3.  I can fix #1 by using 
> the Function-Display key to step through displays until I have
> selected 

Thats a weird one.

> the LCD display again.  I fix #2 by ctrl-alt-f1 and then back to X
> tty.  

If its an ATI with dri, I think it still needs a VT switch to reset the
driver. There was also something with nvidia I think. You should change
VT to the console and then change back on resume.

> I fix #3 by running setfont.  

Strange one also.

>I haven't had to deal with #4 in over a 
> year, but I no longer have that notebook.
> 

I had such problems a lot with windows and the screen saver. With linux
only when it got stuck (a over heating problem).

> Chris root # lspci -vvv -s 0:00.0
> 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host 
> Bridge (rev 04)
>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR+ FastB2B-
>        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort+ >SERR- <PERR-
>        Latency: 0
>        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=64M]
>        Capabilities: [e4] #09 [d104]
>        Capabilities: [a0] AGP version 2.0
>                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- 
> HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
>                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
> Rate=<none>
> 
> Chris root # lspci -vvv -s 01:00.0
> 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 
> Go] (rev a3) (prog-if 00 [VGA])
>        Subsystem: Dell Computer Corporation: Unknown device 00d4
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ 
> ParErr- Stepping- SERR- FastB2B-
>        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 32 (1250ns min, 250ns max)
>        Interrupt: pin A routed to IRQ 11
>        Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
>        Region 1: Memory at e0000000 (32-bit, prefetchable) [size=128M]
>        Region 2: Memory at dff80000 (32-bit, prefetchable) [size=512K]
>        Expansion ROM at 80000000 [disabled] [size=128K]
>        Capabilities: [60] Power Management version 2
>                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>        Capabilities: [44] AGP version 2.0
>                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- 
> HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
>                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
> Rate=<none>
> 
> no DRI/FB.
> 
> David
> 
> Pavel Machek wrote:
> 
> >Hi!
> >
> > 
> >
> >>My setup is:
> >>ASUS L3800C laptop, Radeon M7, i845 chipset, using DRI and radeonfb.
> >>
> >>Note that this is not specific to the kernel used, as I've been seeing 
> >>similar corruption every now and then, most recently under 2.6.7 +
> >>ACPICA20040715 + swsusp2.0.0.100 (S3, S4), but also under 2.4 with S1 
> >>(but not with S4/swsusp2).
> >>
> >>I have a very simple script I use to suspend (i.e. basically echo $arg >
> >>/proc/acpi/sleep), which is usually started by acpid. Once the script is
> >>triggered (by pressing power / sleep button) and an X session is running, 
> >>various red and green patches appear on the screen (the background image
> >>and the tinted terminal emulator), followed by the VT switch the PM code
> >>does. After resume and subsequent VT switch by the PM code the corruption
> >>is still visible. The screen is properly restored by a manual VT switch.
> >>The corruption is clearly related to the existing background pixmap, as
> >>moving the windows does not change its pattern. Oddly enough, starting a 
> >>GL
> >>app such as glxgears and moving it into and out of focus also properly
> >>restores the screen.
> >>   
> >>
> >
> >So what happens on 2.6.7 with swsusp1? Can you try vesafb (and fbdev
> >Xserver)?
> >
> >								Pavel
> > 
> >
> 
> 
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.

> begin:vcard
> fn:David Ford
> n:Ford;David
> email;internet:david@blue-labs.org
> title:Industrial Geek
> tel;home:Ask please
> tel;cell:(203) 650-3611
> x-mozilla-html:TRUE
> version:2.1
> end:vcard
>