After my desktop boots, the login screen looks garbled/mashed up, although my cursor looks fine.
When booting, i notice a line something along the lines of
conflicting fb hw usage
Is there any way to fix this? Currently i can boot with the nomodeset option decently.
Thank you guys in advance.
Try disabling the framebuffer device and rebooting:
chkconfig fbset off (as root)
Sorry, didn’t fix it 
Ok, well on to step :2 
What video card do you have? (lspci would be the best way to see) Is this a laptop or do you have a monitor attached? Any errors in /var/log/Xorg.0.log?
It is a desktop with a monitor attached.
output from lspci:
It is a desktop with a monitor attached.00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE nForce 430] (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:0a.0 Communication controller: Conexant Systems, Inc. HSF 56k Data/Fax Modem
And Xorg.0.log (errors only):
30.689] (II) Loading extension MIT-SCREEN-SAVER
30.721] (EE) Failed to load module "nvidia" (module does not exist, 0)
30.921] (EE) [drm] failed to open device
Ahh… looks like the nvidia module is giving you fits.
Did you have a chance to install it yet (wondering if installation just flat out failed) or no?
not sure, to be honest. Lol. I upgraded from 11.3, but i can give installation/re-installation a try. I will update on the results. 
I downloaded the nvidia drivers from their site, installed, restarted x, and everything works! Thank you, I really appreciate it.
Sure thing … glad to help out!
I am getting the following message, sometimes followed by a loss of video (from /var/log/boot.msg):
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
I am running the following setup:
Motherboard: Asus M4A88TD-V EVO/USB3
Onboard graphics: VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4250]
The installed radeon driver appears to be:
xorg-x11-driver-video-radeonhd - Driver for AMD GPG (ATI) r5xx/r6xx Chipsets
I would be interested to hear if you have any thoughts on what the problem might be.
Thanks!
Andy Prough
Note “xorg-x11-driver-video-radeonhd - Driver for AMD GPG (ATI) r5xx/r6xx Chipsets” refers to an rpm, and the ‘radeonhd’ graphic video driver which is not the same as the ‘radeon’ driver. Support for the ‘radeonhd’ driver has mostly stopped and only the ‘radeon’ driver being supported.
If you type:
man radeonhd
you will find no mention of the RS880 graphics nor of the Radeon HD42xx series with the ‘radeonhd’ graphic driver.
If you type:
man radeon
you will note the line "RS 880 Radeon HD 4100/4200/4290 " suggesting the ‘radeon’ graphic driver supports your hardware.
The ‘radeon’ graphic driver is included in the ‘xorg-x11-driver-video’ rpm, which you can confirm by typing:
rpm -qi xorg-x11-driver-video -l
and you will note files installed with ‘radeon’ in the file name for that graphic driver.
If you type:
rpm -qi xorg-x11-driver-video -changelog
you may note reference in Feb-2011 to the xf86-video-ati-6.14 tarball which contains the radeon driver that is then packaged in the xorg-x11-driver-video rpm. This shows the version of the radeon driver is 6.14.0.
If that changelog history scolls by too fast, then redirect it to a text file:
rpm -qi xorg-x11-driver-video -changelog > graphic-driver-history.txt
and open “graphic-driver-history.txt” with a text editor.
Reference the message in the boot.log that you report, I’m not familiar with that. But what is more useful is to look in the /var/log/Xorg.0.log file and that will tell what graphic driver you are using (likely RADEON) and it will also may any salient error messages.
If you can’t understand anything in the /var/log/Xorg.0.log file you can copy and paste it to a paste site such as SUSE Paste and then post here the URL indicating where the file contents are located on the web.
Hi oldcpu,
You are right - Xorg.0.log indicates that the “radeon” driver is loading, not “radeonhd”:
18.120] (II) LoadModule: "radeon" 18.121] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so 18.121] (II) Module radeon: vendor="X.Org Foundation"
Here is the entire output of Xorg.0.log:
SUSE Paste
I noticed the following lines indicating a failure:
17.779] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) 17.779] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
Possibly an acpi problem?
Otherwise, you are right, to my untrained eye I do not see any other problem in the log file.
Please let me know your thoughts. Thanks!
Andy
I recall this :
followed by this:
Do you get this all the time when you boot, or only when you have a loss of video ?
By loss of ‘video’ do you mean your X window goes black ? That also reads like a power management issue, and likely you can tune that with both your screen saver AND (not or) your power management control (desktop dependent).
I don’t know if there is a problem. Maybe that can be ignored ? If one surfs the web on that quoted warning, one can read of ways to prevent it which may or may not work. I read a Ubuntu thread post which speculated:
It seems there is a race condition between acpid and Xorg as they are starting. Xorg tries to connect to the socket before acpid has created it. It also seems as if later versions of Xorg poll for the missing socket and connect within a few seconds, but do not post a message to say the connection has been successful. If acpid is running (it should have started automatically), then Xorg will have silently connected to the socket and you can safely ignore the warning.
Frankly, I don’t know if that is accurate nor appropriate for your observation on openSUSE. If it is a race condition then maybe you could try to switch OFF the parallel boot process to see if that helps. But that’s just speculation on my part and so take it as such (ie take it as speculation).
I read an old post on a site (referring to openSUSE-10.2 !! ) where in the case of that warning they recommended adding to the ‘server’ section of one’s xorg.conf file the line:
Option "NoPM" "true"
of course 11.4 does not have an xorg.conf by default, and so one would need find the appropriate .conf file in /etc/X11/xorg.conf.d/ directory to apply such an edit IF it were appropriate, and it may not be appropriate. There are some hints in the mythtv wiki on DPMS. But does that edit just address a symptom as opposed to a problem ? When I search to see what “NoPM” means (and I assume “PM” means power management) I find this in the xorg.conf documentation:
**
Option “NoPM” “boolean”**
Disables something to do with power management events. Default: PM enabled on platforms that support it.
So if one were to set “NoPM” to true, then it disables something in power management. Possibly not a good idea if this is a laptop.
There is an arch linux page that speculates the warning could be associated with the PC’s boot config and acpid, and suggest checking the acpid daemon. In openSUSE the acpid daemon control setting can be found under YaST > System > System Services (run level) where typically the acpid daemon is set to YES to run. But if already set to YES I do not think I would touch it.
My suggestion would be to ignore that warning for the moment, and instead try to tune BOTH your screen save and your power management application (to stop the sudden ‘video loss’ as you describe it.
Hi oldcpu,
Do you get this all the time when you boot, or only when you have a loss of video ?
I had only recently started watching the Xorg.0.log, but I do recall the past three times I tried to start up, whether it booted fully into the KDE desdtop or not, I was getting the “Open ACPI failed” messages in that log. I will keep a close eye on it and make sure I am correct about that.
By loss of ‘video’ do you mean your X window goes black ? That also reads like a power management issue, and likely you can tune that with both your screen saver AND (not or) your power management control (desktop dependent).
Yes, the X window goes black, and normally the boot process stalls at that point. I’m not sure what screen saver options I should be looking at? Are you referring to boot splash?
It seems there is a race condition between acpid and Xorg as they are starting. Xorg tries to connect to the socket before acpid has created it. It also seems as if later versions of Xorg poll for the missing socket and connect within a few seconds, but do not post a message to say the connection has been successful. If acpid is running (it should have started automatically), then Xorg will have silently connected to the socket and you can safely ignore the warning.
If it is a race condition then maybe you could try to switch OFF the parallel boot process to see if that helps.
The “race” condition makes a lot of sense here - this system is just falling all over itself to boot as fast as possible. I built it with the fastest 6-core AMD processor I could find in order to run some extremely processor-intensive PDF OCR applications on several hundred thousand pages of documents. When it boots up, it almost LOOKS like the machine is “racing” itself, and often boots from the point of kernel selection to the point of login in about 6-7 seconds. I’ve never seen a machine of mine trying to fly through the boot process so fast, and frankly I wouldn’t mind it slowing down a bit and taking its time. I will apply the “no” option on RUN_PARALLEL under /etc/sysconfig Editor in YaST and see if that makes a difference.
There is an arch linux page that speculates the warning could be associated with the PC’s boot config and acpid, and suggest checking the acpid daemon. In openSUSE the acpid daemon control setting can be found under YaST > System > System Services (run level) where typically the acpid daemon is set to YES to run. But if already set to YES I do not think I would touch it.
I should have looked at that earlier, but acpid is already set to “no” in System Services (run level).
Thanks for your feedback! I’ll post later today if I make any progress.
Andy
No, I was confused as to the nature of your PCs problem. I had the misunderstanding that you had X running for some minutes, when the screen would randomly go black. What you clarified now is clearly different as what you experience is during the boot process.
Yes, the problem occurs halfway through the boot process. During boot I get this message:
fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
I understand that “fb” refers to framebuffer. At the moment I get the above message, the screen flickers for a moment. Sometimes it locks up during boot at that point, and sometimes it continues.
I did go ahead and change to the “no” option on RUN_PARALLEL, and the boot process was noticeably slower, taking about an extra 5 seconds. The machine did boot into the KDM login screen in this mode. Still got the above mentioned acpid messages in the Xorg.0.log.
Thanks for all your help so far. I am just trying to figure out how to get this to run without a hitch.
Andy
Another ‘speculative’ idea is that the grub boot settings “vga=0xYYY” (on my PC it is vga=0x317) are interfering the the “radeondrmfb” (or maybe its visa versa) and you simply need to remove the “vga=0xYYY” out of the options line in your grub menu when you boot. If you find doing that all the time helps then you can remove it out of the /boot/grub/menu.lst file. Again, as noted, this is ‘speculative’.
Brilliant! I think that did the trick. This time I got three framebuffer messages in boot.msg, none of them errors:
<6> 5.727532] [drm] fb mappable at 0xD0141000
<6> 5.727533] [drm] vram apper at 0xD0000000
<6> 5.727534] [drm] size 5242880
<6>** 5.727534] [drm] fb depth is 24**
<6> 5.727535] [drm] pitch is 5120
<4> 5.741365] Console: switching to colour frame buffer device 160x64
<6>** 5.752348] fb0: radeondrmfb frame buffer device**
I went into the YaST boot loader configuration, and changed the VGA mode for the desktop kernel from mode 0x31a to Text Mode.
And you were right - I looked at boot.omsg, and the prior boot attempt had been trying to load framebuffers for both the Vesa and the radeon settings - I think there was definitely a conflict.
Here are boot.msg and boot.omsg, if you want to take a look at the difference:
boot.msg: SUSE Paste
boot.omsg: SUSE Paste
Thanks!
Andy
wow ! who would have guessed ? That was a real “long shot” on my part. Please let us know if it helps also with the random boot failure problem.
Hi oldcpu,
Seems to have done the trick - no boot failures in 5 attempts since the change, and no error messages which would indicate it is having any problem at boot.
Thanks again - great detective work!
Andy