My wife's system has the Intel 845 video chipset "on-board," and boots to a black screen if no "steps" are taken. (See my posts, above, for a description of the "steps.") An interesting sidelight is that her box was delivered (a few years ago) with Vista installed, and Vista also booted to a blank screen when an update to the Intel driver was shipped by Microsoft.

The problem with the new driver version(s) distributed by Intel is, I believe, that they don't work properly with LCD displays larger that 19". Switching her system back to a 19" screen got a display that worked fine, and I was able to revert the Vista system to the older driver (since my wife has an occasional need for MS) and apply the steps described above to her main Fedora installation.

Re the Fedora she uses: Fedora installs the default Xorg video drivers in the "Initial RAM disk" (initrd) image file, so the boot messages and artwork are sent to a black screen, and nothing is visible before the initrd image restarts the X-server using the /etc/X11/xorg.conf file for the display of the login screen. (I could fix that by recreating the initrd file with the mkinitrd command, but, for the Intel problem, it's not worth the effort. On the other hand, my systems use nVidia and Radeon drivers, and the FOSS ones installed by the Xorg defaults don't work, and I have to replace the initrd image so I can install the correct drivers.)

UPDATE

I eventually got the networking solved on that old laptop, so since all that would install to a desktop was Slackware, that is what I went with. It works OK with the VESA driver, quick and snappy, so I will probably just stay with it. KDE is reasonably easy for my wife to deal with.

However, since I first posted here, I have found that a workaround to this problem has been to append the kernal boot line with "i915.modeset=1". I didn't have much hope this would work, but I have tried all of the live CD's I did previously (Ubuntu, Fedora, etc.) using this, and they all worked. None crashed at all. So this might just be the cure for anyone else still dealing with this problem. Fedora was quite slow, but the graphics worked fine and they didn't at all before appending the kernel boot line.

Since Slackware is running OK, I can always revert back to my current set up with the VESA driver, but I am going to try to use the i915 driver and append the LILO boot line with this and see if there is any improvement in graphic performance.

Bob

1 members found this post helpful.

If you have not tried what I have written above, give it a try. It worked for me. If you need instructions on how to do it, just post back.

Bob

I have a problem of the same kind like described in the predecing posts of this thread. I will supply a combined step-by-step description of various single helping comments of this thread, so it is helpful for those with similar problems;
and gives a chance to get help for my own problem.

I upgraded in the past from FC11 to FC12
========================================
This was a relatively rapid upgrade, an upgrade in the proper sense, not a total re-installation, and all was working fine and better.

I upgraded the same system these days from FC12 to FC13.
===========================================
It was in fact a re-installation of the whole system, evidently accompanied by a transfer of user identities, mail messages and so on (I could not check most of this).
If I would have known that it is done this way, - I would never have done a re-installation for a properly running system.
Among others, after installing the packages (with changing package name displays), the installation software then worked for hours without displaying some information about the ongoing background job. (Desktop PC, chip speed 1800, Ram 512 DDR2).

Possibly it did indexing of the file data base (for the command locate)?
There are 50 000 files on the hard disk main usage partition, in several partitions back-ups of the 50 000 files... Much, if it was the data base creation.
This unexpected time needed made the hard disk run permanently from the morning until the afternoon, for the hottest day of the year, close to 40 degree C, no option to interrupt / to resume later.

The installation done under these conditions has an increased write error risk. At least, the IDE hard disk tray (removable...) has been damaged by this - it does since then not any more work on some other PC here (the HD itself does).

But I think writing was fault-free. The error is probably that FC13 has problems with the video cards, which both are properly detected by FC10 and FC11 (und a past upgrade from FC11 to FC12).
(One is a MSI card - for the other, information to know the chip set is specified here below.)

=== Now the step-by-step instruction like announced above:

To locate the error, interactive mode is required.
=============================================
During the boot display, press: <Escape>
On top of the screen: The command how to enter interactive use.
You MUST activate this. Otherwise the failing command is possibly not displayed.
The failing command is something like:
Start local service

During boot of FC13: To switch from/to the terminal level:
================================
Key combination - simultaneously - : <Control> <Alt> <Fn1>
back: <Control> <Alt> <Fn2>

Test the error reason:
=========================
Command: startx
Resulting display: "fatal server error: no screens found."
(and other messages)

Create a configuration file for tests: ... .new
================================================
Xorg -configure

A file is created, a test command is supplied:
X -conf /root/xorg.config.new
Type it - or better copy it with the mouse.
In my case, this command supplies a black screen.

What is inside the created file?
=================================
gedit does not yet work in this context.
instead was used: vim /root/xorg.config.new
For the important lines, the display is as follows:

Section "Device"
Identifier "Card0"
Driver "Radeon"
Vendor Name "ATI Technologies Inc"
Board Nane "Radeon RV100 QY [Radeon 7000 VE]"
BusID "PCI 1:0:0:0"
EndSection

There is an instruction displayed how to test this file.
=========================================
When testing, the result is identical, a dark screen.
(It was to expect that it is the same...)

There is also an instruction displayed how to move this file to the proper location, to make it the new valid configuration.
I did NOT apply this.

2 AGP graphic cards - same error behaviour - but ... FC13 HAS the required features
===========================================
Both graphic cards were / are working fine for earlier FEDORA versions: FC 10, FC 11, FC12 when upgradefrom FC11.

And now, more astonishing: The same hardware configuration (same PC, same graphics card, same flat screen 17'') worked fine when used with a different hard disk on which I just had installed the KDE LIVE version from FC13.

This means: FC13 possesses the required feature:
a) I suppose that KDE LIVE is entirely a subset of the complete FC13.
b) I suppose that the upgrade from FC12 to FC13 installed a COMPLETE FC13, with everything inside which is inside KDE LIVE of FC13.

c) I suppose that the upgrading on the HD did NOT suffer from the environmental heat - hence is correct
(it finished with the correct re-boot messages, after a total of nearly 10 hours - approx. 3 to 5h for background downloads

Option: To install FC13 with the KDE Live CD, then to complete by yum + others
===============================================
While yum worked instantly - as far as I remember - with KDE LIVE for FC10,
yum does not work instantly on KDE LIVE for FC13 (path problem or so - possibly a normal matter).
There should be ways to settle this; but I think I anyway will not go this way.

Hopefully that the experts of this forum have some good consult for video card problem?
===========================================
Otherwise I would totally re-install FC13 on the same hard disk. Perhaps it is just a problem created during the upgrading process.

Added July 18:
===============
The solution is probably:
- to use the properly working new installed FC 13, to generate there interactively the X configur. file;
- then generat the same by the non-working upgrade to FC13.

Save both files to an SD card via USB. Run diff on these 2 files, to find if there is some vital difference.

Added July 23
==================
As there is so far no following post, I appended this to the text above.
The problem was settled as follows:
On the HD with FC13, upgraded fom FC12, was a file /etc/X11/xorg.config
approx 9oo Byte, some minimal settings.
Created with the date of upgrading. It is NOT created when installing RED HAT for the first time on a HD.
I renamed this file (hence stopped this way its use), and then X Windows started properly.

Apparently, this file had received a high execution precedence and therefore was taken instead of the default automatic detection of the hardware environment.

The upgrading from FC12 to FC13 had downloaded & installed the total of approx 2000 packages - probably ALL. But it still was a upgrade: The email address identities (and last mails) where still present after upgrading.

It is possible that some, many or most users upgrading from FC12 FC13, will have similar problems. It is possible, instead, that it was a single case problem.

=== While being a bit unhappy for the wasted time, I will not forget to express my thanks to RED HAT for making FEDORA avaible for us, and this free of fees.

I have almost the same problem (desktop system config. - P4 1.8GHz, Intel 845GVAD2 MoBo, 512 MB RAM, 19" LCD monitor). As recommended in the "Fedora 13 Common Bugs" article, created the "xorg.conf" file , tried VESA "Driver" and Intel "Driver" both in this file, the former working for much longer period without freezing up X Windows but still ended up in that state after a couple of hours. I was running FC11 for more than a year when a disk crash made me go in for reinstallation. Unfortunately, I have not the same stability since installing FC13.
What I would like to do is leave my system running almost all the time, without bothering to cold boot.
I am planning to give FC12 a try, as mentioned right at the beginning of this chain. Any other thoughts ?

Thanks in advance.

Regards,

Are you sure that the problem is the video driver? With only 512Mb RAM, you may just be waiting for the swap file to deliver a needed memory page which, depending to which pages are on the swap file, can take more than five minutes. If that's your problem, your screen and keyboard would seem "frozen," but your hard disk drive(s) would be active.

Sorry but it is indeed a driver issue. I have Slackware 13.0 installed now and kde hangs. xorgsetup doesnt even recognize my card correctly only as intel.I run slax 6.07 which is based on Salckware 12.0 no problem detects card and 22 inch moniter and displays all correctly.

I hear it is related to kms but can not confirm this yet. It seems the driver that ships with newer releases useskms to display on wide montiors. I have a copy of 2.9 which is supposed to be the last driver that does not do this. I will be installing this driver and will post back the results.

To answer to the question raised by "PTrenholme" -

I believe the problem is with video driver for the following reasons -
* FC11 was working perfectly fine till my (6-year old) HDD gave in a couple of months back;
* I have structured the file system on two drives - with "/boot", "/" on one and "/home" and swap on the other which I think would give better performance when it comes to swapping as compared to a single disk;
* I have tried leaving the system running for 10-15 min.s, just to see its "thrashing" and not "frozen" and so should be given time to recover but this did not work;
* After making changes related to power-saving mode etc. using "gconf-editor", the system was not freezing randomly, as was the case before i.e without "gconf-editor" changes;

Now, one interesting obvervation -
I have been booting my system using "SystemRescue CD" and it seems to be working fine (i.e. no frozen desktops; left running for a couple of days and still problem - just move the mouse and it wakes up) !

Regards,

For rap: Are you saying that changing the power-saving settings "fixed" your problem? If so, what changes did you make? (Other people may read this thread, and want to know how you solved your problem.)

Sorry ... I am not saying that changing setting with "gconf-editor" "fixed" the problem but it did seem to make things better. How I reached that conclusion will need to be described in a little more detail so kindly bear with me (!) -

I installed FC13 after my perfectly-stable FC11 which was running with a custom xorg.conf (as described in the "Common Bugs" page) was rendered unsable due crash of my 6-year old HDD which had the "/boot" & "/" partitions.
After getting a new HDD and installing FC13 (the latest stable), the system was freezing up randomly right from day one. I thought applying all updates would resolve the issue but it did not. Some persistence & cold-boots (hold the power button for 5-10 sec.s) later, I noticed at least one pattern - if you leave the system unattended even for a few minutes, the monitor used to go in a power-saving mode and it would hang thereafter, with HDD light on. It did not however, recover even after leaving it in that state for 10-15 min.s so back to cold-boot it was !
Little study and I found "gconf-editor" notes somewhere around this type of problem. Since this package is not installed by default, I installed it and changed the settings related to power-savings (under "/apps/gnome-power-manager") ... excellent utility that gives you a lot of control which should be part of the core packages, and has nice "search" within (search for "power"). The default settings are such that they are best suited for a laptop (screen goes into power-saving mode after just a minute or two of inactivity, etc.). It improved the situation only a little bit !

Again some more study and came across FC13 Common Bugs ("5.1 Miscellaneous graphical problems") so created xorg.conf but, but played around by keeping "Driver" as "Intel" which seemed to work, but only for a short while. Then changed the driver to "vesa" which seemed to resolve the problem (of hanging due to inactivity) and ramdom freezing was almost gone. Mind you, all along, the "gconf-editor" setting had already been changed (no power saving mode, etc. since I run my desktop with a UPS attached). The "vesa" driver may not support the best monitor settings (mine is 19" wide-format with best resolution of 1440 x 900).
I said "almost" because I had left the system unattended for some time (couple of hours maybe) and came back only to notice the system had "frozen", with the HDD light on. Did a cold-boot again but when the system started, the new PATA HDD that I had installed was not showing up in CMOS which, by all accounts, seems to be a hardware problem. I have asked the manufacturer for a replacement which is still awaited so here I am running my system with a bootable System Rescue CD, which, incidently, seems to be perfectly stable and moreover - the monitor is at its best resolution !

So now, working on trying to figure out the following (based on my experience so far) -
* why is it that "xorg.conf" with "intel" "Driver" seems to be little more stable as compared to the default one which is without that conf file itself?
* how is System Rescue CD video driver different from the one that comes with FC13 (and perhaps Ubuntu) that makes it work just fine on the 845GVAD2 MoBo (and the built-in 82845G graphics controller)?

Thanks for your patience

Regards,

Does the xorg.conf file you use differ from the one generated by the Xorg :1 -configure command? If not, then there should be no difference between having the xorg.conf file or not, because the fife displayed by the Xorg command is that one that is used if there is no xorg.conf file in any loction searched by the server.
IIRC, SystemRescue uses the gentoo Linux distribution, not Fedora, so you're probably using an older kernel release and different versions of the X-server and other software.

Oh, about your bad disk drive: Did you do the obvious checks of replacing the drive cable and using the secondary connection on your other board (if you have one)? (Most older computers supported four disk drives, with two ATA drive connections on each of two cables, and two ports on the mother board.)

DIfferent version of X server/drivers? http://www.sysresccd.org/Detailed-packages-list
A couple of suggestions:

1. (recommended): If the SystemRescueCD uses an xorg.conf file, try using it as your system's xorg.conf file
2. (don't blame me if it breaks things): dig back through koji http://koji.fedoraproject.org/koji/packages, grab the xorg files equivalent to the versions used by the SystemRescueCD, and install them in place of the FC13 xorg files.

My monitor requires an xorg.conf file to get beyond 800x600 with the nouveau driver (FC13 and beyond); I keep a a working version handy and copy it as needed. Back before the nouveau driver began working for me in Fedora, I'd upgrade X to try each new version, but when it wouldn't work, I'd downgrade X back to a version that worked with the proprietary nvidia driver.

1 members found this post helpful.

Um, this is a thread about a Intel 845 integrated graphic driver, not a nVidia one.

But I find that the nVidia propitiatory driver works much better than the nouveau one, even if the nVidia firmware is installed. (It's not installed by default.) I just install the driver from the RPM Fusion repositories, and everything (including "3D") works quite well.

That's what I get for keeping multiple tabs open and not paying attention to which tab is active when replying.

This chipset has always been an issue, and new distros generally will not work.

Try Ubuntu 8.04 it should just work. From memory you can update to about 9.04 before the wheels fall off.