Results 1 to 9 of 9

Thread: radeon vt switch again

  1. #1
    Join Date
    Apr 2009
    Posts
    6

    Default 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. #2
    Join Date
    Apr 2009
    Posts
    6

    Default

    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

  3. #3

    Default

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

  4. #4
    Join Date
    Jan 2008
    Posts
    294

    Default

    Quote 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

  5. #5
    Join Date
    Apr 2009
    Posts
    6

    Default

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

  6. #6

    Default

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

  7. #7
    Join Date
    Jan 2008
    Posts
    294

    Default

    Quote 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; 04-10-2009 at 08:46 AM.

  8. #8

    Default

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

  9. #9

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •