Announcement

Collapse
No announcement yet.

radeon vt switch again

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • radeon vt switch again

    I know this has been covered quite a few times, and I've
    read the previous threads, but so far no go. I'm using kernel
    2.6.29.1 with the drm updates as of 4/6, xorg-1.5.3 on gentoo with
    a Radeon 3650 AGP card.

    I am trying to bring of 2 X sessions with gdm on :7 and :8
    they seem to come up fine, but after :8 I try to switch back
    to :7 and I get a white screen and a dmesg full of

    [drm] wait idle failed status : 0xA0003030 0x00000003

    If I start up an X session using startx I can use vt switches
    to get back to the console, its just through gdm I get the freeze

    I'm kinda stuck since fglrx failed on me as well, I got around
    the problem by renaming libdri.so . I now get the two X servers
    of course no dri or xv.

    Any suggestions would be greatly appreciated.

  • #2
    Hate to reply to my own thread, but tried 6.12.2 tonight with the same
    result as before.. The following was the last entry in my Xorg.0.log
    before the crash

    (II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
    (II) RADEON(0): [agp] Mode 0x1f000a1b [AGP 0x1106/0x0282; Card 0x1002/0x9596 0x1043/0x0028]
    (WW) RADEON(0): DRI init changed memory map, adjusting ...
    (WW) RADEON(0): MC_FB_LOCATION was: 0x00ff00e0 is: 0x00ff00e0
    (WW) RADEON(0): MC_AGP_LOCATION was: 0x0000d000 is: 0x0000d000
    (II) RADEON(0): RADEONRestoreMemMapRegisters() :
    (II) RADEON(0): MC_FB_LOCATION : 0x00ff00e0 0x00ff00e0
    (II) RADEON(0): MC_AGP_LOCATION : 0x0000d000

    Xorg.1.log contained the following message as well

    Fatal server error:
    xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

    Comment


    • #3
      Originally posted by Waltarro View Post
      Any suggestions would be greatly appreciated.
      Don't use vt-switch at all or try
      Code:
      Option "BusType" "PCIE"
      in the device section of the ati-driver. vt-switch works with this, but I get screen corruptions.

      Comment


      • #4
        Originally posted by PuckPoltergeist View Post
        Don't use vt-switch at all or try
        Code:
        Option "BusType" "PCIE"
        in the device section of the ati-driver. vt-switch works with this, but I get screen corruptions.
        Option "ExaNoDownloadFromScreen" "TRUE"

        Should fix the corruption IIRC

        Comment


        • #5
          Originally posted by legume View Post
          Option "ExaNoDownloadFromScreen" "TRUE"

          Should fix the corruption IIRC
          Setting bustype to PCIE and ExaNoDownloadFromScreen does fix
          the vt-switch problem, unfortunately the second X session doesn't
          get DRI and is too slow. The second screen is my wife's desktop
          so needless to say she'll complain louder than the radeon driver.


          Thanks for the help, I think I'm just going to stay with deleting
          libdri.so for awhile and see if this isn't all straightened out
          over the next few months.

          Comment


          • #6
            Originally posted by legume View Post
            Option "ExaNoDownloadFromScreen" "TRUE"

            Should fix the corruption IIRC
            No, this option is irrelevant, cause already disabled in the source.

            Comment


            • #7
              Originally posted by PuckPoltergeist View Post
              No, this option is irrelevant, cause already disabled in the source.
              I know UTS/DFS is disabled for AGP now, but using BusType PCIE seems to bypass that.

              I just retested and I get plenty of corruption with PCIE alone and none with ExaDFS off.

              FWIW the amount of corruption seen is also amplified by recent exa xserver changes, so much so that (before AGP DFS/UTS was disabled) I bisected and filed an xserver bug.

              On my RV670 loosing DFS gives me quite a performance hit on some, but not all web pages. The concurrent change to disable XV DMA actually fixed a CPU usage issue I was having with that.

              Edit: Forgot to add that for running BusType PCIE makes XV revert to high CPU usage, so I don't use it and just avoid VT switches.
              Last edited by legume; 10 April 2009, 07:46 AM.

              Comment


              • #8
                Originally posted by legume View Post
                I know UTS/DFS is disabled for AGP now, but using BusType PCIE seems to bypass that.

                I just retested and I get plenty of corruption with PCIE alone and none with ExaDFS off.

                FWIW the amount of corruption seen is also amplified by recent exa xserver changes, so much so that (before AGP DFS/UTS was disabled) I bisected and filed an xserver bug.

                On my RV670 loosing DFS gives me quite a performance hit on some, but not all web pages. The concurrent change to disable XV DMA actually fixed a CPU usage issue I was having with that.
                Ok, will test this again. I was sure, I've tested with DFS disabled too, but it seems to be not the case.

                Comment


                • #9
                  Ok, disabling DFS/UTS solves the screen corruptions. But video playback is very very sluggish with "BusType" "PCIE". So it's not really an opinion. So I still wait that the AGP problems will be fixed.

                  Comment

                  Working...
                  X