Announcement

Collapse
No announcement yet.

[drm] Could not set DRM device bus ID.

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

  • #21
    Originally posted by agd5f View Post
    (as root)
    echo 1 > /sys/module/drm/parameters/debug
    Thanks. I ran these without X running, from my boot terminal.
    Nothing apparently happened.

    *****************
    chris@ira:~$ sudo lsof /dev/dri/card0
    chris@ira:~$
    *****************
    chris@ira:~$ su
    Password:
    root@ira:/home/chris# echo 1 > /sys/module/drm/parameters/debug
    root@ira:/home/chris#
    *******************
    This is the tail end of my /var/log/messages
    Code:
    Jan 21 11:00:02 ira -- MARK --
    Jan 21 11:16:29 ira kernel: [drm] Initialized drm 1.1.0 20060810
    Jan 21 11:16:29 ira kernel: [drm] Initialized radeon 1.29.0 20080528 on minor 0
    Jan 21 11:23:57 ira sudo:    chris : TTY=tty1 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/bin/lsof /dev/dri/card0

    Comment


    • #22
      Try starting X after setting the debug parameter and pastebin your dmesg after attempting to start X.

      Comment


      • #23
        As root I ran:
        modprobe drm debug=1

        Then as a user:
        startx

        The pastebin link is the Xorg.0.log

        Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

        Comment


        • #24
          please pastebin your dmesg after you start X. the drm debug parameter prints to the kernel log, not the xorg log.

          Comment


          • #25
            dmesg, from drm w/ debug=1

            Originally posted by agd5f View Post
            please pastebin your dmesg after you start X.
            I was comparing and contrasting the X log and noticing they were nearly identical. So, dmesg makes sense. Thanks.

            I ran modprobe drm debug=1, and the dmesg is linked here:
            Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

            Comment


            • #26
              I don't want to be too obsequious, but 'thank you' to adg5F and bridgeman. I can imagine how hard it is debugging stuff without access to actual hardware, and having dufusi, such as myself, trying to pass along relevant reports.

              Thanks for helping make the world safe for FOSS.

              Comment


              • #27
                Originally posted by User0x45 View Post
                I was comparing and contrasting the X log and noticing they were nearly identical. So, dmesg makes sense. Thanks.

                I ran modprobe drm debug=1, and the dmesg is linked here:
                http://pastebin.com/m7d05c424
                Very strange. Can you open a drm bug on https://bugs.freedesktop.org ?

                Please attach your xorg log and the dmesg with debugging enabled and we'll take it from there. Are you comfortable compiling new kernel modules?

                Comment


                • #28
                  Originally posted by agd5f View Post
                  Can you open a drm bug on https://bugs.freedesktop.org ?

                  ...Are you comfortable compiling new kernel modules?
                  I'll go a post the bug at the above list.

                  As for compiling new kernel modules, I'm totally comfortable
                  compiling a new kernel, and breaking stuff on my system as need be. But I'll probably need to be hand-held abit on some of the steps. (at least the first time through.)

                  Thanks.

                  Comment


                  • #29
                    Problems getting RADEON DRI working

                    As I recall I ran into a similar problem with this. I have a HP Pavilion machine with an onboard Intel i915 graphics chip and I've added a MSI Radeon 3450 graphics card to the machine.

                    The problem is that Linux currently only seems to support one hardware device having DRI. The Radeon DRM cannot get the DRI interface if the Intel DRM has grabbed the DRI interface first. There may be plans to fix this but I have no idea when.

                    I think the trick turned out for me to be setting up both the Intel and the Radeon cards as modules, then loading the DRM interfaces at runtime using modprobe. At that point you should get 2 devices (card0 and card1) in /dev/dri. I think the names are not attached to specific cards but are associated with the order in which you load the DRM drivers. Once both interfaces are present (you can have more than 2 if you like) the Xorg server scans them to find the DRM interface which matches the specific hardware (it seems to scan for up to 16 cards). The first piece of hardware to match an entry in /dev/dri/cardX gets control of the DRI device. All of the other drivers will end up with some message about not being able to get the DRI device.

                    If you build a DRI/DRM device into the kernal its going to get the DRI interface due to the first-come - first-served nature. If you make them both modules, e.g.
                    CONFIG_DRM_I915=m (or I810 or I830)
                    CONFIG_DRM_RADEON=m
                    and so forth for all the other DRM drivers one might want, then its going to be the order in which xorg.conf triggers (attempting to connect the DRI interface with a hardware DRM interface) [with associated module autoloading if they are not already loaded]. Obviously you can configure xorg.conf to *not* use DRI+DRM for one or more pieces of hardware, but otherwise its going to depend on the order in which Xorg tries to open the devices (which in turn depends on you you've arranged them in xorg.conf.

                    It took me a couple of days to figure this out and I don't wish it on anybody.

                    Comment

                    Working...
                    X