On 04/10/2010 08:41 PM, Mark Knecht wrote:
On Sat, Apr 10, 2010 at 3:48 PM, Dave Witbrodt<[email protected]> 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 0...@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.
_______________________________________________
xorg-driver-ati mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-driver-ati
