[dapper] xrandr freezes the system (radeon, MergedFB)

[Marius Gedminas]

Three times today my laptop froze totally when I tried to use xrandr to switch from a dual-head mode back to single-head. The freeze was total -- even Alt+SysRq didn't work. The lockups are not 100% reproducible, but occur more often that is, how should I phrase it, convenient.

I've a Radeon Mobility 7500 in my T42 laptop. My xorg.conf is here: http://mg.pov.lt/xorg.conf.

This bug is somewhat similar to #37444, but the symptoms are different (total machine freeze vs. nothing happens when something should happen).

[goofyheadedpunk (goofyheadedpunk)]

I use the xorg-ati driver in my iBook G4. I just posted a similar bug report, number 47777, but did not know how to find any more information. The symptoms are the same, however.

[goofyheadedpunk (goofyheadedpunk)]

Hmm... on second thought the bug appears to be more wide-spread. I'm affected when using my system as single-headed as well, but more frequently.

[asabjorn (andreas-saebjoernsen)]

I can confirm that this bug is also apparent on my HP compaq nc6000 laptop with a ATI Mobility 9600 graphics card. The computer freezes when running the screensaver for a few minutes in random picking mode. Even ctrl+alt+backspace has no effect. This problem started on may 29th.

[Marius Gedminas (mgedmin)]

I had three more freezes (two yesterday, one today).

The first one occurred about 10 minutes after I used xrandr to switch to a dual-head config. I started doubting if xrandr/radeon driver was at fault here.

The second occurred when I used xrandr. This time I still had an external monitor connected, and I saw a bunch of colourful vertical lines there: http://mg.pov.lt/P6010010.JPG

The third freeze occurred this morning during login. When X starts up and I get a gdm screen, the server uses the largest available video mode (2380x1024), which is the dual-head one. When I actually log in, GNOME automatically switches to the single-head 1024x768 mode (I assume this is the work of gnome-display-properties/gnome-settings-daemon). The freeze occurred during this switch, and I saw another screen full of vertical coloured stripes.

Thankfully the freezes do not occur on each xrandr call, or I wouldn't be able to log in.

The freezes started very recently. I think I had one last week, but I was in a hurry and just rebooted the laptop without investigating, and then forgot about it.

I currently have xserver-xorg-driver-ati version 1:6.5.7.3-0ubuntu7. I do not have a deb of an older version, so I cannot downgrade and see if the problem goes away. On the other hand, this version was released on May 1 (according to the changelog), and I upgraded my Dapper daily during May, and I do not know why I only started having problems recently.

[Boris Strajnar (boris-strajnar)]

I must ad that not only the xrandr...every 3d aplication causes after a while freezing the desktop..my mouse still works but everything else is unresponsive. So if you play any 3d OpenGl game it will freeze...if your screensaver is 3d it will freeze after a while....about from 3d everythings works perfect and is as new as nice. I reinstalled the Dapper 3 times hanged on IRC for few days... nothing. Ok i found a "smart" solution on a net. You can disable the Load dri section and the problem is gone (freezing). And 3d acceptable speed also. So that is not a solution at all. Of course there are smart guys who will advise to install the fglrx driver...do i have to mention it is possible you will cry. On some system in just does not work again. Ok and if someone is interested...Celeron 2.2+Radeon 9000 pro 64mbram+512mb system ram...works perfect in debian i just change the hard disk. Although i must admit...there were some troubles to...before it started to work flawlessly. We all beg for solution....So please!

[Michael (auslands-kv)]

I was trying a new xorg.conf file I found on the net that utilizes a MergedFB
setup (http://mg.pov.lt/xorg.conf).

However, when switching through the metamodes the system always freezes
completely and without any chance to save any error log message (even SysRQ
don´t work).

The metamodes are "1024x768-1280x1024 1024x768-1024x768 10
24x768+1280x1024 1280x1024 1024x768 800x600 640x480".

If I am not mistaken, the freeze happens when switching to clone mode, that is
from "1024x768+1280x1024" to "1280x1024" (with ALT-CTRL-NUM+) or from
"1024x768-1280x1024" to "640x480" (with ALT-CTRL-NUM-).

Here is the xorg.conf:

Section "Files"
 FontPath "/usr/share/X11/fonts/misc"
## FontPath "/usr/share/X11/fonts/cyrillic"
 FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/75dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/Type1"
 FontPath "/usr/share/X11/fonts/CID"
 FontPath "/usr/share/X11/fonts/100dpi"
 FontPath "/usr/share/X11/fonts/75dpi"
        # paths to defoma fonts
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID"
EndSection

Section "Module"
 Load "GLcore"
 Load "bitmap"
 Load "ddc"
 Load "dri"
 Load "extmod"
 Load "freetype"
 Load "glx"
 Load "int10"
 Load "type1"
 Load "vbe"
EndSection

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
 Option "Emulate3Buttons" "true"
 Option "ZAxisMapping" "4 5"
EndSection

Section "Device"
 Identifier "MergedFB2 ATI Technologies, Inc. Radeon Mobility M6 LY"
 Driver "ati"
 BusID "PCI:1:0:0"
 Option "DynamicClocks" "on"
 Option "MergedFB" "true"
 Option "CRT2Position" "RightOf"
    # This allows X to use MergedFB if the external monitor is not connected
    # when I start X. The ranges are taken from DDC values of the CTX monitor
    # I use at the office; as listed in Xorg.log.
 Option "CRT2HSync" "30-81"
 Option "CRT2VRefresh" "56-76"
    # The next line lets me switch between dual-head and several clone modes
    # of varying resolutions with xrandr.
 Option "MetaModes" "1024x768-1280x1024 1024x768-1024x768 1024x768+1280x1024
1280x1024 1024x768 800x600 640x480"
    # A newer version of the radeon driver has an option that disables vertical
    # scrolling for the 1024x768 part.
 Option "MergedNonRectangular" "true"
    # In 1024x768-1280x1024 mode the DPI is correct (100), but in all other
    # modes it is weird. Try to override
 Option "MergedDPI" "100 100"
EndSection

Section "Device"
 Identifier "Screen0 ATI Technologies, Inc. Radeon Mobility M6 LY"
 Driver "ati"
 BusID "PCI:1:0:0"
 Option "DynamicClocks" "on"
 Screen 0
EndSection

Section "Device"
 Identifier "Screen1 ATI Technologies, Inc. Radeon Mobility M6 LY"
 Driver "ati"
 BusID "PCI:1:0:0"
 Option "DynamicClocks" "on"
 Screen 1
EndSection

Section "Monitor"
 Identifier "Generic Monitor"
 Option "DPMS"
EndSection

Section "Monitor"
 Identif...

[Johannes Hessellund (osos)]

Could you please post your xorg.conf?

I am having a T42 with radeon 7500, having troubles too. I just bought a port replicator and want to try this out. Dual head on DVI output posible yet?

[Marius Gedminas (mgedmin)]

Did the link to my xorg.conf that I included in the initial bug report not work for you? I'm uploading it here, just in case.

FWIW I use the internal LCD + analog VGA port. I understand that dual-head LCD + DVI was not supported by the radeon driver a while ago. I do not know if that has been fixed since.

[agd5f (agd5f)]

Does removing the dynamicclocks option help (make sure you power off the
computer after removing the option to make sure the clocks come up as the bios
programs them)?

[Michael (auslands-kv)]

Hi Alex,

I have tried it without the dynamicclocks option and also without the dri
modules, but I'm not sure that I restarted the computer.

Are you certain, that a restart is needed?

I did a test a few days ago. I started an X server with DynamicClocks enabled
and measured battery consumption. Then I exited the server and restarted it with
DynamicClocks disabled (The Xorg.0.log file stated, "DynamicClocks disabled".).
I again measured battery consumption and it seemed to be higher again, as should
be when dynamicclocks is off...

But I will try tomorrow with the posted xorg.conf file.

Cheers,

Michael

[Marius Gedminas (mgedmin)]

Confirming. X.org 7.0.0 often freezes my laptop (T42, Radeon Mobility 7500) if
I use MergedFB and switch from dual-head mode to clone mode. I use xrandr for
the switch rather than Ctrl+Alt+[+/-]. The freeze is solid -- even Alt+SysRq
doesn't work. When the machine is frozen, I see a strange picture on the
external monitor: http://mg.pov.lt/P6010010.JPG. Not every xrandr call causes a
lockup, but three or four tries are enough to reproduce the problem. Sometimes
xrandr succeeds, but the laptop lock up suddenly after 10-15 minutes when I'm
not doing anything in particular.

My xorg.conf is already linked from this bug report ;) I've used it in the past
with X.org 6.9 for quite a long time with no problems (well, with only minor
problems, no lockups).

I've also filed this bug in Ubuntu as https://launchpad.net/bugs/47775.

I'll try to disable DynamicClocks and see if it helps.

[agd5f (agd5f)]

(In reply to comment #2)
> Are you certain, that a restart is needed?
>
>

A full shutdown and boot up would be preferred. Enabling and disabling
dynamicclocks just enables and disables the bits in the approriate registers.
It doesn't save and restore those regs to how the bios set them up. if it is
causing problems you'll want to start up with a freshly initialized (by the
bios) chip.

[Marius Gedminas (mgedmin)]

I disabled DynamicClocks, turned the laptop off and back on, and started
clicking on my panel launchers that run xrandr. The system froze after a few
clicks.

[agd5f (agd5f)]

(In reply to comment #5)
> I disabled DynamicClocks, turned the laptop off and back on, and started
> clicking on my panel launchers that run xrandr. The system froze after a few
> clicks.

when you say disable, did you set the option to false or did you just remove the
line? if you set the option to false, try again, but just remove the
dynamicclocks line altogether.

[Michael (auslands-kv)]

O.K. so I have disabled DynamicClocks (by commenting out the line) and I have
experienced four freezes since then.

I had the feeling that it took a bit more switching between the modes until a
freeze occured (appr. 5 to 10 switches while with DynamicClocks it often
happened on the second or third switch), but this is probably not significant.

One time I saw a very very nice color pattern on the external monitor such as
mentioned in comment 3. The other times the external monitor just showed that
the video frequency has changed and is "out of range" now. So no picture.

I used "xrandr -s X" to switch between the modes as well as CTRL-ALT-Keypad+/- .
Both methods lead to freezes.

Hope this helps. Anything else I can test?

Michael

----------------------------------------
Two (more or less) relevant additions:

1.) I simplified the MetaModes to
 Option "MetaModes" "1024x768 1280x1024 1024x768+1280x1024"
as these are the options that I really need: 1024x768 clone mode, when working
on the laptop and maybe a beamer attached. 1280x1024 clone mode or
1024x768-1280x1024 when working on the docking station.

Strange I found, that
a.) X always started in 1280x1024 clone mode, however only showing 1024x768 on
both monitors (with a virtual screen of 1280x1024)
b.) xrand only gave me the possibility to switch between 1024x768 and 1280x1024
clone mode (which at least gave me the expected results), not the xinerama like
setup. All Windows were repositioned correctly.
c.) switching with CTRL-ALT-Keypad+/- switched through all three modes but in
the clone modes there was always a 1280x1024 virtual screen area. No windows
were repositioned (and the the KDE kicker did not adapt either)

2.) What I always hate with such freezes is that data is lost on the harddisk.
I'm using ext3 and in the boot process you first see the journal recovering with
lots of inodes deleted, then the fsck yielding lots of errors, trying to correct
them and then finally a reboot. Awful :(

I already tried remounting the disk read-only via ALT-SYSRQ-u before switching
resolutions (and freezing the system), but I got the same disk errors on the
next boot. I guess I should find a ram disk based test environment. If anybody
has an idea?

[Michael (auslands-kv)]

One more test: I disabled the dri module (as this leads to some system freezes
in other cases), but no change.

[Marius Gedminas (mgedmin)]

(In reply to comment #6)
> when you say disable, did you set the option to false or did you just remove
> the line?

I set the option to "off"

> if you set the option to false, try again, but just remove the
> dynamicclocks line altogether.

Michael tried that already (comment #7). I can also try if you wish.

[agd5f (agd5f)]

(In reply to comment #7)

>
>
> ----------------------------------------
> Two (more or less) relevant additions:
>
> 1.) I simplified the MetaModes to
> Option "MetaModes" "1024x768 1280x1024 1024x768+1280x1024"
> as these are the options that I really need: 1024x768 clone mode, when working
> on the laptop and maybe a beamer attached. 1280x1024 clone mode or
> 1024x768-1280x1024 when working on the docking station.
>
> Strange I found, that
> a.) X always started in 1280x1024 clone mode, however only showing 1024x768 on
> both monitors (with a virtual screen of 1280x1024)

This is because your first metamode is 1024x768. and the largest metamode is
1280x1024.

> b.) xrand only gave me the possibility to switch between 1024x768 and 1280x1024
> clone mode (which at least gave me the expected results), not the xinerama like
> setup. All Windows were repositioned correctly.

You didn't specify a dualhead metamode. 1024x768+1280x1024 is a clone mode.
1024x768-1280x1024 is a dualhead mode.

> c.) switching with CTRL-ALT-Keypad+/- switched through all three modes but in
> the clone modes there was always a 1280x1024 virtual screen area. No windows
> were repositioned (and the the KDE kicker did not adapt either)

only xrandr resizes the desktop. CTRL-ALT-Keypad+/- just changes the mode; the
desktop remains the same size.

>
> 2.) What I always hate with such freezes is that data is lost on the harddisk.
> I'm using ext3 and in the boot process you first see the journal recovering with
> lots of inodes deleted, then the fsck yielding lots of errors, trying to correct
> them and then finally a reboot. Awful :(

save your data and type 'sync' to flush to the HD before you try test something
likely to crash.

What version of the radeon driver are you using?

[Michael (auslands-kv)]

(In reply to comment #10)
> > Strange I found, that
> > a.) X always started in 1280x1024 clone mode, however only showing 1024x768 on
> > both monitors (with a virtual screen of 1280x1024)
>
> This is because your first metamode is 1024x768. and the largest metamode is
> 1280x1024.
>
Ähh, o.k. How can I start X then in 1024x768 clone mode without any virtual
screen. This would be my default setup. Only when I connect to the docking
station with the external monitor, I would like to switch to 1280x1024 clone
mode (with the virtual screen on the laptop LCD) or the dual-head-setup.

> > b.) xrand only gave me the possibility to switch between 1024x768 and 1280x1024
> > clone mode (which at least gave me the expected results), not the xinerama like
> > setup. All Windows were repositioned correctly.
>
> You didn't specify a dualhead metamode. 1024x768+1280x1024 is a clone mode.
> 1024x768-1280x1024 is a dualhead mode.
>

Oh, sh... Typo. I will correct that.

> > c.) switching with CTRL-ALT-Keypad+/- switched through all three modes but in
> > the clone modes there was always a 1280x1024 virtual screen area. No windows
> > were repositioned (and the the KDE kicker did not adapt either)
>
> only xrandr resizes the desktop. CTRL-ALT-Keypad+/- just changes the mode; the
> desktop remains the same size.
>

O.K. so one needs a combination of xrandr and the CTRL-ALT-Keypad in order to
switch between these three modes?

> >
> > 2.) What I always hate with such freezes is that data is lost on the harddisk.
> > I'm using ext3 and in the boot process you first see the journal recovering with
> > lots of inodes deleted, then the fsck yielding lots of errors, trying to correct
> > them and then finally a reboot. Awful :(
>
> save your data and type 'sync' to flush to the HD before you try test
something likely to crash.
>

I thought ALT-SYSRQ-S + ALT-SYSRQ-U should do (sync and remount ro). But that
did not work. Next time I try to issue "sync" and see what happens...

> What version of the radeon driver are you using?
>

6.5.8.0-1 from Debian unstable.

Xorg.0.log says:

(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 7.0.0, module version = 4.0.3
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 0.8
(II) LoadModule: "ati"
(II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
(II) Module ati: vendor="X.Org Foundation"
        compiled for 7.0.0, module version = 6.5.8
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 0.8

(II) ATI: ATI driver (version 6.5.8) for chipsets: ati, ativga

Does that help or do you need other info?

Michael

[agd5f (agd5f)]

(In reply to comment #11)
> (In reply to comment #10)
> > > Strange I found, that
> > > a.) X always started in 1280x1024 clone mode, however only showing 1024x768 on
> > > both monitors (with a virtual screen of 1280x1024)
> >
> > This is because your first metamode is 1024x768. and the largest metamode is
> > 1280x1024.
> >
> Ähh, o.k. How can I start X then in 1024x768 clone mode without any virtual
> screen. This would be my default setup. Only when I connect to the docking
> station with the external monitor, I would like to switch to 1280x1024 clone
> mode (with the virtual screen on the laptop LCD) or the dual-head-setup.

Unforunately that is a limitation of mergedfb, which is a big hack to begin
with. you'd either need to hack the driver to pre-reserve the additional
desktop space at the beginning or and xrandr -s 0 to your .xinitrc to resize the
desktop when you login. I think keithp is working on an improved version of
mergedfb that may address this.

>
> > > c.) switching with CTRL-ALT-Keypad+/- switched through all three modes but in
> > > the clone modes there was always a 1280x1024 virtual screen area. No windows
> > > were repositioned (and the the KDE kicker did not adapt either)
> >
> > only xrandr resizes the desktop. CTRL-ALT-Keypad+/- just changes the mode; the
> > desktop remains the same size.
> >
>
> O.K. so one needs a combination of xrandr and the CTRL-ALT-Keypad in order to
> switch between these three modes?
>

depending on what you want to do xrandr should be fine. CTRL-ALT-Keypad uses
the vidmode extension to change the mode. It came along before xrandr could
resize the desktop to match the mode.

> > >
> > > 2.) What I always hate with such freezes is that data is lost on the harddisk.
> > > I'm using ext3 and in the boot process you first see the journal
recovering with
> > > lots of inodes deleted, then the fsck yielding lots of errors, trying to
correct
> > > them and then finally a reboot. Awful :(
> >
> > save your data and type 'sync' to flush to the HD before you try test
> something likely to crash.
> >
>
> I thought ALT-SYSRQ-S + ALT-SYSRQ-U should do (sync and remount ro). But that
> did not work. Next time I try to issue "sync" and see what happens...

that won't work if your system is already locked solid ;) sync is a preemptive
method.

>
> > What version of the radeon driver are you using?
> >
>
> 6.5.8.0-1 from Debian unstable.
>
> Xorg.0.log says:
>
> (II) LoadModule: "radeon"
> (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
> (II) Module radeon: vendor="X.Org Foundation"
> compiled for 7.0.0, module version = 4.0.3
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 0.8
> (II) LoadModule: "ati"
> (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
> (II) Module ati: vendor="X.Org Foundation"
> compiled for 7.0.0, module version = 6.5.8
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 0.8
>
> (II) ATI: ATI driver (version 6.5.8) for chipsets: ati, ativga
>

That should be the most recent stable 7.0 release, IIRC.

[Michael (auslands-kv)]

(In reply to comment #12)
>
> Unforunately that is a limitation of mergedfb, which is a big hack to begin
> with. you'd either need to hack the driver to pre-reserve the additional
> desktop space at the beginning or and xrandr -s 0 to your .xinitrc to resize the
> desktop when you login. I think keithp is working on an improved version of
> mergedfb that may address this.
>

Well, o.k., this will certainly do. I'd be happy to use MergedFb at all. :)

> depending on what you want to do xrandr should be fine. CTRL-ALT-Keypad uses
> the vidmode extension to change the mode. It came along before xrandr could
> resize the desktop to match the mode.

I'll try again with my typo corrected. That is if we can get rid of the freezing
bug...

>
> That should be the most recent stable 7.0 release, IIRC.
>

O.K. What can I do to find the bug?

Cheers,

Michael

[agd5f (agd5f)]

(In reply to comment #13)

>
> O.K. What can I do to find the bug?
>

If possible, using ErrorF() or GDB, try and find out what function in the radeon
driver the crash is happening in.

[Michael (auslands-kv)]

O.K. I will do this. Will, however, take some time, as I have no idea how to do
this. :-/

Is there somewhere a tutorial about using ErrorF() or GDB which could function
as a start for me?

Thanks,

Michael

[agd5f (agd5f)]

(In reply to comment #15)
> O.K. I will do this. Will, however, take some time, as I have no idea how to do
> this. :-/
>

ErrorF() is easy. just add them to the source code when you want to print
something. so you might do something like:
in RADEONRestoreCrtc2()

ErrorF("RestoreCrtc2 called");
...
ErrorF("about to write crtc2 regs");
...
ErrorF("RestoreCrtc2 finished");

etc.

the messages will show up in your log. then you can look at your log and get an
idea of where the problem is.

> Is there somewhere a tutorial about using ErrorF() or GDB which could function
> as a start for me?

Using GDB with the X server:
http://wiki.x.org/wiki/DebuggingTheXserver

[Michael (auslands-kv)]

O.K. Thanks for the info.

I had a short look over it. I will try whatever I can, but I guess it will take
some time...

I'm not absolutely sure that I can come up with some results. Both methods seem
to have some hurdles that I might not overcome:

1.) errorF(): Necessary to understand the source code. I guess that's over my
capabilities. :(
But I will have a look at it (not even sure that I can sucessfully compile a
complete xserver. Might work with apt-src install easier though...). I guess I
need to find the code that gets executed when the modes are switched. uh, uh...

2.) GDB: A typical debugger it seems. However, if I am not mistaken, this
approach only works with crashed xservers, but not with a completely frozen
system. The relevant data is taken after the server gets a signal e.g. SIGSEGV.
But when the whole system is frozen, even a remote gdb session via ssh won't
work, will it?

[Michael (auslands-kv)]

So, I had a longer look at GDB. To my mind, this won't work, if I'm not
overlooking something.

What really might be a good idea, is to insert the errorF() calls in some
prominent funtions, just to identify, in what function the freeze happens.

With a reconfigured syslogd, one could broadcast the messages and log them on
another computer on the net, so that all messages are logged for sure and won't
get lost if there is no time left for a sync.

What would be necessary, would be some educated guess from the developers what
functions are good candidates, in which such errorF() calls should be inserted.
I have no chance to understand the code and to identify places where such calls
would make sense for this debug approach.

Would anyone who understands the code be interested in helping in this approach?

Cheers,

Michael

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #18)
>
> With a reconfigured syslogd, one could broadcast the messages and log them on
> another computer on the net, so that all messages are logged for sure and won't
> get lost if there is no time left for a sync.

As Roland pointed out in another bug, re-mounting the filesystem containing the
log file with -o sync should be easier and do the trick.

> What would be necessary, would be some educated guess from the developers what
> functions are good candidates, in which such errorF() calls should be inserted.

I'd start in RADEONSwitchMode().

[Michael (auslands-kv)]

(In reply to comment #19)
>
> I'd start in RADEONSwitchMode().

O.K. I'll see if I can find this, insert some meaningful errorF() messages and
get hopefully some sensible information back :-) (However, not this week, I'm
on business travel. Next week... )

Cheers,

Michael

[Michael (auslands-kv)]

Created an attachment (id=5994)
Xorg.log file of freeze

So, here are the first results. (I'm abroad at the moment, so I have limited
possibilities for testing here.)

Setup: The Radeon driver was modified with ErrorF() function calls as shown
here:

_X_EXPORT Bool RADEONSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
{
    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
    RADEONInfoPtr info = RADEONPTR(pScrn);
    Bool tilingOld = info->tilingEnabled;
    Bool ret;
#ifdef XF86DRI
    Bool CPStarted = info->CPStarted;

    if (CPStarted) {
 DRILock(pScrn->pScreen, 0);
 RADEONCP_STOP(pScrn, info);
    }
#endif

    RADEONTRACE(("RADEONSwitchMode() !n"));
    ErrorF ("RADEONSwitchMode entered\n");

    if (info->allowColorTiling) {
 if (info->MergedFB) {
     if ((((RADEONMergedDisplayModePtr)mode->Private)->CRT1->Flags &
  (V_DBLSCAN | V_INTERLACE)) ||
  (((RADEONMergedDisplayModePtr)mode->Private)->CRT2->Flags &
  (V_DBLSCAN | V_INTERLACE)))
  info->tilingEnabled = FALSE;
     else info->tilingEnabled = TRUE;
 }
 else {
     info->tilingEnabled = (mode->Flags & (V_DBLSCAN | V_INTERLACE)) ?
FALSE : TRUE;
 }
#ifdef XF86DRI
 if (info->directRenderingEnabled && (info->tilingEnabled != tilingOld))
{
     RADEONSAREAPrivPtr pSAREAPriv;
     drmRadeonSetParam radeonsetparam;
     memset(&radeonsetparam, 0, sizeof(drmRadeonSetParam));
     radeonsetparam.param = RADEON_SETPARAM_SWITCH_TILING;
     radeonsetparam.value = info->tilingEnabled ? 1 : 0;
     if (drmCommandWrite(info->drmFD, DRM_RADEON_SETPARAM,
  &radeonsetparam, sizeof(drmRadeonSetParam)) < 0)
  xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
      "[drm] failed changing tiling status\n");
     pSAREAPriv = DRIGetSAREAPrivate(pScrn->pScreen);
     info->tilingEnabled = pSAREAPriv->tiling_enabled ? TRUE : FALSE;
 }
#endif
    }
    ErrorF ("RADEON tiling finished\n");

    if (info->accelOn)
 RADEON_SYNC(info, pScrn);
    ErrorF ("RADEON_SYNC finished\n");

    if (info->FBDev) {
 RADEONSaveFBDevRegisters(pScrn, &info->ModeReg);

 ret = fbdevHWSwitchMode(scrnIndex, mode, flags);

 RADEONRestoreFBDevRegisters(pScrn, &info->ModeReg);
    } else {
 info->IsSwitching = TRUE;
 ret = RADEONModeInit(xf86Screens[scrnIndex], mode);
 info->IsSwitching = FALSE;
    }
 ErrorF ("RADEON info->FBdev finished\n");

    if (info->tilingEnabled != tilingOld) {
 /* need to redraw front buffer, I guess this can be considered a hack ?
*/
 xf86EnableDisableFBAccess(scrnIndex, FALSE);
 RADEONChangeSurfaces(pScrn);
 xf86EnableDisableFBAccess(scrnIndex, TRUE);
 /* xf86SetRootClip would do, but can't access that here */
    }
    ErrorF ("RADEON ENABLEDISABLE FB Access finished\n");

    if (info->accelOn) {
 RADEON_SYNC(info, pScrn);
 RADEONEngineRestore(pScrn);
    }
    ErrorF ("RADEON Engine Restore finished\n");

#ifdef XF86DRI
    if (CPStarted) {
 RADEONCP_START(pScrn, info);
 DRIUnlock(pScrn->pScreen);
    }
 ErrorF ("RADEON DRIUnlock finished\n");
#endif

    /* Since RandR (indirectly) uses SwitchMode(), we need to
     * update our Xinerama info here, too, in case of resizing
     */
    if(info->MergedFB) {
       RADEONUpdateXineramaScreenInfo(pScrn);
    }
 Erro...

[Michel-tungstengraphics (michel-tungstengraphics)]

I suspect the log writes may get buffered somewhere, so we're missing the last
ones. As for where to go from here, the best suggestion I can make is for
someone to do a git bisect, as someone on
https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/+bug/47775
claims this only started happening recently. Michael, you could try an older
version of xserver-xorg-video-ati first, e.g. from
http://snapshot.debian.net/archive/2006/05/03/debian/pool/main/x/xserver-xorg-video-ati/

PS: Please try not to clutter up your comments. Attaching a diff would be more
useful than pasting code, e.g. Also, it's not clear for someone who just reads
this bug how the 'lbreakout test' relates to this bug, and until we've confirmed
that other bug and this one are indeed one and the same, it's better not to mix
up comments between them.

[Michael (auslands-kv)]

Well, having read Marius' bug entry I actually thought that he meant with xorg
6.8.2 there were no problems, but now, after I have tried 6.5.7.3-3, I am happy
to say:

Yes, it is a regression! Works flawlessly with MergedFB -> In an extensive test
last night I did not manage to freeze the system at all.

And yes, bug #7251 seems to have the same cause.

[Michel-tungstengraphics (michel-tungstengraphics)]

*** Bug 7251 has been marked as a duplicate of this bug. ***

[Michel-tungstengraphics (michel-tungstengraphics)]

Would be really nice if someone could do a git bisect.

It's most likely related to Ben's memmap changes though - Ben, any other ideas
for tracking this down?

[Li Hu (xsd12)]

I experience the same problems, but I am not sure if it has something to do with multi-heading. Like one of the posters before also stated, my X freeze problems begun shortly before Dapper was released as final in the end of May 2006. Since this time I get occasional freezes at least one time a day. I have an Thinkpad X31 with a Mobility Radeon M6 and use the "radeon" driver with no multi-head set up .. Its extremly annoying and I would be happy if someone could provide an old xserver-xorg-ati package to solve that grave bug.

[Marius Gedminas (mgedmin)]

I stopped using xrandr (and bought an LCD monitor so I can use a dual-head layout at home as well as at work instead), but occasionally my laptop freezes. This happens most often after switching to a different workspace in metacity.

I would not be surprised to discover there are many bugs. One of them can be triggered by xrandr/mode switching and MergedFB, so let's keep this bug report focused on that one.

[RealMurphy (carsten-welcomes-you)]

I've got a similar problem on my T43p, also with a ATi mobility chip (FireGL M24 GL). Ironically, while typing this the first time, the machine locked up :(.

I don't think this is directly related to the x.org driver, since I experience the lock ups not only with radeon, but also with the ati and the fglrx driver. Also, this happens when just working with the system, not when switching to an external video output.

In about 80% of all freezes, I can still ssh into the system from another machine and see that the X server is running at 100% CPU all the time, not responding at all. Killing it with -6 works most of the time, i.e. X gets restarted and I can log in again, but sometimes the machine locks up completely after kill -6.

Sorry, that I don't have a solution handy, but I'd like to help, if someone can give me a hint how I can get some information out of the system, since I don't see *anything* in any /var/log/* file related to this.

[murmel (garkein)]

Same here with Thinkpad X31 (Radeon M6) and MergedFB (clone mode), 1280x1024
virtual desktop size, 1280x1024 resolution on CRT and 1024x768 res on LCD.

With xserver-xorg-video-ati 6.5.8.0-1 as of Debian xorg 7.0.22 I consistently
get random system freezes (even no SysRq anymore) and I even don't have to
switch modes to trigger it. Just use the system and after random time it freezes.

I already disabled DRI to sort that out.

With xserver-xorg-video-ati 6.5.7.3-3 as suggested above, it runs stable again
(thanks for that link!).

[Jacob Fricke (jacob-fricke)]

I had the same problem with an Thinkpad T30 (ATI Radeon Mobility 7500). I had no freezes after switching to the vesa drivers. Maybe this is a short-time solution for you.

[Saul Albert (saul-theps)]

Similar problem here using ati M6 card on a thinkpad x30.

System locks up totally after 10-40 minutes of use, no visible errors, only started when I upgraded to dapper-release (earlier releases of dapper were fine).

A solution to this one would be great!

I'll try downgrading to breezy again for now.

here's my xorg.conf

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
 FontPath "/usr/share/X11/fonts/misc"
 FontPath "/usr/share/X11/fonts/cyrillic"
 FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/75dpi/:unscaled"
 FontPath "/usr/share/X11/fonts/Type1"
 FontPath "/usr/share/X11/fonts/100dpi"
 FontPath "/usr/share/X11/fonts/75dpi"
 # path to defoma fonts
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
 Load "bitmap"
 Load "ddc"
 Load "dri"
 Load "extmod"
 Load "freetype"
 Load "glx"
 Load "int10"
 Load "type1"
 Load "vbe"
EndSection

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "gb"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ExplorerPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"
EndSection

Section "InputDevice"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 Option "SendCoreEvents" "true"
 Option "Device" "/dev/psaux"
 Option "Protocol" "auto-dev"
 Option "HorizScrollDelta" "0"
EndSection

Section "InputDevice"
  Driver "wacom"
  Identifier "stylus"
  Option "Device" "/dev/wacom" # Change to
                                                      # /dev/input/event
                                                      # for USB
  Option "Type" "stylus"
  Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "InputDevice"
  Driver "wacom"
  Identifier "eraser"
  Option "Device" "/dev/wacom" # Change to
                                                      # /dev/input/event
                                                      # for USB
  Option "Type" "eraser"
  Option "ForceDevice" "ISDV4" # Tablet PC ONLY
EndSection

Section "InputDevice"
  Driver "wacom"
  Identifier "cursor"
  Option "Device" "/dev/wacom" ...

[Marius Gedminas (mgedmin)]

Disabling DRI didn't help -- video mode switches frequently caused crashes with rainbow-filled screens.

I haven't tried to disable both DRI and MergedFB.

[sounddezign (andy-sounddezigns)]

Just some more info which might help in hunting down the problem:

Firstly, this problem is driving me absolutely crazy!! My laptop freezes so often, I'm loosing work and hair!!

System:
Compaq Evo N410c
1.2GHz P3 mobile
ati mobility radeon M6 LY (16MB)
512MB SDRAM
40GB HDD
NEC DVD-RW
Atheros AR5212 wifi with madwifi-ng drivers and wpa_supplicant

Running Ubuntu 6.06

It freezes very randomly. There seems to be no connection between the programs I'm running and when it freezes. The only solution is to hold the power button until the laptop powers off.

My system ran completely stable on breezy badger, but as soon as I upgraded to Dapper Drake it started freezing! Why is the cause of the problem not obvious to those that contributed to upgrading breezy to dapper??

It was freezing with the original xorg.conf file which I think was set to use ati driver. I have subsequently changed it to radeon drivers and tried using mergedfb with a secondary monitor connected. So mergedfb doesnt appear to be the problem.

I wish there were a higher level than "critical"

[sounddezign (andy-sounddezigns)]

I must add that it freezes with OR without the atheros card installed. So this does not seem to be the cause.

I don't think that heat is a problem. I have tried squirting Freezer spray into the fan inlets every couple minutes to keep it all nice and cool, but it still kept on freezing.

I'm going back to Breezy, which is a shame because Dapper is so much nicer to use. Let me know when this problem has been sorted out and I'll be back on Dapper.

[mmc (martin-campbell)]

yip i too had smooth runnings on breezy, however the problem didnt arise immediately for me in dapper [i've been running dapper since flight 5] ... i'm also reluctant to roll back to breezy at this stage, & I was hinting in one of my earlier posts if anyone had managed to roll back xorg in dapper to a version that didnt have this issue?

sounddezign - before rolling back you should trying 'disabiling' MergedFB as i found my system to be a LOT more stable with it disabled (your last post implied that you had 'enabled' it), that said i've just had a lock up [this is my second attempt to write this post ;) ]

i also found some people saying to drop to 16bit colour but i dont believe this to make any real difference.

if anything i'd be tempted to push on into edgy rather than roll back ... but thats just my $0.02

-mmc

[Binh Trinh (beango)]

I've found a solution for the ATI lockups...
Hopefully, you guys will be able to independently confirm it.

I've got a Dell with ATI M6 running edgy with xserver-xorg-video-ati 6.6.2-0ubuntu1. The stock xorg.conf causes fast frequent random lockups at 24 bpp and somehow less frequent random lockups at 16bpp.

I don't know how, but inserting these lines (all or some of them) to the stock xorg.conf solves the freezes (in Section "Device"):
Option "DynamicClocks" "true"
Option "AccelMethod" "EXA"
Option "DMAForXv" "off"
Option "SubPixelOrder" "None"
Option "BusType" "AGP"

My hunch tells me that the important line is either the DynamicClocks or the AccelMethod.

Note: I have no idea of stability in 3D. But in 2D, it is quite stable (uptime 2+ days now); and much faster than Option "NoAccel" or Driver "vesa".

Please try and spread the word.

beango

[Airlied-freedesktop (airlied-freedesktop)]

can you try xf86-video-ati git head for this?

[Michael (auslands-kv)]

Dave,

this looks VERY promising! I don't know what you have done (there are quite a
lot of changes in git after 6.6.2), but whatever it was, it seems to be exactly
what was needed!!

So far no freezes using MergedFB on a Radeon M6 (IBM Thinkpad X31), and I have
tried quite a lot of resolution changes!

Now,..., next step will be to get the KDE guys to eliminate some annoying bugs
on the desktop when MergedFB is enabled :-D ;-)

Greeting from Switzerland

Michael

[2hansen (bo2hansen)]

I am on Dapper, and have tried changing the first of my device sections to include the changes suggested by Bin Trihn - but since I have experienced two system freezes.

So in my case the suggestion did not solve the case.

[siriusnova (siriusnova)]

I have to add to this, however i dont know if its related but it seems to be the same problem..

I am running Ubuntu Dapper on an IBM Thinkpad T30 with an ATI Radeon 7500 Mobility
I am using the X.org "ati" driver..

I can very rarely go more then 2 hours without a total system freeze, no input, complete lock up of the system and the only option i have left is to literally hit the power button.

It happens in X regardless of what i am doing, but it only happens when X.org is running ie everything is fine if kill X and just run a console.

i tried the above suggestion
Option "DynamicClocks" "true"
Option "AccelMethod" "EXA"
Option "DMAForXv" "off"
Option "SubPixelOrder" "None"
Option "BusType" "AGP"
etc...

but it doesnt seem to change anything, help us, Dapper is unusable on my laptop without a fix for this.

[mmc (martin-campbell)]

siriusnova, have to tried disabling the MergedFB & dropping the colour depth to 16bit?

it hasnt completey solved the problem but does seem to change the lockups from every two hours to more like once every two weeks, which at least has made my system useable. i too have tried all the hints and tips on this thread (and even removed all modules from xorg) still to no avail .... the lockups still occur :(

let me know if anyone finds a real solution.

ta
mmc

[2hansen (bo2hansen)]

Just a short comment that might be useful in the tracing process.

In 9 of 10 cases the freeze occurs while starting "Evince" (opening one or more PDF-files).

I have not experienced this PDF-freeze in single monitor-mode, only in dual.

B:)

[Michael (auslands-kv)]

I'm not sure if I can/should change the bug status, but I try to put it to
"Resolved" and "Fixed"

Cheers,

Michael

[Marius Gedminas (mgedmin)]

I'd like to test xf86-video-ati git head too. Could someone gently point me to
the relevant documentation for building it, as I can't seem to get past
autogen.sh? Also, can I build just the driver, or do I need to build the whole
server? I currently use X.org 7.0.0 from Ubuntu Dapper.

[Michael (auslands-kv)]

Hi Marius,

I haven't found much documentation. Everything I know is basically described by
Michel in comment 29.

This only builds the ati driver. After the build you find the driver files
somewhere in src/.libs/ . So, it's a hidden directory. The files are all named
*.so like ati_drv.so .

I searched for them in my root dir, found them in /lib/xorg/drivers/modules and
simply exchange them with the newly build ones.

If you are having problems with autogen, look if you have all the corresponding
packages (I think they are called autoconf and automake (automake1.7 if I
remember correctly). And you need all the relevant xorg dev packages.

It takes some time to set this up. If you don't like to install all these
packages on your system (e.g. because it's a production system like mine), then
you can also set up a virtual machine with vmware and use this as a build system
(this is what I do).

Hope this helps a bit.

Cheers,

Michael

[Denes Kiss (kiss-denes)]

No freeze with Kubuntu 6.06.
I have Comnaq Evo160 laptop, ATI Radeon Mobility card.
It was rock solid with Ubuntu 5.10, but freezes randomly with U6.06. I tried everything, but no result.
It has been working with Kubuntu 6.06 for weeks without hang up. Everithing is the same, but KDE! Interesting. I do not see any changes in the configuration.
KD

[2hansen (bo2hansen)]

Sorry for asking a stupid question, but accordingly to https://bugs.freedesktop.org/show_bug.cgi?id=7154 this bug is now fixed.

When should I then expect to have my update manager pop up and install a new version?

[siriusnova (siriusnova)]

I can confirm this also happens in Edgy Eft Beta..

I just installed Edgy Eft onto my Thinkpad T-30 with an ATI Radeon 7500 Mobility.

All i did was an aptitude update and aptitude dist-upgrade

after updating within 10 minutes the system locked up..

hopefully the fix will be in the new patches? when can we expect it to show up in the package manager

[Marius Gedminas (mgedmin)]

Denes: it is entirely possible that Qt excercises different parts of the driver than Gtk+ does, and therefore the chance of crashes may be different.

It is also true that the crashes are very irregular: sometimes I get three crashes in one day, sometimes I get two consecutive crash-free weeks, without any changes in the configuration.

[Marius Gedminas (mgedmin)]

I tried to compile the upstream git head version of xf86-video-ati on Dapper, but gave up after several hours of fighting automake/aclocal.

I'll try to build it on edgy and see if it fixes the crashes for me. Maybe first I'll wait until edgy's X actually crashes.

[2hansen (bo2hansen)]

Freezes occur *very* often in Edgy. Of course this might be caused by many other things, but only when in dual display mode - I have not experienced any freezes with just a single display.

[Marius Gedminas (mgedmin)]

Yay! It looks like xserver-xorg-video-ati 1:6.6.2-0ubuntu3 fixed the problem:

  * Fix radeon aperture size check that was causing hangs and crashes on
    RN50, M6, M7 with 8/16/32(??) MBs of VRAM:
    - 08_radeon_fix_aperture_size_check.diff

  Thanks to Ben H., Dave Airlied and Michel Danzer for their constant support.

 -- Fabio M. Di Nitto <email address hidden> Tue, 03 Oct 2006 09:11:47 +0200

My xrandr stress test (toggling between dual-head and clone modes many times in a row) failed to cause a freeze.

[Hezekiah Carty (hez)]

Is there anything special required for a user to do a manual backport of this to Dapper? Edgy still seems to have a large number of problems on my system, so I'm sticking with Dapper for the time being.

[mmc (martin-campbell)]

hezekiah, it looks like 'xserver-xorg-video-ati 1:6.6.2-0ubuntu3' marius references is actually a later release that what is default in dapper ... certainly my dapper shows i have version: 6.5.7.3-0ubuntu7 (unless mine is out of sync .... ) i dont think the package numbering is designed to reflect the version'ing (7.0) of xorg ;)

marius, i too would appreciate a kick in the right direction to get 'server-xorg-video-ati 1:6.6.2-0ubuntu3' installed, have you just dpkg'd it?

?

ta
mmc

[Marius Gedminas (mgedmin)]

Sorry for being unclear. I upgraded to Edgy.

[Hezekiah Carty (hez)]

My apologies - I understand the Dapper vs Edgy versioning situation. I'm using a 6.6.1 deb from another Radeon bug here on Dapper to fix the Cairo/Ubuntulooks theme rendering problems in the original Dapper drivers. I would just apt-get source and dpkg-buildpackage this new driver release, but the package says it needs newer libraries than are available in Dapper so I'm curious to know which of these dependencies can be ignored and which need further attention.

From what was said in the other bug (I apologize, I don't remember the bug number) the new driver may end up in Dapper's backports archive. I'm just looking for a fix until that time.

[mmc (martin-campbell)]

ahh - sorry i should have checked to see what packages edgy was running, thanks for the nudge!

of to edgy we go ....

-mmc

[Jonas August (jonas-m-august)]

This bug does not appear in the list of ~80 current bugs for Dapper on https://launchpad.net/distros/ubuntu/dapper/+bugs (or the next page). But I believe this is a current Dapper bug, and so anyone wanting to know the status of Dapper should see it. Strangely, when I type 47775 in the search field on that page, I get the page for this bug, i.e., the search doesn't limit itself to the list of ~80 current Dapper bugs. My guess is that this bug should still be listed on https://launchpad.net/distros/ubuntu/dapper/+bugs, and hopefully quite high (just below bug #1) on the list so that the upstream patch gets incorporated into Dapper. If I understand correctly, this is the only other "confirmed critical" bug on Dapper.

Thanks.

PS: I have been bitten by this bug on a Thinkpad A31p with ATI FireGL 7800 (which is similar to a Radeon 7500 mobility). I'm currently using gentoo (with much maintenance fatigue) and this bug is the only barrier to my switching to Dapper.

[Denes Kiss (kiss-denes)]

Marius: You were right. After a week I got a freeze with Kubuntu6.06 too. (With U6.06 I got freezes in every hour.)
But now I run fine for a week with U6.10. I hope it will keep on.

[eze80 (ezequiel-pozzo)]

Hello.. I wonder if this is related to bug number #67225? I found it recently and it's giving me lots of trouble.

I don't know how to solve it... can you help me?

I'm running the latest updates of kubuntu dapper with an nv 6800gt using the proprietary nv drivers.

One thing is that I had to install gdm to make the multiseat boot. Could this problem be gdm related? In my bug report I included some weird gdm logs just after the freeze.

Thank you

[Marius Gedminas (mgedmin)]

eze80: I'm pretty sure it is unrelated. This bug in the open-source Radeon driver has now been fixed in Edgy. I think your problem is caused by some bug in the closed-source Nvidia driver.

[Lou Ruppert (louferd)]

If the bug is fixed in Edgy, how long until we'll see it backported to Dapper? Lets put the LTS to the test. :)

Meanwhile, is it possible to selectively use Edgy's xserver-xorg package (and drivers) without upgrading to Edgy? I have about ten machines to support for one client, and would prefer to only support the one OS version.

[Denes Kiss (kiss-denes)]

Lou: I moved to Edgy and I have had no freeze any longer. Edgy is great. With dapper server I had problems with the cups too.
Denes

[DominikBodi (dominik-bodi)]

seems to be fixed in edgy.

[Eli Criffield (launchpad-zendo)]

Any answers on when this is going to be fixed in dapper. I'm also getting random total lockups, sometimes once a week sometimes 4 times a day.
(IBM T42 laptop with radeon 7500)

Seems silly that its not fixed in dapper, dapper is suppost to be the Long Term Supported Stable versioin right?

Eli

[DominikBodi (dominik-bodi)]

the upstream bug report has a patch attached to it. Perhaps that patch could easily applied to the driver in dapper.

[Eli Criffield (launchpad-zendo)]

I made a new package with the patch installed, (everything else is the same as the previous package) so until an official new package comes out, you can use the one i made, and live without the crashs.

wget http://eli.criffield.net/ubuntu/xserver-xorg-driver-ati_6.5.7.3-0ubuntu8_i386.deb
sudo dpkg -i xserver-xorg-driver-ati_6.5.7.3-0ubuntu8_i386.deb

Eli Criffield

[DominikBodi (dominik-bodi)]

Excellent, could you please attach that patch to this bug report?

[Eli Criffield (launchpad-zendo)]

I got the patch from this bug report, just fallow the link to the freedesktop-bugs 7154 and the patch is there somewhere.

I'll attach it here too.

Eli Criffield

[DominikBodi (dominik-bodi)]

bug in malone?

[DominikBodi (dominik-bodi)]

ooops, that comment got cut off a wee bit. I wanted to clean up the status fields for all the packages referred to in this bug report. It seems malone did not like to have the same package referred to twice in the same bug report. That's why I changed one instance of package "xorg" to refer to no package at all and mark the bug as rejected for that instance.

As the original problem seems to have been fixed in edgy, the backport to dapper is the only open issue remaining now.