Announcement

Collapse
No announcement yet.

Testing radeon KMS on Ubuntu

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

  • #41
    Very poor performances with RV350 and Jaunty

    Hello,
    I'm testing KMS packages under Jaunty (and yes, I read the disclaimer...) and I get very poor performances. With Compiz the system is unusable and with Metacity is quite slow (slowness is well noticeable on resizing and moving windows).

    To make things work I had to install packages from radeon-kms PPA (of course) and upgrade xorg and mesa to Karmic; with only KMS packages or with radeon-kms and xorg-edgers packages I get console working, but xorg fails to start ("failed to allocate fb").

    Everything works good with KMS live 0.14 (boot from usb).

    How can I solve this issue? Thanks

    Comment


    • #42
      I dont have a solution, but I have the same problems using KMS on jaunty. Probably the xserver is too old or some other userspace component.
      But radeon KMS is stilly quite immature - radeon-rewrite has still some major performance refressions and power management does not work at all..

      Comment


      • #43
        By setting drm.debug=1 I get syslog flooded by
        Code:
        [drm:drm_ioctl] pid=4025, cmd=0x40086409, nr=0x09, dev 0xe200, auth=1
        [drm:drm_ioctl] pid=4025, cmd=0xc01c645d, nr=0x5d, dev 0xe200, auth=1
        [drm:drm_ioctl] pid=4025, cmd=0xc020645e, nr=0x5e, dev 0xe200, auth=1
        [drm:drm_ioctl] pid=4025, cmd=0xc0206466, nr=0x66, dev 0xe200, auth=1
        [drm:drm_ioctl] pid=4025, cmd=0xc0086464, nr=0x64, dev 0xe200, auth=1
        where pid=4025 is Xorg and cmd sequence is fixed.

        I get even a lot of
        Code:
        [drm:drm_mode_cursor_ioctl] 
        [drm:drm_ioctl] pid=4025, cmd=0xc01c64a3, nr=0xa3, dev 0xe200, auth=1
        and in Xorg.0.log
        Code:
        RADEON DRM CS failure - corruptions/glitches may occur -22
        bufmgr: last submission : r:64 vs g:268435456 w:94208 vs v:46861515
        RADEON DRM CS failure - corruptions/glitches may occur -22
        bufmgr: last submission : r:64 vs g:268435456 w:188416 vs v:46861515
        What's going on?
        Last edited by meden; 06-25-2009, 07:11 AM. Reason: Added Xorg.0.log errors

        Comment


        • #44
          The latest updates include 2.6.30-10-generic and with this kernel, KMS does not work anymore.

          Comment


          • #45
            Originally posted by DF5JT View Post
            The latest updates include 2.6.30-10-generic and with this kernel, KMS does not work anymore.
            Has this happened to somebody else? Because I'm planning to upgrade to the new kernel but if KMS does not work ...... I won't do it

            Comment


            • #46
              I think KMS and GEM/TTM for radeon went into 2.6.31, not 2.6.30...

              Comment


              • #47
                yeah maybe the update is unpatched kernel from main ubuntu repos ?

                I mean the last listed kernel here :
                https://launchpad.net/~xorg-edgers/+archive/radeon-kms
                is
                linux - 2.6.30-9.10kms6 uploaded 2009-06-17

                you should obviously stick to that if you want KMS

                Comment


                • #48
                  Originally posted by tormod View Post
                  Sounds like you did not copy the live CD correctly and you have some conflicts with old live CD stuff on it.

                  1. Make sure you delete the old casper folder on the stick
                  2. Use usb-creator instead of whatever scripts
                  I had 2 other partitions with live CD isos on them. Apparently the init script doesn't just use the partition it booted from, it searches for a /casper directory on every block device it can mount. Seems a bit strange, because my other two isos boot just fine without any confusion. Anyway, I renamed the /casper on the other two partitions so they wouldn't be found, so it mounted the correct one from /dev/sdb3.

                  Usually I just have to toggle the bootable flag on the partition I want, using fdisk. This new casper script seems like a step backward.

                  Anyway, that seemed to be the only problem and so it booted successfully on my Asus M6Ne with Mobility 9700 (M300). But it only sees the LVDS and VGA, it doesn't see my S-Video connector. I guess I'm going to stick with Jaunty for a while longer.

                  Comment


                  • #49
                    Originally posted by highlandsun View Post
                    I had 2 other partitions with live CD isos on them. Apparently the init script doesn't just use the partition it booted from, it searches for a /casper directory on every block device it can mount. Seems a bit strange, because my other two isos boot just fine without any confusion. Anyway, I renamed the /casper on the other two partitions so they wouldn't be found, so it mounted the correct one from /dev/sdb3.

                    Usually I just have to toggle the bootable flag on the partition I want, using fdisk. This new casper script seems like a step backward.
                    casper never looked for a bootable flag. Only the DOS MBR uses the bootable flag AFAIK. casper should verify the .disk/casper-uuid on the block device (against its conf/uuid in the initrd) to make sure it does not mount a wrong /casper directory. Did you boot with the ignore_uuid option?

                    Anyway, that seemed to be the only problem and so it booted successfully on my Asus M6Ne with Mobility 9700 (M300). But it only sees the LVDS and VGA, it doesn't see my S-Video connector. I guess I'm going to stick with Jaunty for a while longer.
                    You can always report the bug to help getting it fixed, if it is not a known issue.

                    Comment


                    • #50
                      Originally posted by tormod View Post
                      casper never looked for a bootable flag. Only the DOS MBR uses the bootable flag AFAIK. casper should verify the .disk/casper-uuid on the block device (against its conf/uuid in the initrd) to make sure it does not mount a wrong /casper directory. Did you boot with the ignore_uuid option?
                      I didn't set any options at all. I dunno why it didn't match UUIDs properly.

                      You can always report the bug to help getting it fixed, if it is not a known issue.
                      Which bug tracker? That iso is already 2 weeks old, not even sure if the bug is current any more.

                      Comment

                      Working...
                      X