Announcement

Collapse
No announcement yet.

[drm] Could not set DRM device bus ID.

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

  • #16
    Kernel Developers comments

    I sent a kernel developer a snippet of my Xorg log and asked his opinion.
    ************
    Here is a dusty issue I've brought to the ATI driver board.
    I'm just trying to understand if the via chipset support
    is where I should pursuit this issue, or strictly the
    X radeon driver folks. Or, some other.

    My MVP3 chipset board will does not allow my ATI r2xx video
    adapter to use DRI. The X log simply shows:
    *************

    He sent a brief reply. It might be helpful.

    **************
    Without looking to deeply into it, it looks like drmOpenDevice opens /dev/dri/card0 and then tries to set the busID of that device. That fails, probably because that's the VIA device. drmOpenDevice should then try /dev/dri/card1, but it doesn't. Also a little suspicious is the drmBetBusid return.

    So the issue is probably either in core drm or in libdrm.
    *******************

    Comment


    • #17
      Can you pastebin dmesg as well please ?

      Comment


      • #18
        pastebin of dmesg

        Originally posted by bridgman View Post
        Can you pastebin dmesg as well please ?
        Yup, sorry I was futzing around a bit.


        http://pastebin.com/m666d0546

        Comment


        • #19
          This is another hint from a kernel developer that responded.
          >
          > (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0
          > .....
          > drmGetBusid returned ''
          > (II) [drm] DRM interface version 1.0
          > (EE) [drm] Could not set DRM device bus ID.
          > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI.

          Weird... maybe some process is keeping the DRM device open, does

          sudo lsof /dev/dri/card0

          give any results when the X server isn't running? If not, check out the kernel output; if it doesn't seem to have anything relevant, try writing 1 to /sys/modul /drm/parameters/debug before starting the X server.
          FYI running the lsof /dev/dri/card0, did nothing at all.

          I don't know what he means by "try writing 1 to /sys/modul /drm/parameters/debug". If someone helps me decipher this request, I'll try it. Thanks.

          Comment


          • #20
            Originally posted by User0x45 View Post
            This is another hint from a kernel developer that responded.


            FYI running the lsof /dev/dri/card0, did nothing at all.

            I don't know what he means by "try writing 1 to /sys/modul /drm/parameters/debug". If someone helps me decipher this request, I'll try it. Thanks.
            (as root)
            echo 1 > /sys/module/drm/parameters/debug

            or when loading the drm module before starting X:
            modprobe drm debug=1

            Comment


            • #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

                  http://pastebin.com/m40f16ee

                  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:
                      http://pastebin.com/m7d05c424

                      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