Created attachment 141451 [details]
Screenshot of corrupted display

The Screenshot was taken May 9, as this has been happening before, but the effect is identical to todays.

This looks like a corrupted X display similar to the radeon driver.

Could you attach xorg.conf and Xorg.0.log? Thanks.

Created attachment 142427 [details]
/etc/x11/xorg.conf

Created attachment 142428 [details]
/var/log/Xorg.0.log

Created attachment 142429 [details]
most recent screenshot of corrupted display

This gets nicer each time ;-)

Actually the distortion appears on every logout ( shutdown of the x-server ) sometimes it recovers normally with hickups, mostly it just freezes the system.

My guess is, it's some kind of leaking memory or plain memory allocation misbehavoiur.

Freeze with intel driver. Hmm ...

DRI is enabled. Does it still happen when you disable 3D support?

It seems to be a good starting point, happened 4 times while trying to remove 3d. ( Computer/Control Center/Graphics Card and Monitor uncheck 3D).

It may help you to know that it hapens in Sabayon as well, but not in Fedora 7 rc2. 

Can't tell now whether it's getting better, will report back after a few logouts.

I did a couple of logout/login sequences as well as reboot and shutdown. System hang did not occur so far. The display is still distorted when x is switched off, but much less massive than before. Imagine the screen shot, where the upper 1/8th was blue with white streaks emanating downward. Now only a few bright spots where the lower border of the distortion was. Alas cant make a screen shot, as this passes too fast.

In Sabayon it looks much like I documented with the screenshots but doesn't hang, in Fedora 7 the screen stays completely dark when switching (3D enabled in both).

> It may help you to know that it hapens in Sabayon as well, but not in Fedora
> 7 rc2. 
Unfortunately this information is rather useless as long as I don't know, which gfx driver is used for your machine by these distributions. Maybe i810?
Maybe fbdev? Maybe vesa? Maybe intel? Which version?

Well, I was under the impression they both use "intel", otherwise I wouldn't have bothered you. I will check the versions for you as well.

OK, for Fedora 7 rc2 its "intel" in the xorg.conf, uname -a produces: Linux localhost.localdomain 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:35:01 EDT 2007 i686 i686 i386 GNU/Linux.

The package manager lists:

xorg-x11-drv-i128-1.2.0-5.fc7.i386
xorg-x11-drv-i740-1.1.0-3.fc7.i386
xorg-x11-drv-i810-2.0.0-3.fc7.i386

Created attachment 143321 [details]
Fedora 7 rc2 xorg.conf

So Fedora 7 uses the same driver as we do. Possibly RH applied a patch we don't have. To rule out a configuration issue, you can test once more with RH's xorg.conf.

copied  attachment (id=143321) to /etc/X11/xorg.conf, reboot to make sure it's used.

Logging out causes the same distortion as with the openSuSE xorg.conf.

You may check the src rpm from http://ftp.netcraft.com.au/pub/fedora/linux/releases/7/Fedora/source/SRPMS/xorg-x11-drv-i810-2.0.0-3.fc7.src.rpm 
for patch level.

Thanks for testing with RH's config file. I could only find an unrelated DRI patch in the source RPM. So it must be something different. What about driver version in Sabayon, which suffers from the same problem?

Not sure what the Sabayon driver versions are, they have a completely different package management system, didn't find enough motivation so far to uncover it's secrets :-(

xorg.conf attached

Created attachment 143463 [details]
Sabayon xorg.conf

P.S. since disabling 3D I haven't expeienced another freeze so far, only the corrupted picture while screen is in transition.

Ok. Obviously Sabayon uses "i810" - which means nothing, since normally this is a symlink to "intel", which includes the required "i810" symbols. SUSE patched the "intel" sources, so we also can provide the old real "i810" driver to our customers, if there are any problem with the new "intel" driver.

> only the corrupted picture while screen is in transition.
So this is no permanent problem, just some garbage during reinitialization?
This would mean that DRI is the problem.

Well, to me it's not looking like random "garbage" it looks pretty constant like  attachment (id=142429) in comment #7, only, since deactivation of 3D, it doesn't freeze there any more but the (distorted) display gets overwritten by console output.

As I mentioned before, to me it looks like several programs think they should use other peoples scratchpad. I.e. memory leak or memory allocation problem

With F7 the display just gets black and then console output starts on a clean slate, as you would expect.

So the difference between enabled/disabled DRI is that with DRI enabled the machine freezes, whereas the display output is broken in both situations?

Yes

OK, now it has happened again. This time it is different though.

1) When switching from the x-session to tty1 with CTL+ALT+F1 the display showed the garble at the top for an instant.

2) When shutting the system down for reboot ( Computer / logout ) the display showed content of tty1 overlayed by garble ( see attached screenshot ) and froze.

Created attachment 144095 [details]
Screenshot of corrupted display

I think you should better go back to i810 driver. Replace intel with i810 in your xorg.conf. Does this help?

Any news on this one?

Not really, the picture has become colorful though :-)

So the Intel driver did neve work for you. Interesting.

Actually, in the meantime I found that logging out on Fedora 7 also sometimes freezes the system, only the screen is completely blank. So it may be upstream after all. Also I think it is the same issue as Bug 263147, if you agree, it should be marked duplicate.

Ok.

*** This bug has been marked as a duplicate of bug 263147 ***

Sorry if I caused confusion, alas now the duplication shows everything as resolved, which is not the case. I think rather than marking 276928 as duplicate of 263147 it should be vice versa. I.e. 263147 is a duplicate of 276928 and it's pretty much alive.

Created attachment 149037 [details]
Most recent screenshot of frozen systems display

Bug #263147 is already a duplicate of Bug #252509.

The situation looks hopeless to me. Could you add the output of "hwinfo --gfxcard", so we can use the fbdev driver for this notebook by default? Thanks.

OK, here you go.

Created attachment 149051 [details]
output from hwinfo --gfxcard

I am still content, that there are processes trying to use the same bit of memory. Is there a way I can log memory usage for the area in question ? 

Also this keeps popping up in dmesg:

workstation6l:/home/cjp # dmesg | grep agpgart
Linux agpgart interface v0.102 (c) Dave Jones
agpgart: Detected an Intel 945GM Chipset.
agpgart: Detected 7932K stolen memory.
agpgart: AGP aperture is 256M @ 0xc0000000

not sure what significance it has, but if it is possible to detect "stolen" memory, it should be possible to identify the "thief" or leave that memory alone, as the "thief" is probably trying to make use of it, thus "stealing" it again.

Ignore the dmesg warnings. These are *not* the problem at all. Beginning with Alpha6 your machine will be configured with fbdev by default.