[M6 LY] System lockup when switching VT's or Resume from Suspend
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xserver-xorg-driver-ati |
Fix Released
|
High
|
|||
xserver-xorg-video-ati (Debian) |
Fix Released
|
Unknown
|
|||
xserver-xorg-video-ati (Ubuntu) |
Fix Released
|
High
|
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-
---
Simon.
mungewell (simon-mungewell) wrote : | #1 |
mungewell (simon-mungewell) wrote : | #2 |
mungewell (simon-mungewell) wrote : | #3 |
Looking at /var/log/
---
(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): RADEONRestoreMe
(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) wrote : | #4 |
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) wrote : | #5 |
Thanks for your bug report and the attached information. Can you please try the -tv6 package from https:/
Changed in xserver-xorg-video-ati: | |
assignee: | nobody → tormodvolden |
status: | New → Incomplete |
mungewell (simon-mungewell) wrote : | #6 |
- Xorg.0.log.old Edit (44.7 KiB, text/plain)
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-
---
I have also attached the /var/log/
Cheers,
Simon.
Tormod Volden (tormodvolden) wrote : | #7 |
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 : | #8 |
Bug #127101 has a similar issue, but with Intel cards.
mungewell (simon-mungewell) wrote : | #9 |
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]
---
---
simon@bourne:~$ dpkg --list | grep xserver | grep core
ii xserver-xorg-core 2:1.3.0.
---
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.
Changed in xserver-xorg-video-ati: | |
assignee: | tormodvolden → nobody |
status: | Incomplete → Confirmed |
David Douard (david-douard) wrote : | #10 |
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-
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 : | #11 |
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:/
I'm going to give it a try and I'll post my results here.
fruehrentner (fruehrentner) wrote : | #12 |
I tried http://
fruehrentner (fruehrentner) wrote : | #13 |
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 : | #14 |
> version 6.7.193 fixed the problem for some people
> 6.7.194-
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 : | #15 |
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.
In freedesktop.org Bugzilla #13994, David Douard (david-douard) wrote : | #16 |
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://
I also tried many xorg.conf tweaks (disabled almost everything).
Note there is a bug report on Ubuntu launchpad tracker:
https:/
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #17 |
Please attach your xorg log and config.
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #18 |
Created an attachment (id=13668)
xorg.conf from a thinkpad x24
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #19 |
Created an attachment (id=13669)
Xorg.log, the machine crashed
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #20 |
Created an attachment (id=13670)
Xorg log, the system not crashed, straced.
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #21 |
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.
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #22 |
Created an attachment (id=13671)
strace output, sid driver, crash
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #23 |
Created an attachment (id=13672)
strace output, experimental driver, no crash
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #24 |
Do any of the following options help:
Option "AGPMode" "4"
Option "DRI" "false"
Option "BusType" "PCI"
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #25 |
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.
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #26 |
*** Bug 14058 has been marked as a duplicate of this bug. ***
Changed in xserver-xorg-video-ati: | |
importance: | Undecided → High |
Rolf Leggewie (r0lf) wrote : | #27 |
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 : | #28 |
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-
with newer xserver-
but also on S3 coming back the system freeze no information in syslog or Xorg.0.log
R.Rublack (salatessen) wrote : | #29 |
hi since my last comment I tried some changes in /etc/default/
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 "DisableGLXRoot
Option "AddARGBGLXVisuals" "true"
Option "AllowGLXWithCo
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "glx"
Load "record"
Load "freetype"
Load "type1"
Load "dri"
EndSection
and
/etc/default/
ACPI_SLEEP=true
ACPI_HIBERNATE=true
ACPI_SLEEP_MODE=mem
MODULES=""
MODULES_
SAVE_VBE_STATE=true
VBESTATE=
POST_VIDEO=true
# SAVE_VIDEO_
USE_DPMS=false
RADEON_LIGHT=true
#DOUBLE_
HIBERNATE_
LOCK_SCREEN=true
# DISABLE_DMA=true
# RESET_DRIVE=true
STOP_SERVICES=""
RESTART_IRDA=false
ENABLE_
SPINDOWN_TIME=12
Rolf Leggewie (r0lf) wrote : | #30 |
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/
USE_DPMS=true
HIBERNATE_
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.
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #31 |
Downgrading to xserver-
https:/
Tormod Volden (tormodvolden) wrote : | #32 |
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 : | #33 |
- Xorg.0.log Edit (43.2 KiB, text/plain)
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-
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 : | #34 |
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) wrote : | #35 |
Take a look at my weblog: http://
Rolf Leggewie (r0lf) wrote : | #36 |
https:/
https:/
https:/
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) wrote : | #37 |
first and second (feisty and gutsy version 1:6.6.3-2ubuntu6) are md5sum identical
Rolf Leggewie (r0lf) wrote : | #38 |
$ debdiff xserver-
[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/
lrwxrwxrwx root/root /usr/share/
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://
This [-module can be found as-] {+package is built from+} the [-module 'driver/
[- :pserver:<email address hidden>:/cvs/xorg-] {+X.org xf86-video-ati driver module.+}
Installed-Size: [-884-] {+912+}
Provides: xserver-
Version: [-1:6.6.
Rolf Leggewie (r0lf) wrote : | #39 |
Turns out that all I had to do was downgrade to xserver-
Boy, am I glad this NUISANCE is finally over for me.
A. Tombol (atombol) wrote : | #40 |
reverting to 6.6.3 solved it for me too on an X23, but the FPS on glxgears is a disaster...
Tormod Volden (tormodvolden) wrote : | #41 |
> 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-
(btw, you should run debdiff on the source package .dsc files)
Lots of changes happened between these versions. See http://
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.
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #42 |
situation has not improved after trying out the latest version: https:/
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #43 |
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:
80eee856938756e
653da558148cc60
Rolf Leggewie (r0lf) wrote : | #44 |
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%:
Rolf Leggewie (r0lf) wrote : | #45 |
I installed http://
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) wrote : | #46 |
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://
It's not yet in my PPA (but maybe later today).
Rolf Leggewie (r0lf) wrote : | #47 |
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) wrote : | #48 |
@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) wrote : | #49 |
@Tormod Volden
there is an new workaround insert by Alex Deucher related to freedesktop Bug http://
may be this can solve your problem
Tormod Volden (tormodvolden) wrote : | #50 |
The upstream fix is now in my PPA: xserver-
R.Rublack (salatessen) wrote : | #51 |
I tested the upstream fix with and without xorg.conf present but unlikely I must say no luck for us.
Rolf Leggewie (r0lf) wrote : | #52 |
situation is still the same for 1:6.7.197+
In freedesktop.org Bugzilla #13994, Freeserj (freeserj) wrote : | #53 |
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): RADEONRestoreMe
(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/
(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"
In freedesktop.org Bugzilla #13994, Freeserj (freeserj) wrote : | #54 |
(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): RADEONRestoreMe
> (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/
> (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) wrote : | #55 |
Issue still present in Hardy v. 1:6.8.0-1
In freedesktop.org Bugzilla #13994, Gergely-tomka (gergely-tomka) wrote : | #56 |
http://
Have you seen this? and a status report - it still not works with the march 20 driver.
Rolf Leggewie (r0lf) wrote : | #57 |
Tormod Volden (tormodvolden) wrote : | #58 |
Rolf, I updated the not-so-
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #59 |
Still the same with 1:6.8.0+
Rolf Leggewie (r0lf) wrote : | #60 |
still the same on 1:6.8.0+
Bryce Harrington (bryce) wrote : | #61 |
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://
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_
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) wrote : | #62 |
Doesn't fix it for me.
Rolf Leggewie (r0lf) wrote : | #63 |
unfortunately, not fixed on my X24, either. But I guess it is nice to have the other bug fixes, nonetheless ;-)
Bryce Harrington (bryce) wrote : | #64 |
Okay, that's unfortunate but thanks for testing it.
Changed in xserver-xorg-video-ati: | |
status: | Fix Released → Confirmed |
In freedesktop.org Bugzilla #13994, R.Rublack (salatessen) wrote : | #65 |
Created an attachment (id=16289)
strace with git master revert commits from #14
In freedesktop.org Bugzilla #13994, R.Rublack (salatessen) wrote : | #66 |
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 070cce5255a5c31
no change.
> does reverting either or both of the following commits help:
> 80eee856938756e
> 653da558148cc60
>
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) wrote : | #67 |
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-
... 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:/
Rolf Leggewie (r0lf) wrote : | #68 |
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://
R.Rublack (salatessen) wrote : | #69 |
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) wrote : | #70 |
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) wrote : | #71 |
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:
36672117653a8cd
debdiff xserver-
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
-------
Conflicts: {+xserver-
Maintainer: {+Ubuntu Core Developers <email address hidden>+}
{+Original-
Provides: {+xf86-
Replaces: xserver-xorg (<< 6.8.2-35), {+xserver-
Version: [-1:6.6.3-2-] {+1:6.6.
Tormod Volden (tormodvolden) wrote : | #72 |
R.Rublack (salatessen) wrote : | #73 |
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_
I can't find.
R.Rublack (salatessen) wrote : | #74 |
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.
In freedesktop.org Bugzilla #13994, R.Rublack (salatessen) wrote : | #75 |
now I tried a little bit with debian and ubuntu packages. So the last working ubuntu .deb was 6.6.3-2ubuntu6.
http://
So I tried the related debian package from snapshot, http://
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:/
and this time it worked.
So looking in source from https:/
one of this additional patches should be applied or the relavant changes in source.
Mike Holland (z-launchpad-myk-id-au) wrote : | #76 |
I'm getting a different md5sum:
57da0b00e64f023
from http://
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/
(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/
(EE) Failed to load module "ati" (module requirement mismatch, 0)
R.Rublack (salatessen) wrote : | #77 |
under http://
try https:/
Mike Holland (z-launchpad-myk-id-au) wrote : | #78 |
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) wrote : | #79 |
yes I'm able to use it in hardy. one problem is the installation with
dpkg --force-conflicts -i xserver-
provided xserver-
Xorg.0.log:
(II) LoadModule: "radeon"
(II) Loading /usr/lib/
(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/
(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) wrote : workaround | #80 |
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/
> (II) Loading /usr/lib/
> (II) Module ati: vendor="X.Org Foundation"
> compiled for 1.4.0.90, module version = 6.6.3
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #81 |
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-
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.
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #82 |
(From update of attachment 16489)
>debian/
>debian/
>debian/
>debian/
>debian/
>debian/
>debian/
>debian/
>debian/
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?
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #83 |
I believe I have found a very HOT candidate.
Patch 107_radeon_
IOW, changelog in ubuntu claims that 107_radeon_
Rolf Leggewie (r0lf) wrote : | #84 |
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_
https:/
Tormod Volden (tormodvolden) wrote : | #85 |
The "107" patch in question was taken from http://
In freedesktop.org Bugzilla #13994, Michel-tungstengraphics (michel-tungstengraphics) wrote : | #86 |
(In reply to comment #23)
> Patch 107_radeon_
> 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.
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #87 |
(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.
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #88 |
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:/
https:/
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #89 |
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) wrote : | #90 |
- xorg.conf.switching - Invalid Edit (1.8 KiB, text/plain)
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) wrote : | #92 |
Rolf Leggewie (r0lf) wrote : | #93 |
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.
Changed in xserver-xorg-video-ati: | |
status: | Confirmed → New |
SteveH (steve-systemax) wrote : | #94 |
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) wrote : | #95 |
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) wrote : | #96 |
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) wrote : | #97 |
- patched ATI drivers, for /usr/lib/xorg/modules/drivers Edit (292.7 KiB, application/x-tar)
Try the attached ATI drivers, as described above. Works for me.
Unpack to /usr/lib/
D. Grady (fehknt) wrote : | #98 |
Ach, yeah, that did fix it. Sorry - I tried some updated driver, but I guess not that one. Thanks!
Tormod Volden (tormodvolden) wrote : | #99 |
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/
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) wrote : | #100 |
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:/
and unpacking it
dpkg-source -x xserver-
go into the source directory
cd xserver-
and build it [segno %]
debian/rules build
then just install the new driver module
sudo cp obj-i486-
and test X
startx
Log out to shut down X again. Then
fakeroot debian/rules clean
and comment out a new patch
nano debian/
and build again... [dal segno]
Rolf Leggewie (r0lf) wrote : | #101 |
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) wrote : | #102 |
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_
Bryce Harrington (bryce) wrote : | #103 |
Thanks, that does help a ton.
Changed in xserver-xorg-video-ati: | |
assignee: | nobody → bryceharrington |
status: | Confirmed → Triaged |
Tormod Volden (tormodvolden) wrote : | #104 |
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.
Tormod Volden (tormodvolden) wrote : | #105 |
- xserver-xorg-video-ati_6.6.193-1ubuntu1p8746_i386.deb Edit (378.0 KiB, application/x-debian-package)
D. Grady (fehknt) wrote : | #106 |
- Xorg.0.log Edit (45.0 KiB, text/plain)
using the package
xserver-
yes, did work. xorg log attached, includes VT switches and suspend/resume
R.Rublack (salatessen) wrote : | #107 |
- Xorg.0.log Edit (46.2 KiB, text/plain)
okay is working with this package
switching and resume from S3
xorg.log attached
thx to all
Rolf Leggewie (r0lf) wrote : | #108 |
- Xorg.0.log, includes a couple of switches between X and VT and back Edit (71.8 KiB, text/plain)
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_
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 : | #109 |
The 105_fdo_
(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 : | #110 |
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 : | #111 |
well, it reposts the video in the console, but when I try to switch back it still dies.
Rolf Leggewie (r0lf) wrote : | #112 |
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 : | #113 |
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 : | #114 |
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 : | #115 |
Great, see https:/
D. Grady (fehknt) wrote : | #116 |
- strace_console.log Edit (170.5 KiB, text/plain)
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 : | #117 |
- xorg_strace_worked.log Edit (4.4 MiB, text/plain)
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 : | #118 |
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_
Anyway, if we get it narrowed down to one function, we can probably get help from the upstream developers.
Tormod Volden (tormodvolden) wrote : | #119 |
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 : | #120 |
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.
In freedesktop.org Bugzilla #13994, Bugzi09-fdo-tormod (bugzi09-fdo-tormod) wrote : | #121 |
Devin Grady did some debugging in https:/
"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 RADEONWaitForId
9093: reached without a crash (right after pInt = xf86InitInt10 (info->
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #122 |
Created an attachment (id=18178)
possible fix
Does this patch help? The mem size reg on M6 can be unreliable.
D. Grady (fehknt) wrote : | #123 |
the problem seems to be with radeon_
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_
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
D. Grady (fehknt) wrote : | #124 |
D. Grady (fehknt) wrote : | #125 |
D. Grady (fehknt) wrote : | #126 |
Tormod Volden (tormodvolden) wrote : | #127 |
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://
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 : | #128 |
- xserver-xorg-video-radeon_6.9.0+git20080807.df0d1ef5-0ubuntu0tormod2_i386.deb Edit (394.9 KiB, application/x-debian-package)
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 : | #129 |
- Xorg.0.log Edit (15.8 KiB, text/plain)
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 : | #130 |
Tormod Volden (tormodvolden) wrote : | #131 |
Sorry, that's probably due to the recent split of the -ati and -radeon packages. Please install the -ati package from https:/
In freedesktop.org Bugzilla #13994, Bugzi09-fdo-tormod (bugzi09-fdo-tormod) wrote : | #132 |
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?"
In freedesktop.org Bugzilla #13994, agd5f (agd5f) wrote : | #133 |
fix pushed: 268c848130ec177
In freedesktop.org Bugzilla #13994, Bugs-freedesktop-org (bugs-freedesktop-org) wrote : | #134 |
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 : | #135 |
- Xorg.0.log Edit (43.9 KiB, text/plain)
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 : | #136 |
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 : | #137 |
This has now been fixed in the upstream git tree: http://
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 : | #138 |
- xserver-xorg-video-radeon_6.9.0+git20080808.33f88f7f-0ubuntu0tormod~post_i386.deb Edit (395.2 KiB, application/x-debian-package)
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 : | #139 |
I'm afraid that it does still hang with that change...
D. Grady (fehknt) wrote : | #140 |
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 : | #141 |
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 : | #142 |
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) wrote : xorg.conf validation failed | #143 |
The xorg.conf at http://
An EndSection is in the wrong place.
Bryce Harrington (bryce) wrote : | #146 |
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 |
Lock up does not occur with Vesa driver.
---
load_detection : 1 (0x00000001) range: (0,1)
scaler: full
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
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
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
---