5000 series card questions

Sat Apr 10 19:39:22 PDT 2010

On 04/10/2010 08:41 PM, Mark Knecht wrote:
> On Sat, Apr 10, 2010 at 3:48 PM, Dave Witbrodt<dawitbro at sbcglobal.net>  wrote:
>> To sum up, you should try to get the latest possible versions of all of the
>> packages I listed:
>>
>>   - linux kernel built from "drm-radeon-testing" (2.6.32 or 2.6.33), or
>>    (preferably) a release candidate of 2.6.34
>>
>>   - libdrm 2.4.18 or newer (including enabled radeon driver support)
>>
>>   - xorg-server 1.7.5.901 or newer (1.7.6 is out)
>>
>>   - xf86-video-ati 6.13
>>
>> If you give it a try, report the software versions and the kind of connector
>> cables you are using if you have any problems.
>
> Hey Dave,
>     Thanks for the inputs. Very clear. (I think!) ;-) Up front, it
> seems grub is displayed on only one output and I'm using a DVI cable
> to the Syncmaster 2333. I do have an analog monitor but it seems to
> act the same as the 2333. (Goes black)

I assume you mean you've tried them one at a time, not at the same time?

By "analog," do you mean using a VGA (Dsub) connector instead of DVI?

Hmm, it's disappointing when these sort of problems arise.  Try to 
understand that Evergreen support is in very early stages in the 
"radeon" driver and in the kernel DRM -- and by doing this testing and 
reporting you are making an important contribution to improving that 
support.  Just take a look at what "radeon" and "radeonhd" looked like 
on my HD4850 when I first started experimenting with 3D acceleration 
using the open sources drivers last Fall:
     http://bugs.freedesktop.org/attachment.cgi?id=31496

It was supposed to look like this:
     http://bugs.freedesktop.org/attachment.cgi?id=31495

* Yipe! *
(It all got better in a big hurry, BTW.  By late December, _all_ of my 
HD4850 issues were resolved.)

>     Questions up front?
>
> 1) xorg.conf?
> 2) hald?
> 3) dbus?

Do you have an 'xorg.conf' file in '/etc/X11' or thereabouts?  With 
today's X server, it's not unusual for people to have no 'xorg.conf' at all.

You can look at the contents of '/var/log/Xorg.0.log' to determine what 
driver is actually used by X.  I'm not sure what directories Gentoo uses 
for their X drivers, but some grep-fu like this should give us answers 
on any Linux system:

     grep 'drv\.so' /var/log/Xorg.0.log

[HAL and D-Bus should be brought in automatically as dependencies if 
they are needed by any software on your system, whether that is the X 
server or something else.  If your particular distribution doesn't 
depend on them to be able to run X, then AFAIK they should not have any 
impact at all on the Evergreen problems you are having.]

>     OK, Gentoo had a call for stable users to start testing
> xorg-server-1.7 so I've upgraded to 1.7.6.
[...]

> cruncher ~ # equery files libdrm | grep radeon
[...]
> /usr/lib64/libdrm_radeon.la
> /usr/lib64/libdrm_radeon.so
> /usr/lib64/libdrm_radeon.so.1
> /usr/lib64/libdrm_radeon.so.1.0.0

Here's what we wanted to see.  Unless your system is not configured to 
look in '/usr/lib64' for this stuff (very, very unlikely) we can set 
aside all questions about the "libdrm" package.

>     The key results I'm seeing right now are:
>
> 1) Just after entering the interactive part of boot and right around
> the message 'waiting for udev events to be processed' the screen goes
> black and the monitor loses sync. I somehow remember a similar screen
> goes black after udev issue with the I915 but I cannot for the life of
> me remember what the solution was. I'm looking through notes and
> emails. Something about frame buffer devices maybe?

Yeah, if your kernel loads one of the legacy framebuffer drivers, that 
can interfere with the new "radeondrmfb" driver (or the Intel DRM FB 
equivalent) which works with KMS.  You would need to show us more of 
your 'dmesg' output to rule out something like that.

> 2) I somehow think I'm still missing the right drivers. If I ssh in
> and try to start xdm it fails and Xorg.0.log is still telling me 'No
> Devices Detected'
>
>          ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics,
>          ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics,
>          ATI Radeon HD 4200, ATI Radeon 4100, ATI Mobility Radeon HD 4200,
>          ATI Mobility Radeon 4100, ATI Radeon HD 4290, ATI Radeon HD 4290
> (II) Primary Device is: PCI 03 at 00:00:0
> (EE) No devices detected.
>
> Fatal server error:
> no screens found

I don't wish to sound rude here, but it's possible that you have made an 
easy-to-overlook error in getting your system ready to use the open 
source drivers.  Didn't you mention trying to use 'fglrx' drivers in 
earlier messages?  Did you ever attempt to install and use 'fglrx'?

I know you use Gentoo, but take a look at this Debian bug report:
     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538868

Look familiar?

> However radeon is in memory:
>
> cruncher ~ # lsmod
> Module                  Size  Used by
> radeon                633741  0
> ttm                    47515  1 radeon
> drm_kms_helper         23847  1 radeon
> drm                   169899  3 radeon,ttm,drm_kms_helper
> agpgart                30664  2 ttm,drm
[...]

FYI, please be aware that the kernel contains its own Radeon support, 
called a Direct Rendering Manager (DRM), which makes mode setting 
possible for all the system components that might wish to change the 
video mode -- full screen virtual terminals, X server, or anything else. 
  The kernel configuration for this feature is set in a giant text file 
(called '.config') when the kernel is compiled.  If you are using a BASH 
shell, you should get the same (or very similar) output that I do if you 
run the following command:

$ grep  RADEON  /boot/config-$(uname -r)
CONFIG_DRM_RADEON=y
CONFIG_DRM_RADEON_KMS=y
# CONFIG_FB_RADEON is not set

This CONFIG_DRM_RADEON thingy is built directly into my kernel because I 
use a custom kernel configuration and build my own.  However, for all 
the Linux distributions I know of, the kernels are built mostly with 
loadable modules instead of built-in drivers, so you should see 
something like:

CONFIG_DRM_RADEON=m

That means your kernel can load and/or unload that driver, while my 
kernel cannot unload it (the driver is always in memory, and cannot be 
removed).

When the kernel boots, it detects you have a Radeon device and loads the 
appropriate DRM module.  It shows up in your 'lsmod' output as "radeon", 
but it is entirely distinct from the X server "radeon" driver.  (The X 
"radeon" driver asks the kernel DRM_RADEON thingy to do mode changes if 
you are using kernel mode setting [KMS]; if not using KMS, then X uses 
"userspace mode setting" [UMS], and the X "radeon" driver talks directly 
to the hardware to do mode changes.)

This naming issue for kernel drivers is another pitfall for the 
inexperienced.  It's not unusual for the CONFIG* kernel settings to have 
a completely different name from the 'lsmod' driver name which 
corresponds to them!  (It actually seems like a practical joke, sometimes.)

On my Debian system, I have configured a runlevel which allows me to 
boot without X.  If I boot like that, and use a kernel with DRM_RADEON 
compiled as a module (instead of built-in), then I will see that 
"radeon" driver in 'lsmod'.  But X isn't even running!  So that is the 
kernel driver which is running the "radeondrmfb" framebuffer, and which 
responds to requests from software to change video modes.  It is not the 
"radeon" driver from xf86-video-ati used by the X server.

>     Packages you pointed out are shown below.
>
> cruncher ~ # emerge -pv xorg-server xorg-drivers libdrm xf86-video-ati mesa
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> [ebuild   R   ] x11-libs/libdrm-2.4.20  USE="-debug" 0 kB
>
> [ebuild   R   ] media-libs/mesa-7.7.1  USE="nptl xcb -debug (-gallium)
> -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 -mga -none
> -nouveau -r128 -radeonhd -savage -sis (-sunffb) -svga -tdfx -via" 0 kB
>
> [ebuild   R   ] x11-base/xorg-server-1.7.6  USE="hal ipv6 nptl sdl
> xorg -debug -dmx -kdrive -minimal -tslib" 0 kB
>
> [ebuild   R   ] x11-drivers/xf86-video-ati-6.13.0  0 kB
>
> [ebuild   R   ] x11-base/xorg-drivers-1.7  INPUT_DEVICES="evdev
> -acecad -aiptek -joystick -keyboard -mouse -penmount -synaptics -tslib
> -virtualbox -vmmouse -void -wacom" VIDEO_CARDS="fbdev radeon -apm -ark
> -ast -chips -cirrus -dummy -epson -fglrx (-geode) -glint -i128 (-i740)
> (-impact) -intel -mach64 -mga -neomagic (-newport) -nv -nvidia -r128
> -radeonhd -rendition -s3 -s3virge -savage -siliconmotion -sis -sisusb
> (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx)
> -tdfx -tga -trident -tseng -v4l -vesa -via -virtualbox -vmware
> (-voodoo) (-xgi)" 0 kB

Looks good... very good.  Here we see you have a cutting edge libdrm; 
you have Mesa with Radeon support enabled (which doesn't accelerate 
anything on Evergreen cards, yet); you have an up-to-date X server with 
the HAL interface enabled; you have a cutting edge xf86-video-ati 
("radeon") driver; and you have a very intelligent packaging system 
which builds only the input and output drivers you need for your system. 
  (Most Debian users end up with ALL of that driver cruft installed, 
almost all of which they will never touch, unless they take pains to 
remove all of the unneeded ones; but, hey, it works. ;)

> [    6.209896] Linux agpgart interface v0.103
> [    6.219972] mdadm used greatest stack depth: 4168 bytes left
> [    6.257363] [drm] Initialized drm 1.1.0 20060810
> [    6.309372] [drm] radeon defaulting to kernel modesetting.
> [    6.309374] [drm] radeon kernel modesetting enabled.
> [    6.309401]   alloc irq_desc for 30 on node -1
> [    6.309403]   alloc kstat_irqs on node -1
> [    6.309408] radeon 0000:03:00.0: PCI INT A ->  GSI 30 (level, low)
> ->  IRQ 30
> [    6.309410] radeon 0000:03:00.0: setting latency timer to 64
> [    6.310122] [drm] radeon: Initializing kernel modesetting.
> [    6.310272] [drm] register mmio base: 0xFBAC0000
> [    6.310273] [drm] register mmio size: 131072
> [    6.310339] ATOM BIOS: JUNIPER
> [    6.310347] [drm] Clocks initialized !
> [    6.310348] [drm] 1 Power State(s)
> [    6.310349] [drm] State 0 Default (default)
> [    6.310350] [drm]    16 PCIE Lanes
> [    6.310351] [drm]    1 Clock Mode(s)
> [    6.310352] [drm]            0 engine/memory: 850000/1200000
> [    6.310356] [drm] radeon: power management initialized
> [    6.310361] radeon 0000:03:00.0: VRAM: 256M 0x00000000 - 0x0FFFFFFF
> (256M used)
> [    6.310363] radeon 0000:03:00.0: GTT: 512M 0x10000000 - 0x2FFFFFFF
> [    6.310366] mtrr: type mismatch for d0000000,10000000 old:
> write-back new: write-combining
> [    6.310368] [drm] Detected VRAM RAM=256M, BAR=256M
> [    6.310368] [drm] RAM width 128bits DDR
> [    6.310392] [TTM] Zone  kernel: Available graphics memory: 6163198 kiB.
> [    6.310394] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
> [    6.310400] [drm] radeon: 256M of VRAM memory ready
> [    6.310401] [drm] radeon: 512M of GTT memory ready.
> [    6.311701] [drm] Radeon Display Connectors
> [    6.311702] [drm] Connector 0:
> [    6.311703] [drm]   DisplayPort
> [    6.311704] [drm]   HPD4
> [    6.311705] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448
> 0x644c 0x644c
> [    6.311706] [drm]   Encoders:
> [    6.311707] [drm]     DFP1: INTERNAL_UNIPHY2
> [    6.311708] [drm] Connector 1:
> [    6.311708] [drm]   HDMI-A
> [    6.311709] [drm]   HPD5
> [    6.311710] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438
> 0x643c 0x643c
> [    6.311711] [drm]   Encoders:
> [    6.311712] [drm]     DFP2: INTERNAL_UNIPHY2
> [    6.311713] [drm] Connector 2:
> [    6.311713] [drm]   DVI-I
> [    6.311714] [drm]   HPD1
> [    6.311715] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468
> 0x646c 0x646c
> [    6.311716] [drm]   Encoders:
> [    6.311717] [drm]     DFP3: INTERNAL_UNIPHY1
> [    6.311717] [drm]     CRT2: INTERNAL_KLDSCP_DAC2
> [    6.311718] [drm] Connector 3:
> [    6.311719] [drm]   DVI-I
> [    6.311719] [drm]   HPD6
> [    6.311721] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458
> 0x645c 0x645c
> [    6.311722] [drm]   Encoders:
> [    6.311722] [drm]     DFP4: INTERNAL_UNIPHY
> [    6.311723] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> [    6.660144] [drm] fb mappable at 0xD0040000
> [    6.660145] [drm] vram apper at 0xD0000000
> [    6.660146] [drm] size 8294400
> [    6.660147] [drm] fb depth is 24
> [    6.660148] [drm]    pitch is 7680
> [    6.660171] fb0: radeondrmfb frame buffer device
> [    6.660172] registered panic notifier
> [    6.660174] [drm] Initialized radeon 2.1.0 20080528 for
> 0000:03:00.0 on minor 0

This partial 'dmesg' output seems to indicate that KMS loaded OK. 
Assuming that there weren't bad things happening after this part of the 
boot process, then right now...

*** WARNING ***
I am not a developer, just a noob user like you, and everything you are 
about to read should be viewed with suspicion and rejected utterly upon 
the first sign of evidence contradicting it
*** END WARNING ***

... it looks like you were using 'fglrx' earlier, and it left cruft on 
your system which is now interfering with the X server trying to use the 
open source "radeon" driver.  If X crashes hard when trying to load, it 
could be leaving you with a black screen instead of falling back to the 
full screen virtual terminal login prompt.

If that is not the explanation of your black screen issue, then it is 
some deeper problem, like the black screen issues I had with my HD5750 
when trying to use the keyboard/video/mouse switch, or the purple 
vertical line I get when using the HDMI cable.

BTW...

On my Debian system, it is normal for the kernel to spew tons of text 
until the display manager finally loads, at which point the screen goes 
blank and a graphical login prompt appears.  On my friend's Ubuntu 
system, even though Ubuntu is Debian-based, they take pains to make sure 
that few (or none) of those boot messages appear:  they switch to 
graphics mode early in boot, and the typical Ubuntu user never sees 
anything but graphics modes unless something like the display manager or 
the X server crashes.

How does it work (normally) on Gentoo?  When you have had a working 
system in the past, does it spew text boot messages until the login 
prompt comes up in graphics mode, or does it switch to graphics mode 
very early in boot?

HTH,
Dave W.