LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Fedora
User Name
Password
Fedora This forum is for the discussion of the Fedora Project.

Notices

Reply
 
Search this Thread
Old 03-05-2010, 05:40 PM   #91
Alex_Dc
Member
 
Registered: Oct 2009
Posts: 104

Rep: Reputation: 22

Quote:
Originally Posted by deesto View Post
Your assumptions seem correct: no crashes or errors so far on desktop (except for occasional GConf/ORBit errors). mesa drivers were still installed since many posts ago. In Gnome, I can enable compositing (via Compiz desktop effects settings), though I noticed that the "wobble windows", while I can select it and it works, seems to disable itself every time I run the Gnome Desktop Effects config tool. Strange. And Xorf.conf is minimal, but calls for radeon driver.
As far as I know, the wobble windows thing is a problem with gnome, so there isn't any need to worry about that.

Okay, so as far as hardware configuration we seem to be good. We've identified your original problem as the PAT feature in the kernel, which we disabled, thereby fixing your ATI issue, and the crashing. Also, we identified your slow/weird graphics problems as another kernel problem, this being and improperly set /proc/mtrr, which is a common, still unresolved issue among Dell PCs and laptops. So I think we have everything covered there.

What I need you to do at this point, is go ahead and add those commands you used to disable the registers to whatever file Fedora uses to read user-related commands at start up. This way, the offending registers will be disabled every time you boot. The file is generally "/etc/rc.local". When you have done this, reboot, and check your /proc/mtrr to make sure it matches your fixed /proc/mtrr. If it does, we're done with this mess.

Now, let's go ahead and re-install KDE. This shouldn't be a problem, but I want to stay with you on this one to make sure it works.

Also, I take it you are going to stick with the ATI card at this point, correct? For what you are doing you don't really need it, but you will notice a bit of a difference speed-wise. If you decide to go back to the Nvidia, and return the ATI, you should be aware that you will have to do some additional configuration as another reason you were having graphics problems before is that you were rendering graphics via software rather than hardware. This is another common problem, and easily fixed, though I can't help you with it if you choose to re-install the Nvidia as I don't know much about the problem other than that it exists.

Finally, you are going to install some additional RAM? Again, for graphics this isn't necessary, it will only affect the speed of your system (which should be significantly better already). If you do plan on doing this, you will have to reconfigure your /proc/mtrr again when the additional RAM is installed. This should be fairly easy, but I will need to explain a few things to you so you can understand what to do.
 
1 members found this post helpful.
Old 03-08-2010, 08:34 AM   #92
deesto
Member
 
Registered: May 2002
Location: NY, USA
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448

Original Poster
Rep: Reputation: 31
Hi Alex,

I edited /etc/rc.local to include the MTRR changes, and after a reboot /proc/mtrr ended up the same as after the manual edits.

I installed @kde-desktop (well, really updated it, as it was already installed) and changed run levels from 5-3-5 and got back into KDE.

Just before the desktop loaded, I got a bunch of distorted horizontal lines on a white background, on both screens. That lasted a few seconds, and then the desktop appeared as normal. Something else odd, though: in system settings --> desktop, under General, it shows an info bar that says "Compositing is not supported on your system", and then just beneath that, under "Compositing State", it says "Compositing is active". So I'm a little confused. xorg.conf is still minimal, with a "device" entry of just "videocard0" and the "radeon" driver. A generic "glxgears" now produces a rate of just 300-350 FPS, as compared to before.

Sound is screwed up (no errors, but I don't hear anything), though I hear this is a common problem when switching from Gnome to KDE.

I do plan to stick with the ATI card, as long as things can be normalized. And the memory still hasn't arrived (ordered it weeks ago!).

One more thing: the system (and I assume GPU) fans are going absolutely bonkers and are running at almost max all the time. Really loud. I've installed lm_sensors and fancontrol, but pwmconfig keeps saying there are no capable sensor modules installed. sensors-detect shows a temp monitor for both DIMMs, as well as CPU speed, but that's about it. This wasn't happening before.

Last edited by deesto; 03-08-2010 at 11:08 AM.
 
Old 03-08-2010, 11:14 AM   #93
Alex_Dc
Member
 
Registered: Oct 2009
Posts: 104

Rep: Reputation: 22
Quote:
Originally Posted by deesto View Post
Hi Alex,

I edited /etc/rc.local to include the MTRR changes, and after a reboot /proc/mtrr ended up the same as after the manual edits.

I installed @kde-desktop (well, really updated it, as it was already installed) and changed run levels from 5-3-5 and got back into KDE.

Just before the desktop loaded, I got a bunch of distorted horizontal lines on a white background, on both screens. That lasted a few seconds, and then the desktop appeared as normal. Something else odd, though: in system settings --> desktop, under General, it shows an info bar that says "Compositing is not supported on your system", and then just beneath that, under "Compositing State", it says "Compositing is active". So I'm a little confused. xorg.conf is still minimal, with a "device" entry of just "videocard0" and the "radeon" driver. A generic "glxgears" now produces a rate of just 300-350 FPS, as compared to before.

Sound is screwed up (no errors, but I don't hear anything), though I hear this is a common problem when switching from Gnome to KDE.

I do plan to stick with the ATI card, as long as things can be normalized. And the memory still hasn't arrived (ordered it weeks ago!).

One more thing: the system (and I assume GPU) fans are going absolutely bonkers and are running at almost max all the time. Really loud. I've installed lm_sensors and fancontrol, but pwmconfig keeps saying there are no capable sensor modules installed. sensors-detect shows a temp monitor for both DIMMs, as well as CPU speed, but that's about it. This wasn't happening before.
Not fun. Please post your regular slew of outputs. I think my original assumption was right, and there are kernel-level bugs here. The PAT and MTRR problems may have been only half the story.

But, before we jump the gun and start installing the 2.6.32 kernel for testing, go ahead and try booting back into Gnome again (but post those outputs before you do), and see if you have the same problems.
 
Old 03-08-2010, 02:00 PM   #94
deesto
Member
 
Registered: May 2002
Location: NY, USA
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448

Original Poster
Rep: Reputation: 31
A few strange things are happening here, after multiple reboots and X restarts:
- Fans seem to have righted themselves and are now all down to much more tolerable levels. No idea how.
- Sound is now fine in KDE.
- Compositing seems to be a no-go in both KDE and GDE.
- 'glxgears' is now back up to 1200-1600 FPS under KDE.
- Still seeing a second or so of distorted colors on white right before the X desktop login screen, and then it rights itself.
- KDE can't seem to save display location settings, so it keeps flipping my two displays around and showing the main display on the right. As soon as I go into System Settings -> Display, the settings are shown correctly, but are not applied until I click "Apply", which is strange since I haven't changed anything there. This gets reset with every boot/init level change. GDE didn't need to be fixed.

KDE output:
http://deesto.pastebin.com/ESk4bY1y

GDE output:
http://deesto.pastebin.com/xum8VGCH
 
Old 03-08-2010, 03:28 PM   #95
Alex_Dc
Member
 
Registered: Oct 2009
Posts: 104

Rep: Reputation: 22
Let's see...

Quote:
Originally Posted by deesto View Post
A few strange things are happening here, after multiple reboots and X restarts:
- Fans seem to have righted themselves and are now all down to much more tolerable levels. No idea how.
- Sound is now fine in KDE.

- 'glxgears' is now back up to 1200-1600 FPS under KDE.
Probably a glitch on your first reboot, then. I wouldn't worry to much unless the problem reappears. We've been mucking around a lot, it was bound to happen eventually.

Quote:
Originally Posted by deesto View Post
- KDE can't seem to save display location settings, so it keeps flipping my two displays around and showing the main display on the right. As soon as I go into System Settings -> Display, the settings are shown correctly, but are not applied until I click "Apply", which is strange since I haven't changed anything there. This gets reset with every boot/init level change. GDE didn't need to be fixed.
That is a problem with KDE, I can't help you there.

Quote:
Originally Posted by deesto View Post
- Compositing seems to be a no-go in both KDE and GDE.
- 'glxgears' is now back up to 1200-1600 FPS under KDE.
- Still seeing a second or so of distorted colors on white right before the X desktop login screen, and then it rights itself.
This I don't know about. Try disabling KMS again and see if that helps anything. Also, if you have the Security Enhanced features enabled, disable those also. They have more known bugs than I can count.

Strangely, there is nothing I can identify as being unusual with either of your outputs. In fact, I'm pretty sure they are identical to the previous outputs. As far as I can tell, you have direct rendering enabled, as you should, and if glxgears runs correctly, then you should have no problem with compositing. If neither of the options I suggested does anything, and nothing mysteriously explodes anytime soon, I'm going to go ahead and say that this is a driver bug. Open a new thread detailing this problem and see if other ATI users can help you with this (again, I couldn't help you with this as I only generally understand the workings of the ATI cards).

Finally, when that new RAM comes in, you will have to reconfigure you /proc/mtrr again to account for it. This should be easy enough a second time around, as you already know how to disable inappropriate registers. However, you need to know how to determine which registers are appropriate, and how to assign them if necessary. An an exact, and completely correct /proc/mtrr is difficult to find, however we can speculate using both your dmesg and lspci as a reference. Here we go.

You old /proc/mtrr looked like this:

#
# cat /proc/mtrr
#
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
#
reg01: base=0x07ff00000 ( 2047MB), size= 1MB, count=1: uncachable
#
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
#
reg03: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
#
reg04: base=0x400000000 (16384MB), size=16384MB, count=1: write-back
#
reg05: base=0x800000000 (32768MB), size=32768MB, count=1: write-back
#
reg06: base=0xff0000000 (65280MB), size= 256MB, count=1: uncachable
#
reg07: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining

Your new /proc/mtrr looks like this:

#
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
#
reg01: base=0x07ff00000 ( 2047MB), size= 1MB, count=1: uncachable
#
reg07: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining


Now the question is: how the hell did I know your original was wrong, and how to fix it?

Pretty simple actually: MTRR stands for "Memory Type Range Register". Now, without going into gritty details I only half-understand, basically what that means is that the MTRR is a way for your CPU to address memory on your machine. Now, seeing as you only had 2GB of memory, registers 2, 3, 4, and 5 didn't make any sense at all, because the sizes were 4G, 8G, 16G, and 32G respectively (and obviously you don't have 60G+ of memory on your machine!)

So, I knew we had to disable those by default. Now another thing to look at is reg 7. This 256M of memory is what we call "writing-combining", which means it is a place where a bunch of data can be held for a second and organized in a certain order before it is sent across your machine (again, a very sloppy explanation, but you have Wikipedia if you need more details, I'm just trying to get you generally familiar with all this).

Now, this "write-combing" region is necessary mostly for video processing, so we have to leave that alone. It has nothing to do with the actually amount of memory in your machine.

Finally, we had reg 6. Now, this I knew had to be gotten rid of because it didn't make any sense. How did I know this? Refer to your lscpi output. If you read through, you will find some lines that look like this:

Region 5: Memory at ff970000 (32-bit, non-prefetchable) [size=1K]

And basically, what "non-prefetchable" means is that it is uncacheable memory. Now any entry below 1MB can safely be ignored (I don't know why, so don't ask, I just know that it can), and as I looked through your output, I noticed that there was only 1MB of non-prefetchable memory accounted for, which is why we left register 1 alone, and deleted register three.

Now, finally, there is reg 0. I'm sure at this point you've already guessed that this is your RAM, and you would be right. In fact, I can tell your this output that you specifically have one 2G chip of RAM (chip? I can't remember what it is called.) And even before I looked your PC up, I could tell that you had at least five memory "slots" on your motherboard. Extrapolating further, and this was a bit of speculation as the mtrr was set wrong, I had guessed that each "slot" could hold a 4G chip of memory. This seems to be confirmed by the Dell brochure.

Now how did I figure this out? What I want you to look at now is the "base" range in the /proc/mtrr. It is written in hexadecimal (which you will have to obtain a basic understanding of if you can't read it already), with the numeric value in parenthesis on the right. Basically meaning that reg 0 starts at a memory location of 0, reg 2 starts a memory location of 4G, reg 3 at 8G, etc, leaving room for 4G of memory between each.

Now everything starts to get screwy w/reg 4 and 5 (ignore 6, I have no idea where this came from), and I'm fairly sure that this is because you have 8 memory slots, according to the Dell website, and the Linux kernel can only set 8 registers (0-7). This probably confused the kernel, making it set nonsensical base values.

Unfortunately, this means you will never be able to use all eight memory slots (at least not until the mtrr code is corrected or updated, or whatever).

So, in conclusion, to reset the /proc/mtrr you will need to know how much memory you are adding (in hex), and the base address of the slot you are adding it to (in hex). Then you use this little command:

echo "base=0x000000000 size=0x080000000 type=write-back" >| /proc/mtrr

replacing "base" and "size" with the correct information. Now, if after you install the memory, you see that lspci is declaring more uncacheable ranges, as I explained them earlier, you will also have to replace the "type" portion as to "uncacheable" rather than "write-back".

Finally, the kernel may auto-magically detect everything for you when the new memory is installed, and you won't have to go through this mess (don't count on that). So, before trying to correct the ranges yourself, simply comment out the lines you added to rc.local to disabling the registers on startup, and check out the /proc/mtrr after boot. If it looks as though the kernel automatically assigned the memory to the proper location, then just go through and disable the appropriate registers as explained at the top.

Whew!

Tell me if disabling KMS or SELinux helped anything.

Last edited by Alex_Dc; 03-08-2010 at 03:32 PM.
 
1 members found this post helpful.
Old 03-12-2010, 08:29 AM   #96
deesto
Member
 
Registered: May 2002
Location: NY, USA
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448

Original Poster
Rep: Reputation: 31
To respond quickly: Disabling SELinux is one of the first things I do when creating a workstation, so that's already done. I've also been booting with 'nopat' by default since your earlier recommendation. So both of those suggestions are currently already implemented.

I'm still getting conflicting messages from KDE's desktop control panel regarding compositing: currently, it reads "Compositing is not supported on your system" and greys out the option to enable desktop effects; yet just below that it says "Compositing is active" and gives the option to "Suspend compositing". Of course, if from here I click "Defaults" to reset everything, all options go away and I see only "Compositing is not supported on your system". However, in the meantime, desktop effects (transparency, window transitions, etc.) are all clearly working if I don't touch anything (see attached image). ::

As for memory and MTRR: the memory finally came ... but for whatever reason, it includes a huge heatsink on each DIMM that prevents them from being inserted in a system in congruent slots ... which makes it useless for me. I've tried taking off the heatsink, and the system can use it that way with no problem ... but I see DIMM temps approaching 200 F without the heatsinks, so I need to get them out of there, fast ....
Attached Images
File Type: png kde-desktop-effects.png (99.3 KB, 1 views)

Last edited by deesto; 03-12-2010 at 09:09 AM. Reason: added screen shot attachment
 
Old 03-12-2010, 12:48 PM   #97
Alex_Dc
Member
 
Registered: Oct 2009
Posts: 104

Rep: Reputation: 22
Quote:
Originally Posted by deesto View Post
To respond quickly: Disabling SELinux is one of the first things I do when creating a workstation, so that's already done. I've also been booting with 'nopat' by default since your earlier recommendation. So both of those suggestions are currently already implemented.
All right. But try disabling KMS like we did at the beginning of the thread (radeon.modeset=0 or whatever it was). Honestly, it's a shot in the dark, but it might do something.

Quote:
Originally Posted by deesto View Post
I'm still getting conflicting messages from KDE's desktop control panel regarding compositing: currently, it reads "Compositing is not supported on your system" and greys out the option to enable desktop effects; yet just below that it says "Compositing is active" and gives the option to "Suspend compositing". Of course, if from here I click "Defaults" to reset everything, all options go away and I see only "Compositing is not supported on your system". However, in the meantime, desktop effects (transparency, window transitions, etc.) are all clearly working if I don't touch anything (see attached image). ::
This suggests to me that the problem isn't with KMS (as mentioned above, but try my suggestion just for good measure), or a driver bug, but a KDE bug (4.0 has plenty of them to go around). I guess as long as it is working correctly, it really isn't a problem. But if you want to investigate, try the KMS, then try reporting a bug to KDE and/or ATI, and see if they can figure it out. If you're content just to have it working, then your done as far as this goes.

Quote:
Originally Posted by deesto View Post
As for memory and MTRR: the memory finally came ... but for whatever reason, it includes a huge heatsink on each DIMM that prevents them from being inserted in a system in congruent slots ... which makes it useless for me. I've tried taking off the heatsink, and the system can use it that way with no problem ... but I see DIMM temps approaching 200 F without the heatsinks, so I need to get them out of there, fast ....
Well, that's a new one for me too. Not sure I can help you there, but did you understand my above guide? Any questions you had on that?
 
Old 03-12-2010, 01:35 PM   #98
deesto
Member
 
Registered: May 2002
Location: NY, USA
Distribution: FreeBSD, Fedora, RHEL, Ubuntu; OS X, Win; have used Slackware, Mandrake, SuSE, Xandros
Posts: 448

Original Poster
Rep: Reputation: 31
So, booting with 'radeon.modeset=0' made no difference in settings; the one thing it did do was to once again swap my two displays after I had fixed them (the fix had persisted between boots before the addition of that kernel option; swapping them in the display settings swapped the screens but not their settings or the applications running on them, which was also very strange). Otherwise, I still see the same odd conflict of compositing settings in the desktop control panel. But one positive effect this seems to have shows up in glxgears, which runs at 1200-1500 FPS using 'radeon.modeset=0', and less than half that without it.

Honestly, if I could somehow ascertain that this is a problem with Fedora KDE and not just KDE in general, I might give a go to another distro and try it out.

I understand your info on changing MTRR and will give it a try once I have additional memory to work with. But for the few minutes I had the other 4 GB installed, I did see a performance boost, most dramatically at boot-up time.
 
Old 03-13-2010, 12:29 AM   #99
Alex_Dc
Member
 
Registered: Oct 2009
Posts: 104

Rep: Reputation: 22
Quote:
Originally Posted by deesto View Post
So, booting with 'radeon.modeset=0' made no difference in settings; the one thing it did do was to once again swap my two displays after I had fixed them (the fix had persisted between boots before the addition of that kernel option; swapping them in the display settings swapped the screens but not their settings or the applications running on them, which was also very strange). Otherwise, I still see the same odd conflict of compositing settings in the desktop control panel. But one positive effect this seems to have shows up in glxgears, which runs at 1200-1500 FPS using 'radeon.modeset=0', and less than half that without it.
Okay, like I said, that was a shot in the dark. As far as glxgears go, with KMS you will get lower FPS, but your actual 3D performance will improve. So go ahead and keep KMS enabled (i.e. remove the 'radeon.modeset=0' line) as it doesn't seem to be causing any problems.

Quote:
Originally Posted by deesto View Post
Honestly, if I could somehow ascertain that this is a problem with Fedora KDE and not just KDE in general, I might give a go to another distro and try it out.
Like I said, it is either KDE or a driver bug. I couldn't tell you which, unfortunately. However I am leaning more towards KDE as KDE 4 is rather bug ridden. The fact that you are being informed that you can't use compositing, yet compositing still works seems to support this. As far as switching distros goes, that probably won't help. KDE is KDE no matter which distro you use. Maybe one distro will have a slightly customized, or an updated package, but it is doubtful at best that changing distros will solve your problem. I'd go ahead and file a bug report with KDE. But in the meantime, at least you have compositing no matter what KDE says.

Quote:
Originally Posted by deesto View Post
I understand your info on changing MTRR and will give it a try once I have additional memory to work with. But for the few minutes I had the other 4 GB installed, I did see a performance boost, most dramatically at boot-up time.
Adding 4G of memory will do that. Good to hear that my instructions were understandable. The /proc/mtrr issue is just such a nasty and ill-recognized bug that it's hard to find much information on it, let alone enough to explain it comprehensibly to someone else.


Well! It was a long journey, but I think we've come to our conclusion here. I can't really help you with the KDE and/or driver bug as this is outside of the realm of my knowledge, but in either case it is a different issue than the original subject of the thread, and probably needs a thread all to its own (if you don't intend to skip directly to a bug report, that is). Once you're comfortable that there are no more display issues, go ahead and mark this one as solved.
 
1 members found this post helpful.
  


Reply

Tags
bit, fedora


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
1-Click Install ATI Driver For ATI X1950 Video Card Corrupts Suse 11.1 Harpo Suse/Novell 4 05-25-2009 05:28 PM
Does Linux Kernel support ATI Radeon HD 2100 VGA card eramax Linux - Hardware 4 03-01-2009 08:45 PM
ATI 9200-SE PCI card support question. Alan87i Suse/Novell 0 06-02-2006 04:13 AM
ATI 9600se running slower than older ATI card w/ DRI on euth665667 Linux - Hardware 0 07-03-2004 06:10 AM
Which graphics card has best support in Linux... ATI or Nvidia Stevetgn Linux - Hardware 24 04-13-2004 06:46 PM


All times are GMT -5. The time now is 06:20 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration