Announcement

Collapse
No announcement yet.

Crash hunting in Radeon KMS

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

  • #11
    Originally posted by Neuro View Post
    codestation, nice one with the trace

    Are you getting that under KDE 4.4? Are you loosing monitor signal? It's a bit awkward because I ceased to get kernel logs in syslog after I moved to kernel 2.6.33- in february.

    Cheers,
    Michal
    Yes, i am using 4.4 but i dont think that is related because i was getting the panic/freeze with 4.3.x too. And yes, sometimes i lose the monitor signal while other times i got kicked back to console then the system freeze.

    BTW, i dont know if is related but any of you is getting the rare case of a system freeze just when the radeon module is loaded, while trying to switch to KMS in the early boot? (it corrupts the screen so i cant see any possible messages printed to it). I can even get a backtrace because netconsole stops sending messages after init is started

    Comment


    • #12
      This is with crystalspace walktest-1.9:
      Code:
      Mar 13 15:44:25 gentoo kernel: [ 9588.479510] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation !
      Mar 13 15:44:25 gentoo kernel: [ 9588.488152] kernel BUG at drivers/gpu/drm/radeon/radeon_object.c:464!
      Mar 13 15:44:25 gentoo kernel: [ 9588.488289]  [<ffffffff8124b7e2>] ? drm_mm_split_at_start+0x17/0x6d
      Mar 13 15:44:25 gentoo kernel: [ 9588.488324]  [<ffffffff81243c7c>] ? drm_ioctl+0x224/0x2fc
      Mar 13 15:44:25 gentoo kernel: [ 9588.509389] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:159 radeon_fence_signaled+0x61/0x90()
      Mar 13 15:44:25 gentoo kernel: [ 9588.509474]  [<ffffffff81243c7c>] ? drm_ioctl+0x224/0x2fc
      Fortunately it no longer hangs the system.

      I think there are also some "little" problems with power management
      This is while running the walktest:
      Code:
      [...]
      Mar 13 15:44:16 gentoo kernel: [ 9579.529020] [drm] Requested: e: 30000 m: 112600 p: 16
      Mar 13 15:44:16 gentoo kernel: [ 9579.728024] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:16 gentoo kernel: [ 9579.728028] [drm] Setting: e: 30000 m: 112600 p: 16
      Mar 13 15:44:16 gentoo kernel: [ 9579.728159] [drm] not in vbl for pm change 00020002 00000000 at exit
      Mar 13 15:44:18 gentoo kernel: [ 9581.531023] [drm] Requested: e: 77600 m: 112600 p: 16
      Mar 13 15:44:18 gentoo kernel: [ 9581.731024] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:18 gentoo kernel: [ 9581.731028] [drm] Setting: e: 77600 m: 112600 p: 16
      Mar 13 15:44:18 gentoo kernel: [ 9581.731156] [drm] not in vbl for pm change 00020002 00000000 at exit
      Mar 13 15:44:18 gentoo kernel: [ 9582.132026] [drm] Requested: e: 30000 m: 112600 p: 16
      Mar 13 15:44:19 gentoo kernel: [ 9582.332025] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:19 gentoo kernel: [ 9582.332029] [drm] Setting: e: 30000 m: 112600 p: 16
      Mar 13 15:44:19 gentoo kernel: [ 9582.332159] [drm] not in vbl for pm change 00010002 00000000 at exit
      Mar 13 15:44:19 gentoo kernel: [ 9582.834019] [drm] Requested: e: 77600 m: 112600 p: 16
      Mar 13 15:44:19 gentoo kernel: [ 9583.033025] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:19 gentoo kernel: [ 9583.033029] [drm] Setting: e: 77600 m: 112600 p: 16
      Mar 13 15:44:19 gentoo kernel: [ 9583.033157] [drm] not in vbl for pm change 00010002 00000000 at exit
      Mar 13 15:44:20 gentoo kernel: [ 9583.933036] [drm] Requested: e: 30000 m: 112600 p: 16
      Mar 13 15:44:20 gentoo kernel: [ 9584.133025] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:20 gentoo kernel: [ 9584.133029] [drm] Setting: e: 30000 m: 112600 p: 16
      Mar 13 15:44:20 gentoo kernel: [ 9584.133160] [drm] not in vbl for pm change 00050002 00000000 at exit
      Mar 13 15:44:21 gentoo kernel: [ 9584.633931] [drm] Requested: e: 77600 m: 112600 p: 16
      Mar 13 15:44:21 gentoo kernel: [ 9584.833025] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:21 gentoo kernel: [ 9584.833029] [drm] Setting: e: 77600 m: 112600 p: 16
      Mar 13 15:44:21 gentoo kernel: [ 9584.833157] [drm] not in vbl for pm change 00020002 00000000 at exit
      Mar 13 15:44:22 gentoo kernel: [ 9585.334028] [drm] Requested: e: 30000 m: 112600 p: 16
      Mar 13 15:44:22 gentoo kernel: [ 9585.533022] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:22 gentoo kernel: [ 9585.533026] [drm] Setting: e: 30000 m: 112600 p: 16
      Mar 13 15:44:22 gentoo kernel: [ 9585.533156] [drm] not in vbl for pm change 00020002 00000000 at exit
      Mar 13 15:44:23 gentoo kernel: [ 9586.634016] [drm] Requested: e: 77600 m: 112600 p: 16
      Mar 13 15:44:23 gentoo kernel: [ 9586.833026] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:23 gentoo kernel: [ 9586.833029] [drm] Setting: e: 77600 m: 112600 p: 16
      Mar 13 15:44:23 gentoo kernel: [ 9586.833158] [drm] not in vbl for pm change 00020002 00000000 at exit
      Mar 13 15:44:24 gentoo kernel: [ 9587.333026] [drm] Requested: e: 30000 m: 112600 p: 16
      Mar 13 15:44:24 gentoo kernel: [ 9587.533025] [drm] not in vbl for pm change 00020002 00000000 at entry
      Mar 13 15:44:24 gentoo kernel: [ 9587.533028] [drm] Setting: e: 30000 m: 112600 p: 16
      Mar 13 15:44:24 gentoo kernel: [ 9587.533159] [drm] not in vbl for pm change 00020002 00000000 at exit
      [...]
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #13
        I'm getting crashes in Gnome (Lucid, xorg-edgers) whenever I use KMS. Time from boot to crash is totally random, from several minutes to several hours, even days... Crash is rock solid. It used to be a freeze, but now, they are real crashes. With freezes Ctrl-Alt-SysRq-B helped, now only Reset on PC-case helps... If I boot in UMS, no crashes. It happens in 2.6.32-16-{generic,preempt}, 2.6.34-999...

        Comment


        • #14
          Originally posted by zika View Post
          I'm getting crashes in Gnome (Lucid, xorg-edgers) whenever I use KMS. Time from boot to crash is totally random, from several minutes to several hours, even days... Crash is rock solid. It used to be a freeze, but now, they are real crashes. With freezes Ctrl-Alt-SysRq-B helped, now only Reset on PC-case helps... If I boot in UMS, no crashes. It happens in 2.6.32-16-{generic,preempt}, 2.6.34-999...
          Forgot to say:ASUS AH3650 a.k.a. ATI Radeon HD 3650 512M

          Comment


          • #15
            I've, just now, ppa-purge(d) xorg-edgers to see if that will clear the problem with crashes in KMS. Maybe that will give useful insight...?

            Comment


            • #16
              6.12.5 doesn't work for me (no signal), 6.12.191 from x11 overlay works fine with 2.6.33-zen1 and AMD ucode firmware in the kernel.


              With 6.12.5: I don't boot into X and KMS for frambuffer works just fine. As soon as I start X it freezes. fbdev works fine...

              Comment


              • #17
                I don't think KMS support is in the 6.12 branch, only in 6.13 (or 6.12.191).

                Comment


                • #18
                  Oh, thanks for the info
                  I actual thought from the number, that 6.12.5 would be the candidate for 6.13...

                  Originally posted by http://www.x.org/wiki/radeon
                  2 Mar 2010: 6.12.191: pre-release for the upcoming 6.13 release: KMS/DRI2 support, support for new hardware, basic power management, Displayport. [ changelog ]

                  2 Mar 2010: 6.12.5: bug fix release. [ changelog ]
                  p.s. still can't play sauerbraten/sacred on my hd4770

                  Comment


                  • #19
                    Yeah, I always found that naming convention confusing... but X drivers seem to use one convention (eg staying with 6.12.xxx in mainline until 6.13 is actually released) and mesa drivers use another (mainline builds have the version number that will be used for the eventual release).

                    I like the mesa approach better - not sure what it would take to change the way X drivers are versioned.

                    Comment


                    • #20
                      After I went back from xorg-edgers to "Lucid-offical" set of drivers etc. I did not have a single crash in KMS. So, there is something in that difference-set that makes Lucid to crash, at least on my machine...

                      Comment

                      Working...
                      X