Curious experiences with a Radeon on the fritz

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I hope you find this adventure interesting, and I hope you
provide me with some insight.

Recently, I booted my computer, a Dell Latitude D810 that has a
Radeon Mobility x600 (R300); all systems were waking up as normal:

  * The Dell logo popped up in some ancient VGA mode.
  * The GRUB menu appeared for 3 seconds as instructed.
  * Linux loaded and started spewing out log messages.

and then:

    BAM!

At around:

  2011-09-09 20:27:07 +0000

the Darkness overcame me; my laptop's LCD panel went black with nary
a sign of life. After poking around a bit via ssh, I couldn't figure
out what was going on; I had been running all the relevant code
without trouble for some time now, so it just didn't make sense, and
I began suspecting hardware failure.

I strolled on over to freenode/#radeon, where I explained that I was
still getting graphics at early boot time, but that it was dying
shortly after Linux loaded. A one named Tari suggested that I boot
with `nomodeset' in order to avoid anything more complicated than
the standards of the Ancients.

And Lo! With that very kernel command line parameter, the boot
process did indeed land me safely in a working, albeit cramped
VGA-backed virtual console.

Searching the logs a bit more revealed the following:

  [drm:drm_calc_timestamping_constants] *ERROR* crtc 10: Can't
  calculate constants, dotclock = 0!

Then (skipping a few interesting adventures), I ultimately discovered
this kernel message:

  [drm] Panel Size 1920x4095

which is curious indeed!, because my laptop's panel size should be
`1920x1200'. I booted into the computer's BIOS only to find that
it too was being fooled into thinking that the display dimensions
are `1920x4095'.

Why might this have happened? Are bits stuck? Did something get fried?

Naturally, I set off to hardcode the right values into the DRM/KMS
Radeon driver, and after overturning stones, scraping away ivy,
digging tunnels, and wading through forgotten moats, I managed to
make my way to the beginning of that labyrinthine beast, where I
could successfully exert my will:

  diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c
  index 6367524..9119dd6 100644
  --- a/drivers/gpu/drm/radeon/radeon_combios.c
  +++ b/drivers/gpu/drm/radeon/radeon_combios.c
  @@ -1245,7 +1245,7 @@ struct radeon_encoder_lvds *radeon_combios_get_lvds_info(struct radeon_encoder
   		DRM_INFO("Panel ID String: %s\n", stmp);
   
   		lvds->native_mode.hdisplay = RBIOS16(lcd_info + 0x19);
  -		lvds->native_mode.vdisplay = RBIOS16(lcd_info + 0x1b);
  +		lvds->native_mode.vdisplay = 1200; /*RBIOS16(lcd_info + 0x1b);*/
   
   		DRM_INFO("Panel Size %dx%d\n", lvds->native_mode.hdisplay,
   			 lvds->native_mode.vdisplay);

With that small change, the driver in question loaded none the wiser,
yielding a KMS-driven frame-buffer-backed virtual console as desired:

  [drm] radeon defaulting to kernel modesetting.
  [drm] radeon kernel modesetting enabled.
  ...
  [drm] Panel Size 1920x1200
  ...
  [drm] fb depth is 24
  [drm]    pitch is 7680
  fbcon: radeondrmfb (fb0) is primary device
  Console: switching to colour frame buffer device 240x75
  fb0: radeondrmfb frame buffer device

Unfortunately, X marks the spot where things get hairy again.

Most noticeably, when I run:

  startx

I get an Xorg.log that looks unblemished, yet X clearly renders the
screen based on an erroneous DPI. In fact, even though Xorg.log
clearly shows:

  (**) RADEON(0): Display dimensions: (331, 207) mm
  (**) RADEON(0): DPI set to (147, 147)

I end up getting the following from xdpyinfo:

  dimensions:    1920x1200 pixels (507x317 millimeters)
  resolution:    96x96 dots per inch

Why is this the case?

Fortunately, I can solve the DPI issue by specifying the desired
value directly on the command line:

  startx -- -dpi 147

Why does this work when xorg.conf does not? (especially given that
xorg.conf alone used to be enough to achieve the desired effect).

Unfortunately, the troubles do not end there. Rudimentary benchmarking
(playing 720p H.264 videos, running glxgears, etc.) indicates by low
CPU usage that hardware acceleration is indeed enabled, which is in
agreement with all the logs and diagnostics:

  Linux:

    [drm] radeon: 128M of VRAM memory ready
    [drm] radeon: 512M of GTT memory ready.
    ...
    [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
    [drm] PCIE GART of 512M enabled (table at 0xD0040000).

  Xorg:

    (II) [KMS] Kernel modesetting enabled.
    ...
    (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
    (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
    (==) RADEON(0): Default visual is TrueColor
    (==) RADEON(0): RGB weight 888
    (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
    (--) RADEON(0): Chipset: "ATI Radeon Mobility X600 (M24) 3150 (PCIE)" (ChipID = 0x3150)
    ...
    (II) RADEON(0): KMS Color Tiling: enabled
    (II) RADEON(0): KMS Pageflipping: enabled
    (II) RADEON(0): SwapBuffers wait for vsync: enabled
    ...
    (++) RADEON(0): DPI set to (147, 147)
    ...
    (II) RADEON(0): [DRI2] Setup complete
    (II) RADEON(0): [DRI2]   DRI driver: r300
    ...
    (II) RADEON(0): Direct rendering enabled
    (II) RADEON(0): Render acceleration enabled for R300/R400/R500 type cards.
    ...
    (II) EXA(0): Driver allocated offscreen pixmaps
    (II) EXA(0): Driver registered support for the following operations:
    (II)         Solid
    (II)         Copy
    (II)         Composite (RENDER acceleration)
    (II)         UploadToScreen
    (II)         DownloadFromScreen
    (II) RADEON(0): Acceleration enabled
    (==) RADEON(0): DPMS enabled
    (==) RADEON(0): Silken mouse enabled
    (II) RADEON(0): Set up textured video
    (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message.
    (--) RandR disabled
    ...
    (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
    (II) AIGLX: enabled GLX_INTEL_swap_event
    (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
    (II) AIGLX: enabled GLX_SGI_make_current_read
    (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
    (II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/r300_dri.so
    (II) GLX: Initialized DRI2 GL provider for screen 0
    (II) RADEON(0): Setting screen physical size to 331 x 207

  glxinfo:

    direct rendering: Yes

However, within at least some colors, window locations, and so on,
there is this strange but subtle flickering and subtle striation.
The mouse kind of jitters about rather than moving smoothly; the
frame rate seems too low, a fact that is confirmed by glxgears:

  $ glxgears
  Running synchronized to the vertical refresh.  The framerate should
  be approximately the same as the monitor refresh rate.
  99 frames in 5.0 seconds = 19.628 FPS
  97 frames in 5.0 seconds = 19.285 FPS
  97 frames in 5.0 seconds = 19.285 FPS
  97 frames in 5.0 seconds = 19.285 FPS
  97 frames in 5.0 seconds = 19.285 FPS
  97 frames in 5.0 seconds = 19.285 FPS

Note that while running glxgears, the CPU is hardly used at all, so
the GPU is pulling its weight. (In contrast, when hardware acceleration
is disabled, the CPU gets pegged at 100%, but more importantly, the FPS
is no longer synchronized to the vertical refresh rate, so it actually
becomes higher (at around 26 FPS), though there are still the same
problems of flickering and striation).

Thus, the vertical refresh rate is in fact the bottleneck. Consider
these:

  Xorg:

    (II) RADEON(0): Printing probed modes for output LVDS
    (II) RADEON(0): Modeline "1920x1200"x9.4  162.00  1920 2016 2072 2160  1200 49753 49756 7985 (75.0 kHz)
    ...
    (II) RADEON(0): Output LVDS using initial mode 1920x1200

  xrandr --verbose:

    1920x1200 (0x55)  162.0MHz *current +preferred
          h: width  1920 start 2016 end 2072 total 2160 skew    0 clock   75.0KHz
          v: height 1200 start 49753 end 49756 total 7985           clock    9.4Hz

That's right: A vertical refresh of 9.4Hz! You can see from the
vertical `start', `end', and `total' numbers in the xrandr output
that something really bizarre is going on (there are other wrong
data besides just the panel height).

Is the striation from some kind of interlacing? (after all, 9.4*2 Hz
is ALMOST near the FPS reported by glxgears).

What other bits can I hardcode in the software? What might be failing?

Interestingly, Xorg.conf and xrandr report other, seemingly correct
modelines (which I assume are supplied by built-in alternatives):

  Xorg:
  
    (II) RADEON(0): Printing probed modes for output LVDS
    (II) RADEON(0): Modeline "1920x1200"x9.4  162.00  1920 2016 2072 2160  1200 49753 49756 7985 (75.0 kHz)
    (II) RADEON(0): Modeline "1920x1080"x60.0  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync (67.2 kHz)
    (II) RADEON(0): Modeline "1600x1200"x59.9  161.00  1600 1712 1880 2160  1200 1203 1207 1245 -hsync +vsync (74.5 kHz)
    (II) RADEON(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
    (II) RADEON(0): Modeline "1400x1050"x60.0  121.75  1400 1488 1632 1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz)
    (II) RADEON(0): Modeline "1280x1024"x59.9  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync (63.7 kHz)
    (II) RADEON(0): Modeline "1440x900"x59.9  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync (55.9 kHz)
    (II) RADEON(0): Modeline "1280x960"x59.9  101.25  1280 1360 1488 1696  960 963 967 996 -hsync +vsync (59.7 kHz)
    (II) RADEON(0): Modeline "1280x854"x59.9   89.25  1280 1352 1480 1680  854 857 867 887 -hsync +vsync (53.1 kHz)
    (II) RADEON(0): Modeline "1280x800"x59.8   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz)
    (II) RADEON(0): Modeline "1280x720"x59.9   74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync (44.8 kHz)
    (II) RADEON(0): Modeline "1152x768"x59.8   71.75  1152 1216 1328 1504  768 771 781 798 -hsync +vsync (47.7 kHz)
    (II) RADEON(0): Modeline "1024x768"x59.9   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync (47.8 kHz)
    (II) RADEON(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603 607 624 -hsync +vsync (37.4 kHz)
    (II) RADEON(0): Modeline "848x480"x59.7   31.50  848 872 952 1056  480 483 493 500 -hsync +vsync (29.8 kHz)
    (II) RADEON(0): Modeline "720x480"x59.7   26.75  720 744 808 896  480 483 493 500 -hsync +vsync (29.9 kHz)
    (II) RADEON(0): Modeline "640x480"x59.4   23.75  640 664 720 800  480 483 487 500 -hsync +vsync (29.7 kHz)
    ...
    (II) RADEON(0): Output LVDS using initial mode 1920x1200

  xrandr:

    1920x1200 (0x55)  162.0MHz +preferred
          h: width  1920 start 2016 end 2072 total 2160 skew    0 clock   75.0KHz
          v: height 1200 start 49753 end 49756 total 7985           clock    9.4Hz
    1920x1080 (0x56)  173.0MHz -HSync +VSync
          h: width  1920 start 2048 end 2248 total 2576 skew    0 clock   67.2KHz
          v: height 1080 start 1083 end 1088 total 1120           clock   60.0Hz
    1600x1200 (0x57)  161.0MHz -HSync +VSync
          h: width  1600 start 1712 end 1880 total 2160 skew    0 clock   74.5KHz
          v: height 1200 start 1203 end 1207 total 1245           clock   59.9Hz
    1680x1050 (0x58)  146.2MHz -HSync +VSync
          h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
          v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
    1400x1050 (0x59)  121.8MHz -HSync +VSync
          h: width  1400 start 1488 end 1632 total 1864 skew    0 clock   65.3KHz
          v: height 1050 start 1053 end 1057 total 1089           clock   60.0Hz
    1280x1024 (0x5a)  109.0MHz -HSync +VSync
          h: width  1280 start 1368 end 1496 total 1712 skew    0 clock   63.7KHz
          v: height 1024 start 1027 end 1034 total 1063           clock   59.9Hz
    1440x900 (0x5b)  106.5MHz -HSync +VSync
          h: width  1440 start 1528 end 1672 total 1904 skew    0 clock   55.9KHz
          v: height  900 start  903 end  909 total  934           clock   59.9Hz
    1280x960 (0x5c)  101.2MHz -HSync +VSync
          h: width  1280 start 1360 end 1488 total 1696 skew    0 clock   59.7KHz
          v: height  960 start  963 end  967 total  996           clock   59.9Hz
    1280x854 (0x5d)   89.2MHz -HSync +VSync
          h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   53.1KHz
          v: height  854 start  857 end  867 total  887           clock   59.9Hz
    1280x800 (0x5e)   83.5MHz -HSync +VSync
          h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
          v: height  800 start  803 end  809 total  831           clock   59.8Hz
    1280x720 (0x5f)   74.5MHz -HSync +VSync
          h: width  1280 start 1344 end 1472 total 1664 skew    0 clock   44.8KHz
          v: height  720 start  723 end  728 total  748           clock   59.9Hz
    1152x768 (0x60)   71.8MHz -HSync +VSync
          h: width  1152 start 1216 end 1328 total 1504 skew    0 clock   47.7KHz
          v: height  768 start  771 end  781 total  798           clock   59.8Hz
    1024x768 (0x61)   63.5MHz -HSync +VSync
          h: width  1024 start 1072 end 1176 total 1328 skew    0 clock   47.8KHz
          v: height  768 start  771 end  775 total  798           clock   59.9Hz
    800x600 (0x62)   38.2MHz -HSync +VSync
          h: width   800 start  832 end  912 total 1024 skew    0 clock   37.4KHz
          v: height  600 start  603 end  607 total  624           clock   59.9Hz
    848x480 (0x63)   31.5MHz -HSync +VSync
          h: width   848 start  872 end  952 total 1056 skew    0 clock   29.8KHz
          v: height  480 start  483 end  493 total  500           clock   59.7Hz
    720x480 (0x64)   26.8MHz -HSync +VSync
          h: width   720 start  744 end  808 total  896 skew    0 clock   29.9KHz
          v: height  480 start  483 end  493 total  500           clock   59.7Hz
    640x480 (0x65)   23.8MHz -HSync +VSync
          h: width   640 start  664 end  720 total  800 skew    0 clock   29.7KHz
          v: height  480 start  483 end  487 total  500           clock   59.4Hz

However, switching to one of these other modes or defining my own
through xorg.conf does nothing to fix the troubles; while the
resolution does change, the flickering and striation remain, and
glxgears continues to report the same 19+ FPS.

Is there anything that can be done to work around these last
troubles?

Sincerely,
Michael Witten

P.S.

I'm running i686 Linux 3.1.0-rc5, specifically this commit
(with my patch):

  473e2bc9d3649e072d0a1bff84afa95b072d056b

and:

  X.Org X Server 1.10.3.901 (1.10.4 RC 1)
  Release Date: 2011-07-29
  X Protocol Version 11, Revision 0
  Kernel command line: root=/dev/sda2 ro 3
  Build Date: 08 August 2011  08:28:07AM
  Current version of pixman: 0.22.2
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux