Announcement

Collapse
No announcement yet.

Slackware-13.1 & Radeon Graphics

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

  • #11
    Restarting X with the radeon module loaded is fatal - kernel oops 0000 [#1]
    As I had an ssh session open it threw some output there
    Message from syslogd@genius at Tue Aug 31 15:33:25 2010 ...
    genius kernel: Process X (pid: 1830, ti=f6536000 task=f7997b20
    task.ti=f6536000)
    Message from syslogd@genius at Tue Aug 31 15:33:25 2010 ...
    genius kernel: Stack:

    Message from syslogd@genius at Tue Aug 31 15:33:25 2010 ...
    genius kernel: Code: 31 81 b8 90 00 00 00 34 2f 00 00 8b 90 dc 02 00 00
    77 4f 8b 98 94 00 00 00 b9 34 2f 00 00 89 0b 8b 88 94 00 00 00 31 c0 89
    41 04 <8b> 02 5b 5d c3 66 90 81 b8 90 00 00 00 80 54 00 00 77 34 8b 88

    Message from syslogd@genius at Tue Aug 31 15:33:25 2010 ...
    genius kernel: EIP: [<f8c78369>] r600_ioctl_wait_idle+0x39/0xa0 [radeon]
    SS:ESP
    0068:f6537df4

    Message from syslogd@genius at Tue Aug 31 15:33:25 2010 ...
    genius kernel: CR2: 0000000000000000

    I wasn't in an xterm, so that's only a screenful, but I think the most meaningful chunk.

    /var/log/Xorg.0.log for the same session loaded exa, and gave the line
    (II) RADEON(0): [DRI"] Setup complete
    as the last line in an error free log.

    Comment


    • #12
      OK, so I'm guessing everyone would agree that there is a kernel bug here. This may now be out of my league. You could try building newer kernel from git to see if the problem persists. Other than that, I really have no suggestions :-)

      Adam

      Comment


      • #13
        that issue is already fixed. either disable AGP (radeon.agpmode=-1), or apply the patch here:

        Comment


        • #14
          Originally posted by adamk View Post
          The version mismatch probably means that the version of xf86-video-ati you are using (are you still using the 13.1 version?) wasn't built with KMS support.

          Let me try and get an understanding of the state of your machine in terms of installed software. Are you currently using standard Slackware 13.1 + 2.6.35.4 from robbie? Is there anything else you updated that isn't stock 13.1?

          Adam
          NO. I am being very restrained about that. Standard Slackware-13.1 with no additions. 2.6.35.4 is throwing up a few inconsistencies, however. I had to 'make vmlinux' to see what was rolling up the screen, something about inconsistencies. The output suggested mismatches, & setting some variable, so I did a make clean and
          make -j4 "CONFIG_SECTION_MISMATCH=1" >build.log 2>&1
          I don't know when someone last looked at this o/p, but the wifi section is in a heap. Some details closer to home

          LD arch/x86/pci/built-in.o
          WARNING: arch/x86/pci/built-in.o(.text+0x13cd): Section mismatch in reference from the function pcibios_scan_specific_bus() to the function .d
          evinit.textci_scan_bus_on_node()
          The function pcibios_scan_specific_bus() references
          the function __devinit pci_scan_bus_on_node().
          This is often because pcibios_scan_specific_bus lacks a __devinit
          annotation or the annotation of pci_scan_bus_on_node is wrong.

          drivers/gpu/drm/radeon/radeon_atombios.c: In function 'radeon_atom_get_hpd_info_from_gpio':
          drivers/gpu/drm/radeon/radeon_atombios.c:199: warning: 'hpd.plugged_state' is used uninitialized in this function

          LD vmlinux.o
          MODPOST vmlinux.o
          WARNING: vmlinux.o(.text+0x2d865d): Section mismatch in reference from the function pcibios_scan_specific_bus() to the function .devinit.textci_scan_bus_on_node()
          The function pcibios_scan_specific_bus() references
          the function __devinit pci_scan_bus_on_node().
          This is often because pcibios_scan_specific_bus lacks a __devinit
          annotation or the annotation of pci_scan_bus_on_node is wrong.
          /usr/src/linux-2.6.35.4/usr/include/drm/drm_mode.h:84: found __[us]{8,16,32,64} type without #include <linux/types.h>
          /usr/src/linux-2.6.35.4/usr/include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include <linux/types.h>
          CHECK include/linux/byteorder (2 files)
          /usr/src/linux-2.6.35.4/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include <linux/types.h>
          CHECK include/rdma (1 files)
          /usr/src/linux-2.6.35.4/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include <linux/types.h>
          /usr/src/linux-2.6.35.4/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include <linux/types.h>

          Now I know builds generally nag, so unless any of that is in a touchy area we can ignore it. Which leaves you guys with a known good box, holding a new radeon card which is throwing a kernel oops if the sun goes behind a cloud on the most recent sources. For repeatability's sake, the exact config I used is 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.


          It is robbie's with intel specific options and unnecessary modules not built.

          Comment


          • #15
            It appears to be in the agp. Disabling agp (radeon.agpmode=-1) ran X fairly freely. Any variation in agp settings (8x, fast writes enabled) is fatal. Those settings produce these errors (from startx > x.err 2>&1)
            (==) Using config file: "/etc/X11/xorg.conf"
            (II) [KMS] drm report modesetting isn't supported.
            (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
            [dri] This chipset requires a kernel module version of 1.17.0,
            [dri] but the kernel reports a version of 2.5.0.[dri] If using legacy modesetting, upgrade your kernel.
            [dri] If using kernel modesetting, make sure your module is
            [dri] loaded prior to starting X, and that this driver was built
            [dri] with support for KMS.
            [dri] Disabling DRI.
            ...
            (EE) RADEON(0): Acceleration initialization failed
            Output UNIPHY1 transmitter setup success
            Output CRT2 disable success
            loading X with radeon module loaded is fatal.

            Comment


            • #16
              make sure the radeon drm kernel modules is loaded prior to starting X.

              Comment


              • #17
                Originally posted by agd5f View Post
                that issue is already fixed. either disable AGP (radeon.agpmode=-1), or apply the patch here:
                http://lists.freedesktop.org/archive...st/003373.html

                This is not a full cure, but a great step forward.
                I patched 2.6.35.4 & built this, and I can jump to console mode & back to X without freaking the kernel, glxinfo reports
                OpenGL renderer string: Mesa DRI R600 (RV730 9495) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2
                which is comlicated enough to be believable.

                Caveats are: Random oops can happen on startup (without module loaded) or on shutdown. I'm running 64 console-kit-dae processes(!!), and finally all the output to 'startx > file 2>&1' is cut with the radeon module loaded, so I actually get no meaningful o/p.

                I'm going to thank you guys for your attention, clear off and try to use this thing as it is. I will post afresh if it is meaningfully broken.

                Comment


                • #18
                  Originally posted by business_kid View Post
                  Caveats are: Random oops can happen on startup (without module loaded) or on shutdown.
                  Sounds like a kernel bug. Might want to report that upstream.

                  Comment


                  • #19
                    Originally posted by agd5f View Post
                    Sounds like a kernel bug. Might want to report that upstream.
                    I will, if I can get anything useful to say. 'Sometimes crashes somewhere' isn't much use to anyone. I have also spent 2 days in confusion here and want to come up for air. I've been scanning Xorg.0.log and startx > file outputs without getting much of a hint of what it is. For family reasons I have to be seen logged out from this box :-/.

                    Comment

                    Working...
                    X