Created attachment 24974 [details]
Xorg log before restart

Yeah, your MTRRs look like they're getting broken.  But what's also weird about your config is that GEM isn't getting initialized at all.  Why are you using the fake bufmgr?  It's going to give you pretty poor performance in general...

Also, we're removing EXA support (for many reasons, including performance), so please re-open if you can reproduce this with UXA.

Gem is disabled for i945 and i8xx cards with stock Mandriva 2.6.29.1 kernel due to extremely poor performance when combining them (patch http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/releases/2.6.29.1/4mnb2/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=markup).

Anyway, I've tried with a vanilla 2.6.30rc2-git6 kernel using gem and UXA and I've got exactly the same behavior. I reopen the bug report, edit it and add updated logs.

# lspci -vvv
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
	Subsystem: Lenovo Device 3800
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 3801
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at d0200000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at 1800 [size=8]
	Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at d0300000 (32-bit, non-prefetchable) [size=256K]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Lenovo Device 3801
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at d0280000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


 

Created attachment 25017 [details]
Xorg log before restart

Created attachment 25018 [details]
Xorg log after restart

Using vesa, mtrr are OK.

Created attachment 25246 [details] [review]
Set MTRR even w/WC PCI resources

Can you give this libpciaccess patch a try?  It tries to set up an MTRR even if we use the WC files in sysfs (which due to a kernel bug aren't always WC).

(In reply to comment #8)
> Created an attachment (id=25246) [details]
> Set MTRR even w/WC PCI resources
> 
> Can you give this libpciaccess patch a try?  It tries to set up an MTRR even if
> we use the WC files in sysfs (which due to a kernel bug aren't always WC).
> 

This patch is already applied in the libpciaccess I use (0.10.5).

This patch should keep the X driver from removing the MTRR that the kernel installed, can you give it a try?

diff --git a/src/i830_driver.c b/src/i830_driver.c
index 1887a51..cbf0bd0 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -2624,7 +2624,9 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int argc,
        return FALSE;
    }
 
-   i830_fixup_mtrrs(pScrn);
+   /* In a GEM config, the kernel manages MTRRs */
+   if (!pI830->memory_manager)
+       i830_fixup_mtrrs(pScrn);
 
    pI830->starting = TRUE;
    

Sorry for being late, the mail that should have warned me of a new message never reached my mail box.
I didn't know if the patch is still valid against 2.7.1 (I needed to rediff it), but it doesn't change anything unfortunately, I'm still losing reg03 after a X restart with existing errors found in hardware in the log.

I'm currently using x11 server 1.6.1.901, intel driver 2.7.1 and linux kernel 2.6.30-rc7 (mandriva cooker)

Created attachment 26502 [details]
xorglog after X restart

Still valid I've redone a test with a vanilla 2.6.30-rc8 kernel and updated the log

Jesse, a couple people have tested it on the downstream bug.  One person indicates it did not affect the issue.  The other tester was a bit ambiguous, but thought it might have helped with sound/video stuttering.

> --- Comment #14 from Bryce Harrington <bryce@canonical.com>
> 2009-06-07 11:23:24 PST --- Jesse, a couple people have tested it on
> the downstream bug.  One person indicates it did not affect the
> issue.  The other tester was a bit ambiguous, but thought it might
> have helped with sound/video stuttering.

I'll have to come up with a patch to monitor MTRR writes; we must be
clearing an MTRR somewhere but not rewriting it at the next startup.
Though I'm pretty sure if you were able to use GEM this problem would
go away...

Is this still an issue with more recent bits?

Assuming this is no longer an issue...