I've got a new-ish system that I've been trying to get working that's
very close; the only things left are networking (which the latest e1000
driver from sf.net might fix) and graphics.
The system is a DG33TL micro ATX motherboard with a 2.13GHz Core 2 Duo
processor and 2GB RAM. The graphics adapter is:
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 02) (prog-if 00 [VGA])
Subsystem: Intel Corporation Unknown device 5044
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 22
Region 0: Memory at 90280000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at 2430 [size=8]
Region 2: Memory at 80000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at 90100000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 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-
It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through
2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't
start up, and I get this at the end of my Xorg.log:
============================================
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x006ff000 (pgoffset 1791)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x6ff000 failed (Invalid argument)
Fatal server error:
Couldn't bind memory for front buffer
============================================
Up until that (II) line, the logs are basically identical, and the working
one just goes into another xf86BindGARTMemory call afterwards, then goes
along its merry way. The version of the Intel X.org driver is
2.1.1-0ubuntu5. I've attached a diff of dmesg outputs for the Ubuntu
2.6.22-12 kernel and 2.6.23-rc9.
Matt
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote:
> It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through
> 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't
> start up, and I get this at the end of my Xorg.log:
>
AOL. And I was in the middle of watching a bloody movie too.
commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
Author: Zhenyu Wang <[email protected]>
Date: Tue Sep 11 15:23:57 2007 -0700
intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data stolen memory and be seperate,
so don't subtract it in stolen mem counting.
Signed-off-by: Zhenyu Wang <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Cc: Dave Jones <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Looks to be the commit that breaks things.
Regards,
Kyle M.
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
> commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
> intel_agp: fix stolen mem range on G33
> G33 GTT stolen memory is below graphics data stolen memory and be seperate,
> so don't subtract it in stolen mem counting.
>
Found it, without this corresponding change to xf86-video-intel, this
breaks utterly:
commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca
Author: Zhenyu Wang <[email protected]>
Date: Wed Sep 5 14:52:56 2007 +0800
Fix G33 GTT stolen mem range
G33 GTT table lives in seperate stolen mem with
graphics data stolen mem.
I think this should be reverted for 2.6.23, it certainly doesn't seem to have
been appropriate for 2.6.23-rc6.
Cheers,
Kyle M.
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin <[email protected]>
---
drivers/char/agp/intel-agp.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index a5d0e95..141ca17 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,11 +506,6 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
- /* G33's GTT stolen memory is separate from gfx data
- * stolen memory.
- */
- if (IS_G33)
- size = 0;
switch (gmch_ctrl & I855_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
--
1.5.3.3
On Sat, Oct 06, 2007 at 01:34:10AM -0400, Kyle McMartin wrote:
> On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
> > commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
> > intel_agp: fix stolen mem range on G33
> > G33 GTT stolen memory is below graphics data stolen memory and be seperate,
> > so don't subtract it in stolen mem counting.
> >
>
> Found it, without this corresponding change to xf86-video-intel, this
> breaks utterly:
>
> commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca
> Author: Zhenyu Wang <[email protected]>
> Date: Wed Sep 5 14:52:56 2007 +0800
>
> Fix G33 GTT stolen mem range
>
> G33 GTT table lives in seperate stolen mem with
> graphics data stolen mem.
>
> I think this should be reverted for 2.6.23, it certainly doesn't seem to have
> been appropriate for 2.6.23-rc6.
>
> Cheers,
> Kyle M.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 10/06/2007 07:42 AM, Kyle McMartin wrote:
> This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
> breaks horribly if you aren't running an unreleased xf86-video-intel
> driver out of git.
I guess, this will break my graphics, no?
http://lkml.org/lkml/2007/9/20/447
> Conflicts:
>
> drivers/char/agp/intel-agp.c
>
> Signed-off-by: Kyle McMartin <[email protected]>
> ---
>
> drivers/char/agp/intel-agp.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
> index a5d0e95..141ca17 100644
> --- a/drivers/char/agp/intel-agp.c
> +++ b/drivers/char/agp/intel-agp.c
> @@ -506,11 +506,6 @@ static void intel_i830_init_gtt_entries(void)
> break;
> }
> } else {
> - /* G33's GTT stolen memory is separate from gfx data
> - * stolen memory.
> - */
> - if (IS_G33)
> - size = 0;
> switch (gmch_ctrl & I855_GMCH_GMS_MASK) {
> case I855_GMCH_GMS_STOLEN_1M:
> gtt_entries = MB(1) - KB(size);
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
On Sat, 6 Oct 2007, Jiri Slaby wrote:
>
> I guess, this will break my graphics, no?
http://lkml.org/lkml/2007/9/20/447
Can you try it?
We do have a rule about "no regressions", so I think we'll have to do the
revert, but it would be nice to hear what the consequences for the revert
is for the affected hardware and new X.org..
Linus
On Sat, 2007-10-06 at 08:59 -0700, Linus Torvalds wrote:
> We do have a rule about "no regressions", so I think we'll have to do the
> revert, but it would be nice to hear what the consequences for the revert
> is for the affected hardware and new X.org..
No regressions is more important than making new X.org bits work. I'll
make sure that any future fixes for this are tested against older X
versions before having them sent along.
--
[email protected]
On 10/06/2007 09:29 PM, Keith Packard wrote:
> On Sat, 2007-10-06 at 08:59 -0700, Linus Torvalds wrote:
>
>> We do have a rule about "no regressions", so I think we'll have to do the
>> revert, but it would be nice to hear what the consequences for the revert
>> is for the affected hardware and new X.org..
Agree with the first part. Here comes the X log diff:
--- orig 2007-10-07 11:57:50.000000000 +0200
+++ agp 2007-10-07 11:56:07.000000000 +0200
@@ -3,7 +3,7 @@
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
-Current Operating System: Linux bellona 2.6.23-rc8-mm2_64 #58 SMP Fri Sep 28
08:52:12 CEST 2007 x86_64
+Current Operating System: Linux bellona 2.6.23-rc8-mm2_64 #59 SMP Sun Oct 7
11:43:55 CEST 2007 x86_64
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7
Before reporting problems, check http://wiki.x.org
@@ -12,7 +12,7 @@
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 7 11:57:20 2007
+(==) Log file: "/var/log/Xorg.0.log", Time: Sun Oct 7 11:54:36 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Screen0" (0)
@@ -34,7 +34,8 @@
(**) Option "BlankTime" "8"
(**) Option "StandbyTime" "10"
(**) Extension "Composite" is enabled
-(II) Open ACPI successful (/var/run/acpid.socket)
+(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
+(II) No APM support in BIOS or kernel
(II) Loader magic: 0x7be760
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
@@ -760,18 +761,18 @@
(II) intel(0): 0x08000000-0x09ffffff: textures (32768 kB)
(II) intel(0): 0x10000000: end of aperture
drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 10, (OK)
+drmOpenDevice: open result is 9, (OK)
drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 10, (OK)
+drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 10, (OK)
-drmOpenByBusid: drmOpenMinor returns 10
+drmOpenDevice: open result is 9, (OK)
+drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) intel(0): [drm] DRM interface version 1.3
(II) intel(0): [drm] created "i915" driver at busid "pci:0000:00:02.0"
(II) intel(0): [drm] added 8192 byte SAREA at 0x2efff000
-(II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x7f794b3bb000
+(II) intel(0): [drm] mapped SAREA 0x2efff000 to 0x7fd637f76000
(II) intel(0): [drm] framebuffer handle = 0xd4000000
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): [drm] Registers = 0xffa80000
@@ -838,11 +839,11 @@
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 11, (OK)
+drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 11, (OK)
-drmOpenByBusid: drmOpenMinor returns 11
+drmOpenDevice: open result is 10, (OK)
+drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
@@ -906,7 +907,7 @@
(II) <default pointer>: ps2EnableDataReporting: succeeded
(II) Mouse0-usb-0000:00:1d.0-1.2/input0: Off
(II) intel(0): [drm] removed 1 reserved context for kernel
-(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7f794b3bb000
+(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7fd637f76000
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
And it seems to work, so I think no regression here.
regards,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
On Sat, Oct 06, 2007 at 12:41:21PM +0200, Jiri Slaby wrote:
> On 10/06/2007 07:42 AM, Kyle McMartin wrote:
> > This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
> > breaks horribly if you aren't running an unreleased xf86-video-intel
> > driver out of git.
>
> I guess, this will break my graphics, no?
> http://lkml.org/lkml/2007/9/20/447
You need to upgrade Mesa.
Cheers,
Daniel