I installed openSuSE 11.3 on a Dell Optiplex 740 without any problems.
But now sometimes after choosing “openSuSE” from the bootloader the system crashes with a “white screen”.
The last lines on the screen were:
I have to power off the system to get it run again.
Can anybody help me with this problem?
Thanks
G. Hammer
It could be a timing problem ( ? ) with the graphic driver you are using, which might explain why it works sometimes and not other times? Can you tell us EXACTLY what graphic hardware is in your Dell Optiplex 740 and EXACTLY what graphic driver is in use?
It could also be how you boot, … ie maybe it occurs only when rebooting from MS-Windows to Linux but does not occur when going direct to Linux from a power off.
I could be something other than the above. Is the BIOS on your Dell Optiplex 740 motherboard up to date?
I guess I think there is more investigation that could be done that might help shed a bit more light on this. What else can you tell us about this problem ?
Best wishes and stay well.
It occurs in both cases, restarting from Windows and starting direct from power on.
Graphics hardware is ATI Radeon X1300.
Two sections from hwinfo regarding the graphics:
40: PCI 300.0: 0300 VGA compatible controller (VGA)
[Created at pci.318]
Unique ID: svHJ.aiHZfenAOj2
Parent ID: 8otl.OB2BsRrVga5
SysFS ID: /devices/pci0000:00/0000:00:04.0/0000:03:00.0
SysFS BusID: 0000:03:00.0
Hardware Class: graphics card
Model: “ATI Radeon X1300/X1550”
Vendor: pci 0x1002 “ATI Technologies Inc”
Device: pci 0x7183 “Radeon X1300/X1550”
SubVendor: pci 0x1028 “Dell”
SubDevice: pci 0x0d02
Driver: “radeon”
Driver Modules: “drm”
Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable)
Memory Range: 0xfddf0000-0xfddfffff (rw,non-prefetchable)
I/O Ports: 0xbc00-0xbcff (rw)
Memory Range: 0xfdd00000-0xfdd1ffff (ro,non-prefetchable,disabled)
IRQ: 16 (no events)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: “pci:v00001002d00007183sv00001028sd00000D02bc03sc00i00”
Driver Info #0:
XFree86 v4 Server Module: radeonhd
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #24 (PCI bridge)
41: PCI 300.1: 0380 Display controller
[Created at pci.318]
Unique ID: kEn8.bcVrYw36tO6
Parent ID: 8otl.OB2BsRrVga5
SysFS ID: /devices/pci0000:00/0000:00:04.0/0000:03:00.1
SysFS BusID: 0000:03:00.1
Hardware Class: graphics card
Model: “ATI RV516 [Radeon X1300 Pro] (Secondary)”
Vendor: pci 0x1002 “ATI Technologies Inc”
Device: pci 0x71a3 “RV516 [Radeon X1300 Pro] (Secondary)”
SubVendor: pci 0x1028 “Dell”
SubDevice: pci 0x0d03
Memory Range: 0xfdde0000-0xfddeffff (rw,non-prefetchable,disabled)
Module Alias: “pci:v00001002d000071A3sv00001028sd00000D03bc03sc80i00”
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #24 (PCI bridge)
I use the default radeon driver xorg-x11-driver-video-radeonhd from openSuSE, version 1.3.0_20100325.
Thanks for your help
G.Hammer
Do you mean it occurs randomly in both cases ? or occurs all the time in both cases?
It occurs randomly in both cases. I cannot reproduce the error.
OK, an ATI Radeon X1300 (legacy hardware) using the open source radeon driver. That does not provide much ‘leeway’ for changing drivers. Choices in this case are FBDEV (very slow performance), or VESA (slow performance), or radeonhd (no longer maintained much) or radeon (which you have installed now).
Well, you have that xorg-x11-driver-video-radeonhd rpm installed but you are not using a driver from that rpm. The radeon driver is in the xorg-x11-driver-video rpm and NOT in the xorg-x11-driver-video-radeonhd rpm. I attempted to explain what I understood about all of this here: openSUSE Graphic Card Practical Theory Guide for Users
If you wanted to force use of the radeonhd driver you would need to either
Section "Device"
Identifier "Default Device"
#Driver "radeon"
Driver "radeonhd"
## Required magic for radeon/radeonhd drivers; output name
## (here: "DVI-0") can be figured out via 'xrandr -q'
#Option "monitor-DVI-0" "Default Monitor"
EndSection
… but before you do any such edit, install the program midnight commander (mc) or some other ascii editor that you are comfortable in using, so that if you get stuck in a full screen text mode, you are happy to edit the 50-device.conf file. For example with midnight commander you can type ‘mc’ and get a very user friendly text editor.
After making such an edit you need to restart to test.
Did you check the BIOS date to see if there is an update ?
Next time this happens, can you boot to a liveCD, and then while running from the liveCD, mount your hard drive and open with a text the following files and copy and paste their contents (one at a time) to the web site: SUSE Paste
Be certain to get the ones on the hard drive and not the ones generated by the boot live CD.
I changed the “50-device.conf” to Driver “radeonhd”. But with this setting KDE won’t start anymore.
BIOS is up to date.
I sent you the three files.
ok, then simply remove (or comment out) that entry.
Sent me 3 files ??
ahh … we have a miss-communication here. I guess that’s my fault in assuming too much. Please note that’s a general paste site. I have no special access. None. The only way I can find anything on that site is if you give me the URL/web address where you posted the information.
I’m a openSUSE user just like you. No special status other than I am a volunteer moderator (and that’s debatable as to any specialty, as I spend a lot of volunteer time for this - with the main gratification being the occasional thank-you and self gratification in that I am paying back a bit into open Source by my efforts on this forum) . I’m not a Novell nor SuSE-GmbH employee.
So that’s one more reason to thank you very much for your help.
You can find the three files here:
SUSE Paste
SUSE Paste
SUSE Paste
Hmmm … any chance this is a wireless driver problem instead ? What I see in two of those 3 log files are wireless driver activites.
What happens if you disable your wireless. Does the problem still happen ?
The PC has no wireless connection, so what could I disable?
But I found another problem: the three files from above do not show the errors when the PC crashes!
I deleted these three files again and again in /var/log and restarted the PC until he crashed. When he crashed I started with a LIVE-CD and there were no new files. So the PC crashes before he could generate any files.
Hmmm … too bad. If that is the case, then there is not much I can suggest.
It seems that the error not occurs when I start the PC in ‘Failsafe’ mode.
So I will try the different kernel parameters in normal mode.
Due to your suspicion that it could be a graphical problem I will start with the ‘nomodeset’ parameter.
I will tell you the result tomorrow.
From what I have read, what is supposed to happen, when one specifies ‘nomodeset’ is the KMS identification does not take place (I think) and openSUSE reverts to a different graphic driver.
So in this case, instead of using the ‘radeon’ driver, openSUSE should theoretically revert to the ‘radeonhd’ driver.
When your PC is in ‘FailSafe’ what driver is it using? Is it using the VESA or FBDEV driver?
If you find nomodest consistenly works, you could try things like running “yast” (you can run yast in text mode with root permissions if X window not available) and navigate to yast > System > /etc/sysconfig Editor > System > Kernel > NO_KMS_IN_INITRD and change it to “yes”. This takes a minute or two to save once changed is submitted.
And then boot with that with (and without) no modeset to see if that makes a difference. My guess thou is ‘nomodeset’ will have a more significant effect than applying “yes” to NO_KMS and that it won’t help to set NO_KMS_IN_INITRD to YES.
In normal mode I get with “lspci -v” in the section “VGA compatible controller” the line: kernel driver in use: radeon
In normal mode with ‘nomodeset’ this line is missing and there is no statement to any driver.
In Xorg.0.log there are in both cases the same lines regarding ‘radeon’
25.852] (II) LoadModule: “radeon”
25.853] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
25.854] (II) Module radeon: vendor=“X.Org Foundation”
So what does this mean? Will in the normal mode the driver be loaded twice with the kernel and with starting of the GUI?
In that case, it is possible to determine the graphic driver in use by either looking at loaded modules with:
lsmod
however it takes a bit of experience knowing what to look for.
or look at the content of /var/log/Xorg.0.log file, which also takes a bit (albeit less) knowledge to know what to look for.
If you wish you could post the content of both the ‘lsmod’ and the content of Xorg.0.log file on SUSE Paste and myself or someone can advise as to what graphic driver we believe to be running in such a case.
Thats the place to look, but instead you need to look for something like many many many lines with:
(II) Radeon
or
(II) RadeonHD
or
(II) VESA
or
(II) FBDEV
and it may be (++) instead of (II) … I’m not at a linux pc at this moment and do not know this off the top of my head.
In the process of X starting its possible for a driver to be loaded and then immediately unloaded. I don’t know if this is the case, but I believe it can be the case.
With ‘nomodeset’ PC was booting every hour during the night.
Find the output of lsmod here:SUSE Paste
Find Xorg.0.log here: SUSE Paste
I’m sorry, but the Xorg.0.log from this morning was the wrong one!!
Find the correct one when booting in Failsafe-mode here: SUSE Paste
You are right with your suspicion that Radeon driver is not used in Failsafe mode.
I changed the NO_KMS_IN_INTITRD to “yes”. The effect was, that without ‘nomodeset’ as kernel parameter the PC crashed as before but later on in the boot process. With ‘nomodeset’ as kernel parameter booting is ok. Therefore I changed NO_KMS_IN_INITRD back to “no”.
Yes , I can see from that Xorg.0.log file that “failsafe” is using the FBDEV driver which is very very slow (but reliable) performance.
You could try the vesa driver.
Try editing the /etc/X11/xorg.conf.d/50-device.conf file, changing it to:
Section "Device"
Identifier "Default Device"
#Driver "radeon"
**Driver "vesa"**
## Required magic for radeon/radeonhd drivers; output name
## (here: "DVI-0") can be figured out via 'xrandr -q'
#Option "monitor-DVI-0" "Default Monitor"
EndSection
and then reboot, use the boot code “nomodeset” and see if that boots (to give slight superior performance over the fbdev with the vesa driver).
If that does not work, then remove the line Driver “vesa”
Its also possible it is another boot code that allows your PC to boot to FailSafe settings.