Bug 545993

I can confirm this bug as described above. It is reproducable after every install of 11.2 RC1 on IBM T60 with ATI X1300 - "sax2 -r" repairs the lagging KDE4/Xorg.


01:00.0 VGA compatible controller: ATI Technologies Inc M52 [Mobility Radeon X1300] (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 2005                                                                            
        Flags: bus master, fast devsel, latency 0, IRQ 16                                                        
        Memory at d8000000 (32-bit, prefetchable) [size=128M]                                                    
        I/O ports at 2000 [size=256]                                                                             
        Memory at ee100000 (32-bit, non-prefetchable) [size=64K]                                                 
        [virtual] Expansion ROM at ee120000 [disabled] [size=128K]                                               
        Capabilities: [50] Power Management version 2                                                            
        Capabilities: [58] Express Legacy Endpoint, MSI 00                                                       
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-


Afterwards radeonhd produces corrupt display when enabling KWIN effects - I'll file another bug for this

This is weird. Please attach /var/log/Xorg.0.log with *no* xorg.conf in place.

Created attachment 323076 [details]
Xorg.conf when starting X without xorg.conf

This appears to be the issue.

(EE) RADEONHD(0): FB: Failed allocating DRI Depth Buffer (25600 KB)
(EE) RADEONHD(0): DRI: Failed allocating buffers, disabling

Not enough memory reserved for DRI when using our automatic 'Virtual' mechanism.

I mean this one

-------------------------------------------------------------------
Fri Sep 11 15:37:16 CEST 2009 - mhopf@novell.com

- bug519261-increase-virtual.diff:
  * Increase virtual on startup if enough Gfx RAM is available.

but the patch has disappeared from our package !?!

Oops. It's committed upstream meanwhile.

commit be7216fca954396d92b94335ccb18d22c354c195
Author: Matthias Hopf <mhopf@suse.de>
Date:   Wed Sep 30 15:46:46 2009 +0200

    randr: Select virtual large enough for typical dual-monitor situations
    
    Unless we're able to shrink/enlarge FB on the fly (TTM etc.), allocate
    large enough (TM) virtual size for general use cases.

Have to verify...
Setting to minor because we have a workaround (setting virtual).

Reassigning during vacation.

> (--) RADEONHD(0): VideoRAM: 65536 kByte
> [...]
> (II) RADEONHD(0): Using 2560x2560 Framebuffer with 2560 pitch

This is more than 1680*2*1280 from the 'Virtual' magic patch.

I bet this is unrelated to the introduction of the virtual magic.

I believe it makes more sense to reassign this one to Egbert.

I don't see where this virtual size is coming from right off hand, either.
Jürgen, can you run 'X -logverbose 7' on the command line - without a config file and attach the resulting log file, please? Maybe this helps sheding some light on this.

Created attachment 326349 [details]
Stdout and Stderr

Created attachment 326350 [details]
/var/log/Xorg.0.log

/var/log/Xorg.0.log

@Egbert - of course. I removed xdm and earlyxdm from runlevel - restarted without /etc/X11/xorg.conf and started "X -logverbose 7"

I did not get a running X - Display went black. But I was able to switch back to TTY1, so I guess X did not crash. Btw - startx worked. 

Please find attached 2 files - the first one is from /var/log, the second on from stdout and stderr when starting "X -logverbose 7"

> I did not get a running X - Display went black. But I was able to switch back
> to TTY1, so I guess X did not crash. Btw - startx worked. 

That's fine. Nowadays you need to add the option "-retro" to see the usual X pattern.

Here we are?

(II) RADEONHD(0): RHDSynthModes: Adding Modeline Modeline "2560x1600Scaled"  270.75  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync
(II) RADEONHD(0): RHDSynthModes: Adding Modeline Modeline "2560x2048Scaled"  346.50  2560 2608 2640 2720  2048 2051 2058 2107 +hsync -vsync
[...]
Modeline "2560x1600Scaled"  270.75  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync
Modeline "2560x2048Scaled"  346.50  2560 2608 2640 2720  2048 2051 2058 2107 +hsync -vsync
[...]
Modeline "2560x1600Scaled"  270.75  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync
Modeline "2560x2048Scaled"  346.50  2560 2608 2640 2720  2048 2051 2058 2107 +hsync -vsync
[...]
(II) RADEONHD(0): Using 2560x2560 Framebuffer with 2560 pitch

commit a3b6e284aefaa05e421304c28f7c30c079a3a4fa
Author: Egbert Eich <eich@freedesktop.org>
Date:   Tue Apr 29 17:55:27 2008 +0200

    Add syntesized CVT modes to mode list for scaling.
    
    For RandR we need to synthesize modes for scaling as there is no way
    to obtain the full mode pool.
    We take a list of well known display resolutions and generate CVT
    mode lines from them. This is mainly done so that those modes can
    pass validation as we only need HDisplay and VDisplay from these.

Ah, yes. I forgot about that. I need to find a way to cap this list somehow.

Still the same issue with openSUSE 11.3 (add boot option 'nomodeset')? What are the results on 11.3 with radeon driver instead (without boot option 'nomodeset').

Still waiting for a response for four weeks now. Please reopen once you can provide the requested feedback. Thanks.