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

Bug #148408 reported by mungewell on 2007-10-03
Affects Status Importance Assigned to Milestone
Fix Released
xserver-xorg-video-ati (Debian)
Fix Released
xserver-xorg-video-ati (Ubuntu)
Bryce Harrington

Bug Description

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

mungewell (simon-mungewell) wrote :
mungewell (simon-mungewell) wrote :

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
        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
        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) wrote :

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.

mungewell (simon-mungewell) wrote :

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.

Tormod Volden (tormodvolden) wrote :

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

Changed in xserver-xorg-video-ati:
assignee: nobody → tormodvolden
status: New → Incomplete
mungewell (simon-mungewell) wrote :

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.


Tormod Volden (tormodvolden) wrote :

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) wrote :

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

mungewell (simon-mungewell) wrote :

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"

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: 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,

Changed in xserver-xorg-video-ati:
assignee: tormodvolden → nobody
status: Incomplete → Confirmed
David Douard (david-douard) wrote :


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) wrote :


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) wrote :

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) wrote :

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.

Changed in xserver-xorg-video-ati:
assignee: nobody → tepsipakki
Tormod Volden (tormodvolden) wrote :

> 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.

Changed in xserver-xorg-video-ati:
assignee: tepsipakki → nobody
daschmidty (david-p-schmidt) wrote :

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.

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:

Please attach your xorg log and config.

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

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

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

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.

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

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

Do any of the following options help:

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

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.


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

Rolf Leggewie (r0lf) on 2008-01-13
Changed in xserver-xorg-video-ati:
importance: Undecided → High
Rolf Leggewie (r0lf) wrote :

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.

Changed in xserver-xorg-driver-ati:
status: Unknown → Confirmed
Changed in xserver-xorg-video-ati:
status: Unknown → Fix Released
R.Rublack (salatessen) wrote :


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) wrote :

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.


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"
Section "Module"
    Load "dbe"
    Load "extmod"
    Load "fbdevhw"
    Load "glx"
    Load "record"
    Load "freetype"
    Load "type1"
    Load "dri"



Rolf Leggewie (r0lf) wrote :

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



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.

Tormod Volden (tormodvolden) wrote :

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) wrote :

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) wrote :

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.


Rolf Leggewie (r0lf) wrote :

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

Rolf Leggewie (r0lf) wrote :

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

Rolf Leggewie (r0lf) wrote :

$ 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:}
 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) wrote :

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) wrote :

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

Changed in xserver-xorg-video-ati:
status: Fix Released → Confirmed
Changed in xserver-xorg-video-ati:
status: Confirmed → New
Bryce Harrington (bryce) on 2008-07-30
Changed in xserver-xorg-video-ati:
assignee: nobody → bryceharrington
status: Confirmed → Triaged
66 comments hidden view all 146 comments
R.Rublack (salatessen) wrote :

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

thx to all

Rolf Leggewie (r0lf) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Rolf Leggewie (r0lf) wrote :

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) wrote :

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) wrote :

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) wrote :

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

D. Grady (fehknt) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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."

Created an attachment (id=18178)
possible fix

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

D. Grady (fehknt) wrote :

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.


D. Grady (fehknt) wrote :
D. Grady (fehknt) wrote :
D. Grady (fehknt) wrote :
Tormod Volden (tormodvolden) wrote :

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) wrote :

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) wrote :

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.

D. Grady (fehknt) wrote :
Tormod Volden (tormodvolden) wrote :

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.

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?"

fix pushed: 268c848130ec1770bb645a74197b6aca7fc95abc

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) wrote :

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) wrote :

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) wrote :

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.

Changed in xserver-xorg-video-ati:
status: Triaged → Fix Committed
Tormod Volden (tormodvolden) wrote :

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) wrote :

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

D. Grady (fehknt) wrote :

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) wrote :

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

Changed in xserver-xorg-driver-ati:
status: Confirmed → Fix Released
Changed in xserver-xorg-video-ati:
status: New → Confirmed
Changed in xserver-xorg-video-ati:
status: Confirmed → Fix Released
Bryce Harrington (bryce) wrote :

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!!)

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.

2 comments hidden view all 146 comments
Bryce Harrington (bryce) wrote :

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

Changed in xserver-xorg-video-ati:
status: Fix Committed → Fix Released
Changed in xserver-xorg-driver-ati:
importance: Unknown → High
Changed in xserver-xorg-driver-ati:
importance: High → Unknown
Changed in xserver-xorg-driver-ati:
importance: Unknown → High
Displaying first 40 and last 40 comments. View all 146 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.