FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Rep:
ATI card and compositing support?
Just got a VisionTek ATI Radeon HD2600Pro, which my Fedora 12 64-bit system seems to have no problem recognizing natively (though it is peculiar that it shows up in lspci as an a 'HD3600' instead of 2600), so things seemed fine ... til I tried to start X. To be thorough: I went from an nVidia Quadro NVS 285 in the system using drivers from rpmfusion, to this card in hopes of getting better graphics and compositing support. So I tried uninstalling the nVidia drivers and kmods, blacklisting radeon and radeonhd mods, installing the stock ATI driver straight from the ATI/AMD site (which included header compilation), and starting X ... no go. Then removed that, installed the OpenDrivers stuff ... still no good. Ended up removing all Xorg configuration (literally removing xorg.conf) and starting X with bare bones. And now X will indeed start up and go into my desktop environment (KDE), but as soon as I open more than a single application window, the system becomes virtually unusable, and compositing is completely out of the question.
Any advice for drivers/config/setup to get this working? Or do I need to go back to my crappy 128MB NVS card?
Nothing in xorg.conf ... it didn't exist. After running the livna config tool, xorg.conf appears as below, but livna complains that fglrx and/or nvidia drivers are not found ... but it writes this anyway:
Ok, you are using KMS and HAL to set the X server at this point. Radeon + KMS is known to be buggy right now, so go ahead and disable it and see if that helps. You might have to consult the Fedora wiki on just how to do this, as there may be multiple configuration files that are telling your system to use KMS, but it also might be as simple as adding "radeon.modeset=0" or "nomodeset" to your boot parameters (if you don't know what I'm talking about post the output of "cat /boot/grub/menu.lst" and I'll show you exaclty where to append the line).
Alternatively, you Xorg and dmesg outputs don't look wrong, but do look unusal. It appears X is try to configure multiple displays on start, are you using multiple displays? If not, when the system boots (and I know this might be hard as it crashes constantly) try and run xrandr, and post the output of that. Also, go ahead and post the ouput of "cat /proc/mtrr" for good measure, but I am doubting there is anything wrong with you mtrr at this point.
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Original Poster
Rep:
Hi Alex,
I know how to modify the grub boot menu (grub.conf in my case); no worries there. I'll give that a try. As far as the log output: yes, I am running multiple displays, one next to the other in "twinview" mode, and this function seems to be working fine, even without a twinview definition in xorg.conf. But the system isn't crashing per se; it's booting fine and even loads X without apparent trouble. It just goes under heavy load when trying to do anything useful within an X session.
In searching around, I came across a FAQ guide [1] that mentions a 'fglrx' package for Fedora, but this package appears to have gone AWOL in the case of Fedora 12 64-bit repos. I was told by the maintainer of this FAQ that this package does not currently work in Fedora and hasn't for some time.
I know how to modify the grub boot menu (grub.conf in my case); no worries there. I'll give that a try. As far as the log output: yes, I am running multiple displays, one next to the other in "twinview" mode, and this function seems to be working fine, even without a twinview definition in xorg.conf. But the system isn't crashing per se; it's booting fine and even loads X without apparent trouble. It just goes under heavy load when trying to do anything useful within an X session.
In searching around, I came across a FAQ guide [1] that mentions a 'fglrx' package for Fedora, but this package appears to have gone AWOL in the case of Fedora 12 64-bit repos. I was told by the maintainer of this FAQ that this package does not currently work in Fedora and hasn't for some time.
Gotcha. Nothing personal about the grub part, I just like to be thorough in my explainations. Also, I don't know if you've tried booting without the second display attached, but there is a whole other set of issues with multiple displays and KMS, and that might be part of your problem. In your case, it may be best to scrap the whole of KMS at this point and just go back to the old framebuffer, at least until some of these issues are sorted out. Anyway, keep me updated.
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Original Poster
Rep:
Hmm ... so you think booting with just one display attached might help things? I've been booting with both so far. What do you mean by the old framebuffer? Since it seems that the drivers that used to work for Fedora (fglrx) are no longer available, I'm willing to try most anything.
Hmm ... so you think booting with just one display attached might help things? I've been booting with both so far. What do you mean by the old framebuffer? Since it seems that the drivers that used to work for Fedora (fglrx) are no longer available, I'm willing to try most anything.
Refer to my previous post about KMS for suggestions, but I'll outline some more technical details here (very briefly, and a bit sloppily; if you have specific questions I'll be glad to answer them).
Basically, what the problem most likely is is that KMS, Kernel Mode Setting, is not yet fully supported by ATI graphics cards. What KMS does, exactly, is it tells the kernel how to interact with your graphics card and directly set the resolution of you display. In the past this was handled by a number of different programs that were executed in "user-space" (as opposed to "kernel-space"), namely the X server and the "framebuffer".
Now what does that all mean? Basically, with KMS, on boot the kernel is able to interact with your graphics card, detect the native resolution of you monitor, and set the resolution of your monitor. What you, as the user notice when this happens is that when you switch to a console (tty), it is displayed in you native resolution.
In the past, in order to accomplish this same effect, you had to rely on a "framebuffer". What this means, is that you set a line a grub that said something to the effect of "vga=773", and that would send a message that your monitor was WxH pixels, and so your console had to be set to the same. A framebuffer would handle the setting of the resolution of your console, while whenever you switch to X, the X server would handle the setting of the resolution in X.
So when I tell you to go back to the old framebuffer method, what I basically want you to do is go ahead an follow my previous instructions and append the line "nomodeset" or "radeon.modeset=0", and also a line that reads "vga=N", where N is a number that is associated with your native screen resolution. Refer to this table for more information:
In all, I basically want your menu.lst (or grub.conf, or whatever it is on your machine), to look something like this is you have a 1024x768x32 display:
Code:
# (1) Arch Linux
title Arch Testing
root (hd0,4)
kernel /2.6.33-test root=/dev/sda8 ro nomodeset(or "radeon.modeset=0") vga=790
initrd /kernel26-test.img
This should disable KMS on boot, and should solve your problems. However, you need to be aware of two issues: one, you may have to manually set the resolution of your second display as well, and two, if you have a non-standard resolution, it may not be supported. There are some other things you need to know, but if you test this and it solves your immeadiate problems, we'll talk about those.
Now, on another note, I mentioned your second display because (again) KMS has some issues with trying to set a primary screen resolution to the resolution of a (sometimes nonexistant) external display. However, when this happens the problems that arise usually do not manifest in the way you described, so I am skeptical that this is the problem.
Edit: Also, be aware as you are going about this operation that
1) there may be multiple system files that enable KMS, and KMS+framebuffer don't always play nice. So, first try appending the line "nomodeset" (or "radeon.modeset=0"), booting, then switching to a console to see if KMS was disabled. If it was, the text on the console should be rather large and grainy. If KMS is successfully diabled, only then should you add the "vga=N" part.
2) Not all arguments work equally for some reason I don't understand. If the argument "nomodeset" doesn't work, go ahead and try "radeon.modeset=0", and see if this works.
3) When appending the line "vga=N" if you only know that you monitor resolution is, for example, 1024x768, but don't know the depth (i.e. whether it is a 1024x768x32 or 1024x768x256) just go ahead and pick one and reboot. If you picked the worng one all that will happen is that you will get an error message on boot, will have to select an option from a list, and then you can go right back into grub and try another vga option.
4) If your resolution is non-standard, just pick the closest resolution and go with that.
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Original Poster
Rep:
Thanks a lot Alex. So I added 'radeon.modeset=0 vga=346' to my kernel line in grub.conf (I have dual widescreen 1680x1050 monitors, and I found a code '369' that was supposed to work at this resolution but didn't for me), and I see no error or warning lines in the X log. There are a bunch of info lines listing all possible modes, including:
On boot, my screens got swapped (not a big deal, and easy to fix once things are settings), and compositing is disabled as expected, but things seem otherwise fine to this point.
Thanks a lot Alex. So I added 'radeon.modeset=0 vga=346' to my kernel line in grub.conf (I have dual widescreen 1680x1050 monitors, and I found a code '369' that was supposed to work at this resolution but didn't for me), and I see no error or warning lines in the X log. There are a bunch of info lines listing all possible modes, including:
On boot, my screens got swapped (not a big deal, and easy to fix once things are settings), and compositing is disabled as expected, but things seem otherwise fine to this point.
Compositing is disabled? Whether you are using KMS or a framebuffer shouldn't affect your compositing. Are you using the proprietary or open source drivers right now? If you want the compositing and 3D, then go ahead and install the proprietary drivers, they should work just as well as the open source now that you have your boot options configured correctly.
Now, we're not quite done yet, there are a few things that you need to be aware of. First, does "346" correspond to the actually resolution of your monitors, or just something close? Unless you do a lot of work directly on the console, it isn't really a big deal in itself to have completely correct frambuffer resolution, we just want a framebuffer on the console that's at least pretty close to the native resolution of the monitor. However, be aware that if you have an incorrect framebuffer resolution that in some unusual cases it will lead to the X server being set in an improper resolution. If you find this happening to you, go ahead and follow the Fedora wiki/guide instructions for creating and configuring an Xorg.conf file. Mostly, the settings should be correct, you will just need to ensure that the screen resolution is properly set.
Second, you may notice when switching between a console and the X server that you will now see a "flicker". This is perfectly normal and unavoidable, albeit, undesirable behavior. This "flicker" occurs because you now have the X server setting video output for X and the kernel setting the video output for your console. Before, with KMS, the kernel would set the video output of each. As such, now your machine must hand over control of you video output from the X server to the kernel when switching to a console, and vice versa when switching back to the X server. There is nothing you can do about this.
Finally, there are some security issues with the old framebuffer method. This, combined with the other issue posted above, is mainly why it is being phased out. If security is a concern for you (and we're talking some esoteric exploits here, so when I say a "concern" I mean a real concern) then you'll need to look into additional ways to secure your machine. However, even if security isn't a huge concern, you must be aware of the security issues as users on your machine may need additional privileges in order to properly run some aspects of X. In particular I had an issue with Xscreensaver that left me pounding my head against the wall for a couple of weeks. I never really figured out the root of the problem, I just uninstalled Xscreensaver as I never really used it anyway. All in all, on this issue, you may find that you have no problems what-so-ever. However, I just wish to forewarn you in case you start encountering some unexplainable errors.
If you have any other questions feel free to ask. Otherwise, good luck!
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Original Poster
Rep:
Thanks Alex. My screens' native resolution is 1680x1050, so 1400x1050 is close, and as you said, that's just for the console, so not a big deal.
A big deal occurred, however, when I went ahead and installed the latest version of the proprietary drivers for the Radeon HD 2600 line from the ATI/AMD site [1]. The install went fine, as did the 'aticonfig --initial' command to modify the X config, but a reboot resulted in no more X; from the log:
Code:
dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: UpdateSpriteForScreen
(EE) Failed to load/usr/lib64/xorg/modules/drivers/fglrx_drv.so
(EE) Failed to load module "fglrx" (loader failed, 7)
(EE) No drivers available.
Fatal server error:
no screens found
The file does exist (as an ELF binary). If I delete my xorg.conf, I can get into a plain X session without issue. But if I try System Settings -> Desktop, the control app crashes with what appears to be a driver problem [2].
Thanks Alex. My screens' native resolution is 1680x1050, so 1400x1050 is close, and as you said, that's just for the console, so not a big deal.
A big deal occurred, however, when I went ahead and installed the latest version of the proprietary drivers for the Radeon HD 2600 line from the ATI/AMD site [1]. The install went fine, as did the 'aticonfig --initial' command to modify the X config, but a reboot resulted in no more X; from the log:
Code:
dlopen: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: UpdateSpriteForScreen
(EE) Failed to load/usr/lib64/xorg/modules/drivers/fglrx_drv.so
(EE) Failed to load module "fglrx" (loader failed, 7)
(EE) No drivers available.
Fatal server error:
no screens found
The file does exist (as an ELF binary). If I delete my xorg.conf, I can get into a plain X session without issue. But if I try System Settings -> Desktop, the control app crashes with what appears to be a driver problem [2].
Ouch. I'm pretty sure you're right about this being a driver issue. Unfortunately, I can't help you if this is the case, you'll just have to file a bug report with ATI and have them take care of it.
Just for good measure, try running X with Xorg.conf again, but this time ensure the SUID bit is set on the binary before you do so. This might simply be one of those weird permissions issues I mentioned.
Also, I googled a bit and there appears to be some problems running the proprietary ATI drivers without Xorg.conf at this point. Again, this is something relatively new so the bugs haven't totally been ironed out yet.
fglrx will absolutely not work on Fedora 12 since the driver doesn't yet support Xorg xserver 1.7.* Hopefully this month or next months release will support it.
Maybe I missed it somewhere in this thread already, but what happens when you install the mesa-drivers-experimental package and try to use the open source drivers?
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448
Original Poster
Rep:
Quote:
Originally Posted by adamk75
Maybe I missed it somewhere in this thread already, but what happens when you install the mesa-drivers-experimental package and try to use the open source drivers?
That's actually the first thing I tried, but I tried it again, just for fun. So after uninstalling the proprietary ATI driver, uninstalling the mesa-dri-drivers and mesa-dri-drivers-experimental packages, removing radeon.modeset=0 vga=346' from my grub kernel entry, and re-installing these two packages again, I am back to where I was in the beginning: no errors reported during boot, but no graphical desktop session. The boot process stops reporting after "Starting crond: [OK], Starting atd: [OK]". It just stops there. I can get into another console session and check the Xorg log (no errors) and system messages (no errors), and I can even start an X session, but that just produces a black screen, and again no X errors. 'lspci' shows the same VGA entry as before:
Code:
07:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series]
Odd... So the screen goes black, but the machine is still responsive? Could you grab the /var/log/Xorg.0.log file and pastebin it? Have you checked to see if there are any updates to the radeon driver in F12? Or perhaps even tried a newer version from rawhide?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.