Bug 13994

Please attach your xorg log and config.

Created attachment 13668 [details] [review]
xorg.conf from a thinkpad x24

Created attachment 13669 [details] [review]
Xorg.log, the machine crashed

Created attachment 13670 [details] [review]
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 attachment 13671 [details]
strace output, sid driver, crash

Created attachment 13672 [details]
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. 

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

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

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

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

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

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"

(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

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.

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

Created attachment 16289 [details]
strace with git master revert commits from #14

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

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.

Created attachment 16489 [details]
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.

Comment on attachment 16489 [details]
Files changed by the diff.gz in ubuntu vs. in debian

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

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.

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

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

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

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.

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 attachment 18178 [details] [review]
possible fix

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

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.