[M6 LY] System lockup when switching VT's or Resume from Suspend

[mungewell]

Gutsy Xubuntu Beta running on Thinkpad X22 with 256MByte RAM. Compositor disabled.

I can change to a text terminal (VT1 through 6), but when I attempt to change back to X session (VT7) screen goes blank and the machine is unresponsive.

I can't change back to text term, caps-lock doesn't light LED and thinkpad light does not operate. Only option is to reboot.

Am using the ATI Radeon X driver, will attach xorg.log
---
simon@bourne:~$ dpkg --list | grep xserver | grep ati
ii xserver-xorg-video-ati 1:6.7.194-1ubuntu1 X.Org X server -- ATI display driver
---
Simon.

[mungewell (simon-mungewell)]

Lock up does not occur with Vesa driver.

---
simon@bourne:~$ xrandr --verbose -q -d :0
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
VGA-0 disconnected (normal left inverted right)
        Identifier: 0x44
        Timestamp: 1684606022
        Subpixel: no subpixels
        Clones:
        CRTCs: 0 1
        load_detection: 1 (0x00000001) range: (0,1)
LVDS connected 1024x768+0+0 (0x46) normal (normal left inverted right) 0mm x 0mm
        Identifier: 0x45
        Timestamp: 1684606022
        Subpixel: horizontal rgb
        Clones:
        CRTC: 0
        CRTCs: 0
                scaler: full
        backlight: 255 (0x000000ff) range: (0,255)
  1024x768 (0x46) 65.0MHz
        h: width 1024 start 1040 end 1176 total 1344 skew 0 clock 48.4KHz
        v: height 768 start 770 end 776 total 806 clock 60.0Hz
  1024x768 (0x47) 65.0MHz -HSync -VSync
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
        v: height 768 start 771 end 777 total 806 clock 60.0Hz
  800x600 (0x48) 40.0MHz +HSync +VSync
        h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz
        v: height 600 start 601 end 605 total 628 clock 60.3Hz
  640x480 (0x49) 25.2MHz -HSync -VSync
        h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz
        v: height 480 start 490 end 492 total 525 clock 59.9Hz
---

[mungewell (simon-mungewell)]

Looking at /var/log/Xorg.0.log.old there are a few more lines added to the log when the switch from X->Text is made. No further logs are made when the Text->X switch is attempted.

---
(II) RADEON(0): Printing probed modes for output LVDS
(II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1040 1176 1344 768 770 776 806 (48.4 kHz)
(II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
disable montype: 2
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
finished PLL2
Entering Restore TV
Restore TV PLL
Restore TVHV
Restore TV Restarts
Restore Timing Tables
Restore TV standard
Leaving Restore TV
---

The laptop does not have a TV/SuperVideo output.
Simon.

[mungewell (simon-mungewell)]

I have also noted that this bug is/may be the reason I can not resume after a suspend, which currently results in the laptop hung/crashed.

If I change the X driver to Vesa I can suspend/resume without issue.
Simon

[Tormod Volden (tormodvolden)]

Thanks for your bug report and the attached information. Can you please try the -tv6 package from https://wiki.ubuntu.com/XorgOnTheEdge ?

[mungewell (simon-mungewell)]

Unfortunately this later revision of the ati xserver does not appear to fix the problem :-(

The laptop is OK doing X->Text switch, but on Text->X experiences a complete 'lock up'.
---
simon@bourne:~$ dpkg --list | grep xserver | grep ati
ii xserver-xorg-video-ati 1:6.7.194-1ubuntu1tv6 X.Org X server -- ATI display driver
---

I have also attached the /var/log/Xorg.0.log.old. The TV stuff at the end is added after the X->Text switch, no other logs when Text->X.

Cheers,
Simon.

[Tormod Volden (tormodvolden)]

Can you first try:
 Option "BusType" "PCI"
in the Device section of xorg.conf, and if that doesn't help, try to disable DRI:
 Option "DRI" "off"

[Tormod Volden (tormodvolden)]

Bug #127101 has a similar issue, but with Intel cards.

[mungewell (simon-mungewell)]

Nope.... no joy, still crashes with Bus=PCI and/or DRI=off

xorg.conf extract.
---
Section "Device"
        Identifier "ATI Technologies Inc Radeon Mobility M6 LY"
# Driver "vesa"
        Driver "ati"
        BusID "PCI:1:0:0"
        Option "BusType" "PCI"
        Option "DRI" "off"
EndSection
---

lspci extract
---
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])
        Subsystem: IBM ThinkPad X22/X23/X24
        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: 66 (2000ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at 3000 [size=256]
        Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=48 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>
        Capabilities: [50] 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-
---

---
simon@bourne:~$ dpkg --list | grep xserver | grep core
ii xserver-xorg-core 2:1.3.0.0.dfsg-12ubuntu8 X.Org X server -- core server
---

I'm not convinced that the intel bug is the same issue. My bug happens *everytime* on VT switch back to X, and occurs when resuming from supsend.

Thanks for the help,
Simon.

[David Douard (david-douard)]

hi,

just to tell I the same problem here, on my ThinkPad X24 (Radeon Mobility M6 LY). I tried lated driver from XorgOnTheEdge (namely xserver-xorg-video-ati_6.7.195+git20071020tv_i386), I disabled every DRI, acceleration, etc. Always the same complete lockup when going back to X (from VT).
When X is loaded, I can kill it, I can start another X on vt8 (but I can't go back to the first X (vt7) either).

(The side effect of not being able to suspend my laptop any more is really a pain :-(

[fruehrentner (fruehrentner)]

Hi!

I've got exactly the same Problem here with my Compaq Evo N160 also featuring Radeon Mobility M6 LY (aka. Radeon Mobility 9000). Everything worked fine on Feisty.

I've also tried every imaginable Option in the xorg.conf. No Luck (Everything works fine though when I switch to VESA ... but that's a bit too basic for me ;o)

The machine locks up with a black-screen when I:

- Switch back from console view (CTRL+ALT+F7)
- Resume from hibernation (In fact the machine boots up, but just before it's about to show GNOME's login screen it locks up)

I read here (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/141533) at the launchpad, that reverting the xserver-xorg-video-ati driver to version 6.7.193 fixed the problem for some people.

I'm going to give it a try and I'll post my results here.

[fruehrentner (fruehrentner)]

I tried http://tormod.freeshell.org/linux/ati/xserver-xorg-video-ati_6.7.194-1ubuntu1tv6_i386.deb but with the same results ... seems to be a problem direcly connected to the M6 LY

[fruehrentner (fruehrentner)]

I Assigned this bug to Timo Aaltonen. He fixed some problems with the driver recentliy, and I'm sure that he can help us, too.

[Tormod Volden (tormodvolden)]

> version 6.7.193 fixed the problem for some people

> 6.7.194-1ubuntu1tv6_i386.deb but with the same results

The latter is closer to 6.7.195 than it is to 6.7.193. You can find older versions in launchpad, for instance 6.6.3.

BTW, please do not assign bugs to people (unless they have asked you to). Timo does what he can.

[daschmidty (david-p-schmidt)]

I can also confirm this bug on a thinkpad x24 and reverting to previous versions of the driver (6.7.193 and 6.6.3) seemed to have no effect.

[David Douard (david-douard)]

Using Ubuntu on a IBM Thinkpad X24, since I upgraded to Gutsy, I can't switch back to X11 from VT any more: it completely freeze the computer (does not even answer to ping anymore, cannot sysrq, etc.), thus, I can't suspend any more (which is the *big* drawback for me).

I tried quite recent git builds (packages from http://ppa.launchpad.net/tormodvolden/ubuntu/pool/main/x/xserver-xorg-video-ati/ thus corresponding to driver "version" 6.7.197+git20080108.fa3e2055 ) with no luck.
I also tried many xorg.conf tweaks (disabled almost everything).

Note there is a bug report on Ubuntu launchpad tracker:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/148408

[agd5f (agd5f)]

Please attach your xorg log and config.

[Gergely-tomka (gergely-tomka)]

Created an attachment (id=13668)
xorg.conf from a thinkpad x24

[Gergely-tomka (gergely-tomka)]

Created an attachment (id=13669)
Xorg.log, the machine crashed

[Gergely-tomka (gergely-tomka)]

Created an attachment (id=13670)
Xorg log, the system not crashed, straced.

[Gergely-tomka (gergely-tomka)]

Hi, i have this issue also. Attached conf and logs.

With the debian experimental driver (git 20080109), and when using strace over a serial link, the switch back from console to X is not crash the computer. Without strace, it crashes.

I am attaching two strace outputs, one with the sid driver, with a crash, and one with the experimental driver, without crash.

[Gergely-tomka (gergely-tomka)]

Created an attachment (id=13671)
strace output, sid driver, crash

[Gergely-tomka (gergely-tomka)]

Created an attachment (id=13672)
strace output, experimental driver, no crash

[agd5f (agd5f)]

Do any of the following options help:

Option "AGPMode" "4"
Option "DRI" "false"
Option "BusType" "PCI"

[Gergely-tomka (gergely-tomka)]

No, these options wont help. My poor ext3...

In the Debian bug system i found a similar problem, on a slower cpu, when the slowing down of the X helped. Now, when tried DRI no option, i mounted the / with the sync option. This visibly slowed down the workings of the system, and once there was no crash. But i can't replicate this.

And there was another solution.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435040

[agd5f (agd5f)]

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

[Rolf Leggewie (r0lf)]

also have this problem on my Thinkpad X24. This did not happen before I upgraded to gutsy. Feisty was still fine. Removing xorg.conf and restarting X is no solution either. So, it is not a configuration issue.

[R.Rublack (salatessen)]

hi

I also got the suspend (S3) problem on X24 running Ubuntu 7.10 with
kernel 2.6.22-14-generic #1 SMP
xorg 1:7.2-5ubuntu13
xserver-xorg-video-ati 1:6.6.3-2ubuntu6

with newer xserver-xorg-video-ati from gusty got the same freeze on switch to VT,
but also on S3 coming back the system freeze no information in syslog or Xorg.0.log

[R.Rublack (salatessen)]

hi since my last comment I tried some changes in /etc/default/acpi-support
and now I'm able to coming back from S3. I tried it twice 1 going to sleep and moving to an other place
in this case suspend for more than 30 min and second shortly wakeup again after suspend.
The packages are shown in the last comment.

xorg.conf

Section "Device"
        Driver "radeon"
        VendorName "ATI"
        BoardName "ATI Radeon Mobility M6"
        Option "AccelMethod" "XAA"
        Option "AGPMode" "1"
        Option "AGPFastWrite" "1"
        Option "EnablePageFlip" "1"
        Option "ColorTiling" "1"
        Option "DisableGLXRootClipping" "true"
        Option "AddARGBGLXVisuals" "true"
        Option "AllowGLXWithComposite" "true"
EndSection
Section "Module"
    Load "dbe"
    Load "extmod"
    Load "fbdevhw"
    Load "glx"
    Load "record"
    Load "freetype"
    Load "type1"
    Load "dri"
EndSection

and
/etc/default/acpi-support

ACPI_SLEEP=true
ACPI_HIBERNATE=true
ACPI_SLEEP_MODE=mem
MODULES=""
MODULES_WHITELIST=""
SAVE_VBE_STATE=true
VBESTATE=/var/lib/acpi-support/vbestate
POST_VIDEO=true
# SAVE_VIDEO_PCI_STATE=true
USE_DPMS=false
 RADEON_LIGHT=true
#DOUBLE_CONSOLE_SWITCH=true
HIBERNATE_MODE=platform
LOCK_SCREEN=true
# DISABLE_DMA=true
# RESET_DRIVE=true
STOP_SERVICES=""
RESTART_IRDA=false
ENABLE_LAPTOP_MODE=false
SPINDOWN_TIME=12

[Rolf Leggewie (r0lf)]

Thanks a million for your tests and comment, R.Ruback. This is one the most annoying bugs for me currently. Looking for differences between your and my setup. I found in /etc/default/acpi-support

USE_DPMS=true
HIBERNATE_MODE=shutdown

and

RADEON_LIGHT=true (commented out on my machine)

I believe I have never touched this file, so that should be what is shipped. AFAIK, xorg.conf is not needed anymore for recent xorg. Can you try with an empty xorg.conf or move it out of the way? I will also try and do some tests with your changes and report back.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

Downgrading to xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb fixed this for me.

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/148408/comments/27

[Tormod Volden (tormodvolden)]

Please notice that R. Ruback's xorg.conf has some "dangerous" settings. AGPFastWrite makes many cards crash, and I will not recommend turning it on.

[R.Rublack (salatessen)]

at Tormod Volden
thx for our advise, on the journey to find a solution to this S3 problem I put it in because of same reading in thinkwiki.
at Rolf Leggewie
I tried a short test run without xorg.conf bz moving it out of the way.
the laptop also come back to X without problems.
but additional I need the xorg.conf because of some keyboard and trackpoint settings

I attach the xorg.0.log file from this test

also additional I refer to the package of xserver-xorg-video-ati version 1:6.6.3-2ubuntu6 I use.
This is the only one where no hang on switch to VT.
with newer version I got the hangs on switch and S3.
Also I interessed in why this not happend in hibernate?

[R.Rublack (salatessen)]

now i updated to 1:6.7.195-1ubuntu2 from gusty there are also the problems with my settings, with and without xorg.conf
How can i get version 1:6.6.193-1ubuntu1 the next one to 6.6.3-2ubuntu6 to see if this is working
and checking for what is change in the code.

thx

[Rolf Leggewie (r0lf)]

Take a look at my weblog: http://blog.leggewie.org/?p=24

[Rolf Leggewie (r0lf)]

https://launchpad.net/ubuntu/feisty/i386/xserver-xorg-video-ati/1:6.6.3-2ubuntu6
https://launchpad.net/ubuntu/gutsy/i386/xserver-xorg-video-ati/1:6.6.3-2ubuntu6
https://launchpad.net/ubuntu/gutsy/i386/xserver-xorg-video-ati/1:6.7.195-1ubuntu2

debdiff is probably the tool of choice for inspecting the differences. I don't expect any difference between the first and second link.

[Rolf Leggewie (r0lf)]

first and second (feisty and gutsy version 1:6.6.3-2ubuntu6) are md5sum identical

[Rolf Leggewie (r0lf)]

$ debdiff xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb xserver-xorg-video-ati_6.7.195-1ubuntu2_i386.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/share/xserver-xorg/pci/ati.ids
lrwxrwxrwx root/root /usr/share/bug/xserver-xorg-video-ati/script -> ../xserver-xorg-core/script

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libc6 (>= [-2.5-0ubuntu1),-] {+2.6-1),+} xserver-xorg-core (>= [-2:1.1.1-1)-] {+2:1.3.0.0)+}
 {+<URL:http://www.X.org>+}
 This [-module can be found as-] {+package is built from+} the [-module 'driver/xf86-video-ati' at-]
[- :pserver:<email address hidden>:/cvs/xorg-] {+X.org xf86-video-ati driver module.+}
Installed-Size: [-884-] {+912+}
Provides: xserver-xorg-video-1.0, [-xf86-video-driver-atimisc,-] {+xserver-xorg-video-atimisc,+} xserver-xorg-driver-r128, xserver-xorg-driver-radeon
Version: [-1:6.6.3-2ubuntu6-] {+1:6.7.195-1ubuntu2+}

[Rolf Leggewie (r0lf)]

Turns out that all I had to do was downgrade to xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb to get rid of this bug. No changes to the configuration necessary.

Boy, am I glad this NUISANCE is finally over for me.

[A. Tombol (atombol)]

reverting to 6.6.3 solved it for me too on an X23, but the FPS on glxgears is a disaster...

[Tormod Volden (tormodvolden)]

> How can i get version 1:6.6.193-1ubuntu1 the next one to 6.6.3-2ubuntu6 to see if this is working

> debdiff xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb xserver-xorg-video-ati_6.7.195-1ubuntu2_i386.deb
(btw, you should run debdiff on the source package .dsc files)

Lots of changes happened between these versions. See http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=summary to get an idea.

One thing that happened after the 6.6.3 was the handling of the AGPFastWrite setting and AGPMode (see bug #133192). However, if you get the same lockup when using BusType "PCI", this can not be related.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

situation has not improved after trying out the latest version: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/148408/comments/31

[agd5f (agd5f)]

Do any of the following options help:

Option "DRI" "false"
Option "BusType" "PCI"
Option "AGPMode" "4"
Option "VGAAccess" "FALSE"

Also, can you try the latest ati git master?

does reverting either or both of the following commits help:
80eee856938756e1222526b6c39cee8b5252b409
653da558148cc601bc1f80253e92ef98c75ef37a

[Rolf Leggewie (r0lf)]

The downgrade fixed two more, VERY serious problems I had with X after going for gutsy which reduced the usefullness of my computer by at least 50%:

bug 148408
bug 187967
bug 162136

[Rolf Leggewie (r0lf)]

I installed http://launchpadlibrarian.net/11689116/xserver-xorg-video-ati_6.7.197%2Bgit20080201.bcd59010-0ubuntu0tormod%7Egutsy_i386.deb for testing and the situation is more or less unchanged or possibly even worse.

After installing the updated driver, restarted X and went to the console and the computer already froze right there. With the stock gutsy driver this only happened after trying to get back into X. Instead of the login greeting, the screen showed a bunch of strange patterns in greyscale.

I restarted the computer and tried once more. The situation was now basically the same as always. Going to the VT console was possible as was a login. A complete restart of X was also possible, but going back to a running X session froze the computer with only a hard reboot as a way out.

Going back to feisty version.

[Tormod Volden (tormodvolden)]

Rolf, please try with BusType PCI if you haven't already. Was the last result without any xorg.conf?

For the lockup on resume, a fix has been committed upstream: http://bugs.freedesktop.org/show_bug.cgi?id=12596
It's not yet in my PPA (but maybe later today).

[Rolf Leggewie (r0lf)]

Yes, I had tried with BusType set to PCI. IIRC I tried with and without an xorg.conf.

What did all this testing bring for me? My system is now f*cked again, even with the feisty version. Argh! Video and Multiscreen still work, but I am back to freezes.

[R.Rublack (salatessen)]

@Rolf
today the resume crash for me again, two times, so hopefully the workaround from freedesktop will come in the ubuntu stream soon. to test again, because i'm a little bit tiered of this and at the moment I not have the time for further test.
I'll happely come back after my exams and work to solve this nasty bug.

[R.Rublack (salatessen)]

@Tormod Volden

there is an new workaround insert by Alex Deucher related to freedesktop Bug http://bugs.freedesktop.org/show_bug.cgi?id=12596
may be this can solve your problem

[Tormod Volden (tormodvolden)]

The upstream fix is now in my PPA: xserver-xorg-video-ati_6.7.197+git20080201.b.a38a903d-0ubuntu0tormod~gutsy

[R.Rublack (salatessen)]

I tested the upstream fix with and without xorg.conf present but unlikely I must say no luck for us.

[Rolf Leggewie (r0lf)]

situation is still the same for 1:6.7.197+git20080208.8606c1bd-0ubuntu0tormod~gutsy

[Freeserj (freeserj)]

I have same problem on my thinkpad x22. There is more detailed log(i got it over serial console on com port of UltraBase X2).

Lastest log messages is :

<<here I go to vt from X>>

(II) RADEON(0): RADEONLeaveVT
(II) RADEON(0): RADEONRestore
disable montype: 2
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0): MC_FB_LOCATION : 0xffff0000 0xe3ffe000
(II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
(II) RADEON(0): Map Changed ! Applying ...
(II) RADEON(0): Map applied, resetting engine ...
(II) RADEON(0): Updating display base addresses...
(II) RADEON(0): Memory map updated.
(II) RADEON(0): Programming CRTC2, offset: 0x40000000
(II) RADEON(0): Wrote2: 0x00000000 0x00000000 0x00000000 (0x00004c00)
(II) RADEON(0): Wrote2: rd=0, fd=0, pd=0
finished PLL2
(II) RADEON(0): Programming CRTC1, offset: 0x00000000
Entering Restore TV
Restore TV PLL
Restore TVHV
Restore TV Restarts
Restore Timing Tables
Restore TV standard
Leaving Restore TV
(II) RADEON(0): Ok, leaving now...

<<here I go to X from vt>>

(II) Open ACPI successful (/var/run/acpid.socket)
(II) RADEON(0): RADEONEnterVT
(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
(II) RADEON(0): Primary V_BIOS segment is: 0xc000

<<here is freezing>>

Also, those parameters is not helped:
Option "DRI" "false"
Option "BusType" "PCI"
Option "AGPMode" "4"
Option "VGAAccess" "FALSE"

[Freeserj (freeserj)]

(In reply to comment #14)
> I have same problem on my thinkpad x22. There is more detailed log(i got it
> over serial console on com port of UltraBase X2).
>
> Lastest log messages is :
>
> <<here I go to vt from X>>
>
> (II) RADEON(0): RADEONLeaveVT
> (II) RADEON(0): RADEONRestore
> disable montype: 2
> (II) RADEON(0): RADEONRestoreMemMapRegisters() :
> (II) RADEON(0): MC_FB_LOCATION : 0xffff0000 0xe3ffe000
> (II) RADEON(0): MC_AGP_LOCATION : 0x003fffc0
> (II) RADEON(0): Map Changed ! Applying ...
> (II) RADEON(0): Map applied, resetting engine ...
> (II) RADEON(0): Updating display base addresses...
> (II) RADEON(0): Memory map updated.
> (II) RADEON(0): Programming CRTC2, offset: 0x40000000
> (II) RADEON(0): Wrote2: 0x00000000 0x00000000 0x00000000 (0x00004c00)
> (II) RADEON(0): Wrote2: rd=0, fd=0, pd=0
> finished PLL2
> (II) RADEON(0): Programming CRTC1, offset: 0x00000000
> Entering Restore TV
> Restore TV PLL
> Restore TVHV
> Restore TV Restarts
> Restore Timing Tables
> Restore TV standard
> Leaving Restore TV
> (II) RADEON(0): Ok, leaving now...
>
> <<here I go to X from vt>>
>
> (II) Open ACPI successful (/var/run/acpid.socket)
> (II) RADEON(0): RADEONEnterVT
> (WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.
> (II) RADEON(0): Primary V_BIOS segment is: 0xc000
>
> <<here is freezing>>
>
> Also, those parameters is not helped:
> Option "DRI" "false"
> Option "BusType" "PCI"
> Option "AGPMode" "4"
> Option "VGAAccess" "FALSE"
>

I have test it with new radeon driver 6.8.0

[Chris Smith (cs278)]

Issue still present in Hardy v. 1:6.8.0-1

[Gergely-tomka (gergely-tomka)]

http://bugs.freedesktop.org/show_bug.cgi?id=12596

Have you seen this? and a status report - it still not works with the march 20 driver.

[Rolf Leggewie (r0lf)]

still present in http://launchpadlibrarian.net/12175308/xserver-xorg-video-ati_6.8.0-1ubuntu0tormod%7Egutsy_i386.deb

[Tormod Volden (tormodvolden)]

Rolf, I updated the not-so-on-the-edge-any-longer Gutsy driver on https://wiki.ubuntu.com/XorgOnTheEdge. I haven't seen any relevant changes, but it can be nice to tell upstream that you have tried "latest git" anyway. Although I recommend testing out Hardy which has newer kernel and xorg.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

Still the same with 1:6.8.0+git20080404.5f5e21bb-0ubuntu0tormod

[Rolf Leggewie (r0lf)]

still the same on 1:6.8.0+git20080404.5f5e21bb-0ubuntu0tormod in gutsy.

[Bryce Harrington (bryce)]

I don't know if this will fix this specific issue, but I've backported a bunch of high importance patches that upstream recommended, that fix problems sort of like this one, so I think it would be worth the time to test. Please try this .deb and report what you find:

http://people.ubuntu.com/~bryce/Testing/ati/

If we can determine that the patches in this deb fix this bug, they may be candidates for backporting to Hardy. In particular, this one looks like it might solve this bug:

    + 102_radeon_restore_clock_gating_on_vt_switch.patch:
      Fixes issue which causes hangs on resume (vt switch) for non-avivo's,
      and forces clock errata for r300 and rv100 variants.

[Chris Smith (cs278)]

Doesn't fix it for me.

[Rolf Leggewie (r0lf)]

unfortunately, not fixed on my X24, either. But I guess it is nice to have the other bug fixes, nonetheless ;-)

[Bryce Harrington (bryce)]

Okay, that's unfortunate but thanks for testing it.

[R.Rublack (salatessen)]

Created an attachment (id=16289)
strace with git master revert commits from #14

[R.Rublack (salatessen)]

I report the same issue for me on X24 in launchpad.org Bug #148408.

(In reply to comment #13)
> Do any of the following options help:
>
> Option "DRI" "false"
> Option "BusType" "PCI"
> Option "AGPMode" "4"
> Option "VGAAccess" "FALSE"
>
> Also, can you try the latest ati git master?
>
Try the last last master from 2008/04/28 070cce5255a5c311f9d8b85ec54bd56655014933
no change.
> does reverting either or both of the following commits help:
> 80eee856938756e1222526b6c39cee8b5252b409
> 653da558148cc601bc1f80253e92ef98c75ef37a
>
Yes revert this commits, but also freeze on switch.

The problem is that I tried to debug the issue but no debug output or strace because the system freeze.
The only one is the attached strace output in comment #18

[R.Rublack (salatessen)]

so now I'm a little bit confused.
One week ago I upgrade to hardy and the problem was also there, so I decided to give it a try going back to last working 6.6.3-2 from gutsy.
But of the problem with unresolved dep in xserver-xorg-video-1.0 I build the .deb from source of snapshot.debian. And now...
... the freeze is also with 6.6.3-2 and same settings from gusty.

Was there any additional patch from ubuntu for the 6.6.3-2 build?

My testing was going from 6.6.3-2 to actual git with and without revert the commits recommended by Alex Deucher in https://bugs.freedesktop.org/show_bug.cgi?id=13994#c13.

[Rolf Leggewie (r0lf)]

Thank you for your continued testing. This beast is indeed hard to pinpoint. I have had a similar experience than you. The situation was fixed once for me by going back to the last known good version (comment 27). Subsequently, the problem would stay, even after a downgrade.

BTW, ubuntu also never forgets any binary release they made: http://blog.leggewie.org/?p=24. No need to recompile stuff.

[R.Rublack (salatessen)]

Thx Rolf,
now I've got the 6.6.3-2ubuntu6 package and after dpkg --force-conflicts -i it worked.
I know it isn't the save way, but I need suspend.
But what I not understand is why debian 6.6.3-2 and ubuntu 6.6.3-2ubuntu6 are reacting in such different way. Was the debian package the grounding for the ubuntu once ?Was there any additional patch to the debian package?
Also a strange behavior is the X is now on my VT 9. I'm very confused at the moment, but still looking for the change what cause this problem.

[Rolf Leggewie (r0lf)]

Are you saying that the ubuntu deb fixed this for you? Can you post the md5sum of the package that fixed it? As I said, downgrading to the feisty version fixed this for me once, but later on even that would not fix it anymore. Maybe you can do a "debdiff" between the ubuntu version that worked for you and the debian version you recompiled to find out if there is any relevant difference.

[R.Rublack (salatessen)]

also the unbuntu package is the feisty version from launchpad
I tried:
- switch X to VT and return, successful
- suspend S3 coming back, successful

md5sum:
36672117653a8cd4eeed880b483393b5 xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb

debdiff xserver-xorg-video-ati_6.6.3-2_i386.deb xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Conflicts: {+xserver-xorg-driver-ati,+} xserver-xorg-driver-r128, xserver-xorg-driver-radeon, xserver-xorg-video-atimisc
Maintainer: {+Ubuntu Core Developers <email address hidden>+}
{+Original-Maintainer:+} Debian X Strike Force <email address hidden>
Provides: {+xf86-video-driver-atimisc,+} xserver-xorg-driver-r128, xserver-xorg-driver-radeon, [-xserver-xorg-video-22xf86-video-driver-atimisc-] {+xserver-xorg-video-1.0+}
Replaces: xserver-xorg (<< 6.8.2-35), {+xserver-xorg-driver-ati,+} xserver-xorg-driver-r128, xserver-xorg-driver-radeon, xserver-xorg-video-atimisc
Version: [-1:6.6.3-2-] {+1:6.6.3-2ubuntu6+}

[R.Rublack (salatessen)]

thx to tormod for the debdiff

as I can see there some additional patches applied to ubuntu deb.
I think one of this patches is the key to the problem.
so I took a look in next released version 6.7.195-1ubuntu2.
Some of the patches are actual commited in source, but some like 100_radeon_enable_bios_hotkeys_by_default.diff
I can't find.

[R.Rublack (salatessen)]

now i tried to build with the .dsc and diff.gz from 6.6.3-2ubuntu6 one of the next release 6.6.3-5 from debian snapshot. It worked.

[R.Rublack (salatessen)]

now I tried a little bit with debian and ubuntu packages. So the last working ubuntu .deb was 6.6.3-2ubuntu6.
http://launchpadlibrarian.net/7302068/xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb

 So I tried the related debian package from snapshot, http://snapshot.debian.net/archive/2006/10/16/debian/pool/main/x/xserver-xorg-video-ati/xserver-xorg-video-ati_6.6.3-2_i386.deb
it wasn't working. debdiff says in the ubuntu package were some additional patches.
so i took debian source 6.6.3-2 from snapshot and build .deb with the .dsc and .diff.gz from ubuntu https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati/1:6.6.3-2ubuntu6
and this time it worked.
So looking in source from https://launchpad.net/ubuntu/gutsy/i386/xserver-xorg-video-ati/1:6.7.195-1ubuntu2 some of this patched were going into the source of ati driver but some not. And 6.7.195 isn't working, so my conclusion:
one of this additional patches should be applied or the relavant changes in source.

[Mike Holland (z-launchpad-myk-id-au)]

I'm getting a different md5sum:

57da0b00e64f023cc4222f8696558897 xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb
from http://launchpadlibrarian.net/7302068/ .

I can install it on Hardy(8.04) with "dpkg --force-conflicts -i ", but the X server will not load it.
How is it possible to use the old ATI driver with the Hardy X server?
Meanwhile, I'm stuck with VESA , am I?

log:
(II) LoadModule: "ati"
(II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
(II) Module ati: vendor="X.Org Foundation"
    compiled for 7.2.0, module version = 6.6.3
    Module class: X.Org Video Driver
    ABI class: X.Org Video Driver, version 1.1
(EE) module ABI major version (1) doesn't match the server's version (2)
(II) UnloadModule: "ati"
(II) Unloading /usr/lib/xorg/modules/drivers//ati_drv.so
(EE) Failed to load module "ati" (module requirement mismatch, 0)

[R.Rublack (salatessen)]

under http://launchpadlibrarian.net/7302068/ i got No Such Resource.

try https://launchpad.net/ubuntu/feisty/i386/xserver-xorg-video-ati/1:6.6.3-2ubuntu6

[Mike Holland (z-launchpad-myk-id-au)]

Rublack, thats the same file.
Sorry about that URL, but if you append the package filename, you get the same file (same md5sum).

So are you able to use that in Hardy? Any idea how I can avoid the mismatch error shown above?
Mike

[R.Rublack (salatessen)]

yes I'm able to use it in hardy. one problem is the installation with
dpkg --force-conflicts -i xserver-xorg-video-ati_6.6.3-2ubuntu6_i386.deb because of the
provided xserver-xorg-video-1.0. hardy xserver-xorg-core conflicts with this.

Xorg.0.log:
(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 1.4.0.90, module version = 4.2.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 2.0
(II) LoadModule: "ati"
(II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
(II) Module ati: vendor="X.Org Foundation"
        compiled for 1.4.0.90, module version = 6.6.3
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 2.0

But I builded the binary from the source of 6.6.3-2ubunt6
Maybe give this a try.

[Mike Holland (z-launchpad-myk-id-au)]

OK, my IBM X23 is now working using the binary drivers compiled by R.Rublack (thanks!)
That is the 6.6.3 ATI drivers with ubuntu patches, compiled for X.org 1.4.0.90, ubuntu 8.04. I manually copied ati_drv.so and
radeon_drv.so to /usr/lib/xorg/modules/drivers , not using the package management. So they may well be overwritten on the next upgrade. I edited xorg.conf, changing "vesa" back to "ati" for the Device.

> (II) Loading /usr/lib/xorg/modules/drivers//ati_drv.so
> (II) Module ati: vendor="X.Org Foundation"
> compiled for 1.4.0.90, module version = 6.6.3

[Bugs-freedesktop-org (bugs-freedesktop-org)]

Created an attachment (id=16489)
Files changed by the diff.gz in ubuntu vs. in debian

r.rublack, thank you for your work on this. I picked up the ball and moved it a little further. I hope I understood you correctly, please correct me if I did not.

Both debian and ubuntu take (of course) the same xserver-xorg-video-ati_6.6.3.orig.tar.gz with md5sum of 57f751611bc195b094772493f3ec50ba and then each apply their own diff.gz to it before compilation and packaging. With the help of lsdiff I inspected what files were being changed by those diff.gz and then compared the results between debian and ubuntu. Please find the result in the attachment.

ubuntu creates a number of patches named 10*.diff which are missing from the patched debian source tree. I believe that most likely one of those patches is responsible for the ubuntu package working as expected and the debian package failing to do so.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

(From update of attachment 16489)
>debian/patches/100_radeon_enable_bios_hotkeys_by_default.diff <
>debian/patches/101_radeon_dac_power.diff <
>debian/patches/102_radeon_fix_agp_fastwrite.diff <
>debian/patches/103_fix_misdetection_of_some_chipsets.diff <
>debian/patches/104_radeon_rv280_cp_twopointlines.diff <
>debian/patches/105_fdo_att7409_bug5437.diff <
>debian/patches/106_radeon_predownscale_to_make_hd_video_work. <
>debian/patches/107_radeon_reupload_textures_on_resume.diff <
>debian/patches/108_fix_planar_yuv.diff <

Let's take a closer look at those patches. None of them made it from feisty to gutsy. Looks like most of them were dropped in 1:6.6.193-1ubuntu1, so let's take a look at the Changelog. Patches 101, 103, 104, 106 and 107 were dropped as included in upstream.

Can anybody narrow down the list further by saying with confidence which of those patches are certain not to affect the ati chip?

R. Rublack, can we burden you with recompiling and disecting which of the remaining patches (100, 102, 105 and 108) breaks and unbreaks version 6.6.3-2ubuntu6?

[Bugs-freedesktop-org (bugs-freedesktop-org)]

I believe I have found a very HOT candidate.

Patch 107_radeon_reupload_textures_on_resume.diff was dropped from ubuntu as having been applied upstream. But going through the motions of pretending to apply patches from 100 to 108 (--dry-run) most were simply rejected, some were reverse-applicable indicating that they made it 1:1 into upstream, but 107 was applicable both to 1:6.6.193-1ubuntu1, the next version and the first one to break, and even the sources to the latest hardy release 1:6.8.0-1. The name of the patch also seems to indicate this is very likely to the be one we are looking for.

IOW, changelog in ubuntu claims that 107_radeon_reupload_textures_on_resume.diff from https://launchpad.net/ubuntu/feisty/+source/xserver-xorg-video-ati/1:6.6.3-2ubuntu6/+files/xserver-xorg-video-ati_6.6.3-2ubuntu6.diff.gz was applied upstream and thus it was dropped when in fact the code never arrived upstream.

[Rolf Leggewie (r0lf)]

I believe I have found a very HOT candidate for the patch that we are all looking for (see upstream bug report at freedesktop.org for more details). 107_radeon_reupload_textures_on_resume.diff from
https://launchpad.net/ubuntu/feisty/+source/xserver-xorg-video-ati/1:6.6.3-2ubuntu6/+files/xserver-xorg-video-ati_6.6.3-2ubuntu6.diff.gz. I'll try and compile the latest hardy package with this patch applied in my PPA. Keep your fingers crossed.

[Tormod Volden (tormodvolden)]

The "107" patch in question was taken from http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=4651d00b183cb498879d605c4b93cd3a0c63cb33 and it's still there in the code AFAICS.

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #23)
> Patch 107_radeon_reupload_textures_on_resume.diff was dropped from ubuntu as
> having been applied upstream. But going through the motions of pretending to
> apply patches from 100 to 108 (--dry-run) most were simply rejected, some were
> reverse-applicable indicating that they made it 1:1 into upstream, but 107 was
> applicable both to 1:6.6.193-1ubuntu1, the next version and the first one to
> break, and even the sources to the latest hardy release 1:6.8.0-1.

That fix is certainly present in current Git and has been for a long time. Sometimes patch doesn't realize a change is already present when the context has changed.

> The name of the patch also seems to indicate this is very likely to the be one
> we are looking for.

I'm afraid not - the absence of this fix would merely cause texture corruption in 3D apps running across a VT switch.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

(In reply to comment #24)
> > The name of the patch also seems to indicate this is very likely to the be one
> > we are looking for.
>
> I'm afraid not - the absence of this fix would merely cause texture corruption
> in 3D apps running across a VT switch.

And indeed, not a fix :-(

But it might have fixed bug 11230 which I reported some time ago but was unable to test ever since this problem arose.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

I have found out that this bug does not necessarily occur with the latest 6.8.0 version from hardy and is dependent on xorg.conf

https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/148408/comments/62
https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/148408/comments/63

[Bugs-freedesktop-org (bugs-freedesktop-org)]

My apologies for the noise. I just realized that xorg.conf.switching uses the vesa driver which is of course known to switch successfully between X and VT.

[Rolf Leggewie (r0lf)]

I have an interesting observation to share with you. Switching between X and VT *is* possible and even with the latest, unpatched version in hardy. This problem also seems to depend on how xorg.conf is configured. With the attached xorg.conf, I can switch between X and VT, albeit quite slowly. I have not yet gotten this back to work with Xinerama/MergedFB and X now runs on VT10 or VT11 instead of the usual VT7.

[Rolf Leggewie (r0lf)]

My apologies for the noise. I just realized that xorg.conf.switching uses the vesa driver which is of course known to switch successfully between X and VT.

[SteveH (steve-systemax)]

Mike Holland used the binary drivers compiled by R.Rublack.

Any idea where he got them? Is there a URL I can download from?

[Mike Holland (z-launchpad-myk-id-au)]

Eh? I got them from R.Rublack. What do you mean?
By "binary" I meant that I didn't compile it myself. The source is available, as above.
Or email me (or Ralf) for the binary .deb.

[D. Grady (fehknt)]

This is also affecting me - to be expected though, ThinkPad X24 like many others. I have to use VESA driver if I want suspend or terminal switching to work. I have tried many of the suggestions posted, like everyone else, have had no luck with them.

[Mike Holland (z-launchpad-myk-id-au)]

Try the attached ATI drivers, as described above. Works for me.
 Unpack to /usr/lib/xorg/modules/drivers .

[D. Grady (fehknt)]

Ach, yeah, that did fix it. Sorry - I tried some updated driver, but I guess not that one. Thanks!

[Tormod Volden (tormodvolden)]

If I understand correctly, 6.6.3-2 is broken but 6.6.3-2ubuntu6 works fine? Since the difference is 8 independent patches, I would suggest to try removing one patch at a time to narrow this issue down. That is, start with the 6.6.3-2ubuntu6 source, compile it on Hardy and test. It should work. Then comment out the first patch (in debian/patches/series) and recompile and test. Then the second patch, and so on...

It would be easiest if some of you who experience this issue could do this yourselves, but I can also offer to compile packages if several people commit to test them systematically.

[Tormod Volden (tormodvolden)]

Just a tip if someone want to compile and test, you can skip the packaging and package installation to save time: Do this on a console Ctrl-Alt-F1 log in and stop X
 sudo /etc/init.d/gdm stop
After fetching the source package
 dget https://edge.launchpad.net/ubuntu/feisty/+source/xserver-xorg-video-ati/1:6.6.3-2ubuntu6/+files/xserver-xorg-video-ati_6.6.3-2ubuntu6.dsc
and unpacking it
 dpkg-source -x xserver-xorg-video-ati_6.6.3-2ubuntu6.dsc
go into the source directory
 cd xserver-xorg-video-ati-6.6.3
and build it [segno %]
 debian/rules build
then just install the new driver module
 sudo cp obj-i486-linux-gnu/src/.libs/radeon_drv.so /usr/lib/xorg/modules/drivers/radeon_drv.so
and test X
 startx
Log out to shut down X again. Then
 fakeroot debian/rules clean
and comment out a new patch
 nano debian/patches/series
and build again... [dal segno]

[Rolf Leggewie (r0lf)]

well, as expected, no luck for me. Nothing changed even with the binary drivers from comment 69. I compiled the last feisty version fully patched and that already blocked the machine just on starting up X.

I hope I'll find the time to set up a dedicated test installation for systematically analyzing the situation. I still have an old X20 that I don't really use for anything anymore. I think the graphics chip is a bit different, but maybe I can reproduce and disect the problem there.

[D. Grady (fehknt)]

Well, I ran through the tests, once each with a single patch commented out. The only one that creates this problem is the removal of 105_fdo_att7409_bug5437.diff. I hope this helps.

[Bryce Harrington (bryce)]

Thanks, that does help a ton.

[Tormod Volden (tormodvolden)]

Just for verification, I took the newer 6.6.193-1ubuntu1 and applied the upstream patch 8746 (successor to 7409) to it. Can you please try it out? If it works, please attach an Xorg.0.log that includes some VT switching.

[D. Grady (fehknt)]

using the package
xserver-xorg-video-ati_6.6.193-1ubuntu1p8746_i386.deb
yes, did work. xorg log attached, includes VT switches and suspend/resume

[R.Rublack (salatessen)]

okay is working with this package
switching and resume from S3
xorg.log attached

thx to all

[Rolf Leggewie (r0lf)]

Wow, great. This even works for me, too. Which is pretty amazing given the fact that it looked like my X24 was a pretty hopeless case previously.

Is it already understood what exactly 105_fdo_att7409_bug5437.diff does and how that should be carried over to the more recent xorg versions?

Two remarks. The old version messed up my multi-monitor setup pretty badly so I'll have to get back to the hardy version. Second, the switching from VT to X and back feels somewhat more sluggish than what I think I remember (must have been eons ago). But thank God, it is working again.

Great work, guys!

[Tormod Volden (tormodvolden)]

The 105_fdo_att7409_bug5437.diff (or upstream patch 8746) includes a workaround to figure out monitor specs (see bug #22985, a bug number I know by heart BTW). It involves doing VBE probing instead of the normal driver-asks-card probing. This workaround would break on some other cards/laptops, and was not needed any longer when the normal probing got fixed. The reason it makes VT switching working for you is probably a side effect. We can see this in your logs:
(WW) RADEON(0): zero MEMSIZE, probably at D3cold. Re-POSTing via int10.

Most likely it is the POST'ing that does the job. For resume, I think this can be configured in the sleep/resume settings. For VT switching, this must be done in the driver. Of course, there must be a better solution.

[Tormod Volden (tormodvolden)]

This is just a theory of mine, but you can help confirm it if you switch to a virtual console, log in and run
 sudo vbetool post
and then switch back to X and see if it still works. Although I am not sure vbetool post uses int10 like the X server does.

[D. Grady (fehknt)]

well, it reposts the video in the console, but when I try to switch back it still dies.

[Rolf Leggewie (r0lf)]

I understand that finding a proper fix will be difficult and may take some time. But can we get a patch for a workaround against current xorg to put in our PPA?

[Tormod Volden (tormodvolden)]

Some comments in the Debian bug report might indicate that it is a timing issue, and that anything slowing down the switch (like busy CPU, debug tracing, and perhaps accidentally doing a POST) works around it. The old patches mentioned here do not apply to the current code. Sparkling the code with microsleeps could work. I am not so optimistic about how much efforts the Xorg driver maintainers would invest in these old cards, but it might help if some of you having the card could do some testing. Try for instance attaching to Xorg with strace over the network from another computer. Or use gdb (also remotely) to narrow down where it hangs - for instance with breakpoints.

[D. Grady (fehknt)]

I'm willing to do the strace work - but I really don't know how to attach to Xorg over the network. Is it a matter of ssh'ing and attaching to the running process? If so - how does one attach strace to a running process?

[Tormod Volden (tormodvolden)]

Great, see https://wiki.ubuntu.com/X/Backtracing - the "Trace" section.

[D. Grady (fehknt)]

Straces attached. When dumping to a file it was slowed down enough to apparently fix the problem! Setting the console scrollback buffer to 5000 lines allowed me to get a full capture of it failing, so I have attached both files - the one "worked" copy includes several VT switches, the failed one obviously includes just the one that crashes.

[D. Grady (fehknt)]

Also, GDB wasn't much help because i couldn't get a backtrace once the system hit hard-lock. maybe once the bug is narrowed down via strace we can use breakpoints?

[Tormod Volden (tormodvolden)]

Thanks. Then we got it confirmed that it is a timing issue. Unfortunately, the strace output is not so informative. Can you try ltrace? The idea of gdb was to set a breakpoint early in the switching code, see if it locks up before reaching the breakpoint, then move the breakpoint later in the code etc. But this needs a good knowledge of the code and gdb. I think the interesting code is in the RADEONEnterVT() function in src/radeon_driver.c. I would suggest setting a "breakpoint" on that function, then (if needed, go "down" and) "step" through it and "continue" when you have reached the end of it. Then delete the breakpoint, set a new one a few lines into the function and try again. Alternatively, sprinkle that function with usleep() all over, and if that works, remove one by one until it breaks.

Anyway, if we get it narrowed down to one function, we can probably get help from the upstream developers.

[Tormod Volden (tormodvolden)]

BTW, please attach Xorg.0.log from a working switch (slowed down by strace for instance). That would help me to see where the code is going.

[Tormod Volden (tormodvolden)]

I wrote "step" in the gdb instructions above, but you'd rather use "next" to go through the function. "step" goes into each of the subfunctions, which shouldn't be necessary in a first approach.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Devin Grady did some debugging in https://bugs.launchpad.net/bugs/148408

"setting a breakpoint at the entrance to function RADEONEnterVT() shows me that it gets there and when i continue after that it locks, indicating that the problem is after the entrance. After adding breakpoints at the following lines I saw the corresponding behavior:

9102: did not reach before a crash (this is right after RADEONWaitForIdleMMIO(pScrn);)

9093: reached without a crash (right after pInt = xf86InitInt10 (info->pEnt->index);) upon "next'ing" to advance through the problem area I find that execution of line 9095 (xf86ExecX86int10 (pInt);) (so i was at this line and just hit next) causes it to hard-lock."

[agd5f (agd5f)]

Created an attachment (id=18178)
possible fix

Does this patch help? The mem size reg on M6 can be unreliable.

[D. Grady (fehknt)]

the problem seems to be with radeon_driver.c:9095:xf86ExecX86int10 (pInt); (see attached)

A quick description of the attachments:
gdb.log: probably the most helpful, it's a careful description of all my steps in gdb in order to come to the above conclusion.
xorg.worked.log: as requested, a copy of my xorg.0.log when slowed down by strace enough to work.
xorg_strace_worked.log: the strace that slowed down the above xorg.worked.log - so these both deal with the same VT switch
ltrace.log: ok, this is just a segfault.... when it attached it took down X and I couldn't get anything useful out of it. If an ltrace is required, someone is going to have to give me some tricks to try.

-Devin

[Tormod Volden (tormodvolden)]

I wonder if this in your strace is ok:
ioctl(6, MTRRIOC_GET_ENTRY, 0xbfb62aec) = -1 EINVAL (Invalid argument)

I traced the POST code in RADEONEnterVT() to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234575 where it was introduced as a workaround to some cards going bad over resume. I guess it should not try to POST after only a VT switch.

Don't worry about ltrace, your gdb work is excellent. But it means that just executing the POST without waiting before and after doesn't help, so a usleep workaround will probably not work.

[Tormod Volden (tormodvolden)]

Upstream Alex made a patch now, see upstream package. Attached is a i386 binary package with his patch applied to latest git version. Please test.

[D. Grady (fehknt)]

Ummm, strange problem... that package killed my Xserver. My Xorg.log indicates that it's looking at the vesa driver?!?!? i'll post my xorg.conf too but i'm clearly not using vesa.

[Tormod Volden (tormodvolden)]

Sorry, that's probably due to the recent split of the -ati and -radeon packages. Please install the -ati package from https://launchpad.net/~tormodvolden/+archive together with the -radeon package above.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Devin tried it:
"Yes, it works like a charm. Not only that but VT switching seems like
(I'm not 100% sure but maybe 90%) it's noticeably faster. Is this
because it's not completely re-posting the video now? Attached is the
log from several successful VT switches in a row.

Thanks so much! Do you have any idea when this will make it into an
official update release?"

[agd5f (agd5f)]

fix pushed: 268c848130ec1770bb645a74197b6aca7fc95abc

[Bugs-freedesktop-org (bugs-freedesktop-org)]

I'm happy to report that indeed the patch works for me as well. Thank goodness and thank you guys for all the hard work.

[D. Grady (fehknt)]

Yes, it works like a charm. Not only that but VT switching seems like (I'm not 100% sure but maybe 90%) it's noticeably faster. Is this because it's not completely re-posting the video now? Attached is the log from several successful VT switches in a row.

Thanks so much! Do you have any idea when this will make it into an official update release?

[Tormod Volden (tormodvolden)]

Well thanks to yourself, and Alex Deucher. He came up with the patch within half an hour when I gave him the results of your debugging. Yes, it is not re-post'ing at all now. It should never do after VT switching, only once after boot or resume. The old test to see if it was already post'ed was broken for many M6 cards, since the test was to check if mem_size was zero, and these cards have some hardware bug where the mem_size register is 0 instead of 8, and even if 8 was written back initially, it would "forget" it again. Therefore an unnecessary post was done, and multiple post'ing is often troublesome.

[Tormod Volden (tormodvolden)]

This has now been fixed in the upstream git tree: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=268c848130ec1770bb645a74197b6aca7fc95abc
I think this can get into Intrepid really quick, and would be suitable for SRU in Hardy.

[Tormod Volden (tormodvolden)]

Although the bug has been fixed, I am still wondering why the POST makes the card hang. Can you please try this version, which will POST, but hopefully not hang (adds LockLegacyVGA)? This can help in other situations where a POST is done.

[D. Grady (fehknt)]

I'm afraid that it does still hang with that change...

[D. Grady (fehknt)]

oh, and the last lines of Xorg.0.log are:
finished PLL2
Entering Restore TV
Restore TV PLL
Restore TVHV
Restore TV Restarts
Restore Timing Tables
Restore TV standard
Leaving Restore TV

[Rolf Leggewie (r0lf)]

Thanks guys, for the awesome work. I am happy to report that indeed the problem is gone for me as well. Thank goodness.

[Bryce Harrington (bryce)]

I put in sync req bug #261929 to pull a newer snapshot that includes this patch, but unfortunately Archive Admin still has not yet updated it, so the fix didn't make it for alpha-5. But I'm hopeful they'll get to it once the alpha-5 freeze is done, and we can finally close this bug.

Also I'll echo Tormod's thank you to all the people who did the troubleshooting in this bug. It was actually rather fun to read through this bug report! (Not something I say often!!)

[Brian Murray (brian-murray)]

The xorg.conf at http://launchpadlibrarian.net/14488150/xorg.conf.switching and attached to this bug is problematic for the following reason:
An EndSection is in the wrong place.

[Bryce Harrington (bryce)]

Archive admin has updated the git snapshot to latest from debian, which includes this patch. Closing. Thanks again everyone!