Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: [drm] Could not set DRM device bus ID.

  1. #21
    Join Date
    Sep 2008
    Posts
    22

    Default

    Quote 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

  2. #22
    Join Date
    Dec 2007
    Posts
    2,335

    Default

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

  3. #23
    Join Date
    Sep 2008
    Posts
    22

    Default

    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

  4. #24
    Join Date
    Dec 2007
    Posts
    2,335

    Default

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

  5. #25
    Join Date
    Sep 2008
    Posts
    22

    Default dmesg, from drm w/ debug=1

    Quote 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

  6. #26
    Join Date
    Sep 2008
    Posts
    22

    Default

    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.

  7. #27
    Join Date
    Dec 2007
    Posts
    2,335

    Default

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

  8. #28
    Join Date
    Sep 2008
    Posts
    22

    Default

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

  9. #29

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

Posting Permissions

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