4500MHD driver crash

4500MHD driver crash

[Thomas Fjellstrom]

I've been having this little problem with the intel-gfx driver for a couple
months at least. Basically the xorg intel driver crashes with these errors:

(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
(WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684) [0x7ff1979ba684]
4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a) [0x7ff1979bb24a]
5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a) [0x7ff1979bb47a]
6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x36a1b) [0x7ff1979bca1b]
7: /usr/bin/X (0x400000+0xd4750) [0x4d4750]
8: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x319a2) [0x7ff1979b79a2]
9: /usr/bin/X (0x400000+0xd4a7e) [0x4d4a7e]
10: /usr/bin/X (0x400000+0xca92e) [0x4ca92e]
11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
Segmentation fault at address 0x29

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting


After a little google, I've found the following, seemingly similar issues:

http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html

This crash happens every few days, most of the time when I'm not even using
the laptop, and the lid is closed, but today it happened while I was
working. Was somewhat interesting to see things just disappear.

I've been trying to track this issue down for a while, someone said it
might be an app leaking pixmaps, but I haven't seen xrestop show more than
80MB of pixmaps for quite a while. Also, it usually occurs some time after
graphics start getting really slow (though this last time I didn't really
notice things getting slow). Talking a second or two for window or
desktop switching. At no time was there any errors or warnings in dmesg
related to this, nor was I running out of memory according to "free" or
the plasma system load viewer applet. Usually I had 1-2GB of ram available
(not including cache).

Thanks.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Paul Menzel]

[-- Attachment #1.1: Type: text/plain, Size: 3710 bytes --]

Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> I've been having this little problem with the intel-gfx driver for a couple
> months at least. Basically the xorg intel driver crashes with these errors:
> 
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> 
> Backtrace:
> 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
> 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684) [0x7ff1979ba684]
> 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a) [0x7ff1979bb24a]
> 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a) [0x7ff1979bb47a]
> 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x36a1b) [0x7ff1979bca1b]
> 7: /usr/bin/X (0x400000+0xd4750) [0x4d4750]
> 8: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x319a2) [0x7ff1979b79a2]
> 9: /usr/bin/X (0x400000+0xd4a7e) [0x4d4a7e]
> 10: /usr/bin/X (0x400000+0xca92e) [0x4ca92e]
> 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> Segmentation fault at address 0x29
> 
> Fatal server error:
> Caught signal 11 (Segmentation fault). Server aborting
> 
> 
> After a little google, I've found the following, seemingly similar issues:
> 
> http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
> http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> 
> This crash happens every few days, most of the time when I'm not even using
> the laptop, and the lid is closed, but today it happened while I was
> working. Was somewhat interesting to see things just disappear.
> 
> I've been trying to track this issue down for a while, someone said it
> might be an app leaking pixmaps, but I haven't seen xrestop show more than
> 80MB of pixmaps for quite a while. Also, it usually occurs some time after
> graphics start getting really slow (though this last time I didn't really
> notice things getting slow). Talking a second or two for window or
> desktop switching. At no time was there any errors or warnings in dmesg
> related to this, nor was I running out of memory according to "free" or
> the plasma system load viewer applet. Usually I had 1-2GB of ram available
> (not including cache).

At least information about the versions of the X stack you are using are
missing.

If you do not get any answer from the developers, I recommend to proceed
as documented in [1].


Thanks,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 16, 2010, Paul Menzel wrote:
> Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> > I've been having this little problem with the intel-gfx driver for a
> > couple months at least. Basically the xorg intel driver crashes with
> > these errors:
> > 
> > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access:
> > gtt bo map failed: Cannot allocate memory (WW) intel(0):
> > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access:
> > gtt bo map failed: Cannot allocate memory (WW) intel(0):
> > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access:
> > gtt bo map failed: Cannot allocate memory (WW) intel(0):
> > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > 
> > Backtrace:
> > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
> > 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684)
> > [0x7ff1979ba684] 4: /usr/lib/xorg/modules/drivers/intel_drv.so
> > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a)
> > [0x7ff1979bb47a] 6: /usr/lib/xorg/modules/drivers/intel_drv.so
> > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > (0x400000+0xd4750) [0x4d4750]
> > 8: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x319a2)
> > [0x7ff1979b79a2] 9: /usr/bin/X (0x400000+0xd4a7e) [0x4d4a7e]
> > 10: /usr/bin/X (0x400000+0xca92e) [0x4ca92e]
> > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > Segmentation fault at address 0x29
> > 
> > Fatal server error:
> > Caught signal 11 (Segmentation fault). Server aborting
> > 
> > 
> > After a little google, I've found the following, seemingly similar
> > issues:
> > 
> > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
> > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > 
> > This crash happens every few days, most of the time when I'm not even
> > using the laptop, and the lid is closed, but today it happened while I
> > was working. Was somewhat interesting to see things just disappear.
> > 
> > I've been trying to track this issue down for a while, someone said it
> > might be an app leaking pixmaps, but I haven't seen xrestop show more
> > than 80MB of pixmaps for quite a while. Also, it usually occurs some
> > time after graphics start getting really slow (though this last time I
> > didn't really notice things getting slow). Talking a second or two for
> > window or desktop switching. At no time was there any errors or
> > warnings in dmesg related to this, nor was I running out of memory
> > according to "free" or the plasma system load viewer applet. Usually I
> > had 1-2GB of ram available (not including cache).
> 
> At least information about the versions of the X stack you are using are
> missing.

Doh. Yeah, I must be tired.

xserver-xorg/sid uptodate 1:7.5+6
xserver-xorg-core/sid uptodate 2:1.7.7-2
xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
libgl1-mesa-dri/experimental uptodate 7.8.2-1
libdrm-intel1/experimental uptodate 2.4.21-1
linux-kernel 2.6.34

Using debian sid+experimental to get recent intel drivers.
 
> If you do not get any answer from the developers, I recommend to proceed
> as documented in [1].
> 
> 
> Thanks,
> 
> Paul
> 
> 
> [1] http://intellinuxgraphics.org/how_to_report_bug.html

Will do.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 16, 2010, Thomas Fjellstrom wrote:
> On July 16, 2010, Paul Menzel wrote:
> > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> > > I've been having this little problem with the intel-gfx driver for a
> > > couple months at least. Basically the xorg intel driver crashes with
> > > these errors:
> > > 
> > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > failed: Cannot allocate memory (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > failed: Cannot allocate memory (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > failed: Cannot allocate memory (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > (WW) intel(0):
> > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > 
> > > Backtrace:
> > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
> > > 3: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a)
> > > [0x7ff1979bb24a] 5:
> > > /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a)
> > > [0x7ff1979bb47a] 6: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > (0x400000+0xd4750) [0x4d4750]
> > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x400000+0xca92e)
> > > [0x4ca92e]
> > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > > Segmentation fault at address 0x29
> > > 
> > > Fatal server error:
> > > Caught signal 11 (Segmentation fault). Server aborting
> > > 
> > > 
> > > After a little google, I've found the following, seemingly similar
> > > issues:
> > > 
> > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
> > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > > 
> > > This crash happens every few days, most of the time when I'm not even
> > > using the laptop, and the lid is closed, but today it happened while
> > > I was working. Was somewhat interesting to see things just
> > > disappear.
> > > 
> > > I've been trying to track this issue down for a while, someone said
> > > it might be an app leaking pixmaps, but I haven't seen xrestop show
> > > more than 80MB of pixmaps for quite a while. Also, it usually occurs
> > > some time after graphics start getting really slow (though this last
> > > time I didn't really notice things getting slow). Talking a second
> > > or two for window or desktop switching. At no time was there any
> > > errors or warnings in dmesg related to this, nor was I running out
> > > of memory according to "free" or the plasma system load viewer
> > > applet. Usually I had 1-2GB of ram available (not including cache).
> > 
> > At least information about the versions of the X stack you are using
> > are missing.
> 
> Doh. Yeah, I must be tired.
> 
> xserver-xorg/sid uptodate 1:7.5+6
> xserver-xorg-core/sid uptodate 2:1.7.7-2
> xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> libgl1-mesa-dri/experimental uptodate 7.8.2-1
> libdrm-intel1/experimental uptodate 2.4.21-1
> linux-kernel 2.6.34
> 
> Using debian sid+experimental to get recent intel drivers.
> 
> > If you do not get any answer from the developers, I recommend to
> > proceed as documented in [1].
> > 
> > 
> > Thanks,
> > 
> > Paul
> > 
> > 
> > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> 
> Will do.

A nice fellow on the irc channel suggested I keep an eye on the gem_objects 
file. It seems that when the computer is left alone, especially with the lid 
closed, the number of objects increases a bit:

20212 objects
325713920 object bytes
6 pinned
8445952 pin bytes
137027584 gtt bytes
234881024 gtt total

Just last night, probably about 14 hours ago, X crashed (which is what 
prompted the first mail), and was started back up again. The number of 
objects then was around 19056.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Niccolò Belli]

Try librdm git, latest stable version is known to be bugged with intel-2.12.

Darkbasic

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 16, 2010, Thomas Fjellstrom wrote:
> On July 16, 2010, Thomas Fjellstrom wrote:
> > On July 16, 2010, Paul Menzel wrote:
> > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> > > > I've been having this little problem with the intel-gfx driver for
> > > > a couple months at least. Basically the xorg intel driver crashes
> > > > with these errors:
> > > > 
> > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > failed: Cannot allocate memory (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > failed: Cannot allocate memory (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > failed: Cannot allocate memory (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > (WW) intel(0):
> > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory
> > > > 
> > > > Backtrace:
> > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
> > > > 3: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a)
> > > > [0x7ff1979bb24a] 5:
> > > > /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a)
> > > > [0x7ff1979bb47a] 6: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > (0x400000+0xd4750) [0x4d4750]
> > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x400000+0xca92e)
> > > > [0x4ca92e]
> > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > > > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > > > Segmentation fault at address 0x29
> > > > 
> > > > Fatal server error:
> > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > 
> > > > 
> > > > After a little google, I've found the following, seemingly similar
> > > > issues:
> > > > 
> > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
> > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > > > 
> > > > This crash happens every few days, most of the time when I'm not
> > > > even using the laptop, and the lid is closed, but today it
> > > > happened while I was working. Was somewhat interesting to see
> > > > things just disappear.
> > > > 
> > > > I've been trying to track this issue down for a while, someone said
> > > > it might be an app leaking pixmaps, but I haven't seen xrestop show
> > > > more than 80MB of pixmaps for quite a while. Also, it usually
> > > > occurs some time after graphics start getting really slow (though
> > > > this last time I didn't really notice things getting slow).
> > > > Talking a second or two for window or desktop switching. At no
> > > > time was there any errors or warnings in dmesg related to this,
> > > > nor was I running out of memory according to "free" or the plasma
> > > > system load viewer applet. Usually I had 1-2GB of ram available
> > > > (not including cache).
> > > 
> > > At least information about the versions of the X stack you are using
> > > are missing.
> > 
> > Doh. Yeah, I must be tired.
> > 
> > xserver-xorg/sid uptodate 1:7.5+6
> > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > libdrm-intel1/experimental uptodate 2.4.21-1
> > linux-kernel 2.6.34
> > 
> > Using debian sid+experimental to get recent intel drivers.
> > 
> > > If you do not get any answer from the developers, I recommend to
> > > proceed as documented in [1].
> > > 
> > > 
> > > Thanks,
> > > 
> > > Paul
> > > 
> > > 
> > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > 
> > Will do.
> 
> A nice fellow on the irc channel suggested I keep an eye on the
> gem_objects file. It seems that when the computer is left alone,
> especially with the lid closed, the number of objects increases a bit:
> 
> 20212 objects
> 325713920 object bytes
> 6 pinned
> 8445952 pin bytes
> 137027584 gtt bytes
> 234881024 gtt total
> 
> Just last night, probably about 14 hours ago, X crashed (which is what
> prompted the first mail), and was started back up again. The number of
> objects then was around 19056.

I just came back to my laptop to find it hung. switching to a terminal gave 
me a bunch of "gpu hung" messages, several a second. It never managed to fix 
itself. Even restarting kdm didn't help.

Now that I have had to reboot, gem_objects reports 8190 objects. Seems a bit 
more sane than 20k. I've updated libdrm, it seems its version didn't match 
libdrm-intel1, that could have been causing some problems. so I'll test this 
setup. if the same gem_object leak happens I'll try with libdrm git as was 
suggested.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 17, 2010, Thomas Fjellstrom wrote:
> On July 16, 2010, Thomas Fjellstrom wrote:
> > On July 16, 2010, Thomas Fjellstrom wrote:
> > > On July 16, 2010, Paul Menzel wrote:
> > > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> > > > > I've been having this little problem with the intel-gfx driver
> > > > > for a couple months at least. Basically the xorg intel driver
> > > > > crashes with these errors:
> > > > > 
> > > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot
> > > > > allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo
> > > > > map failed: Cannot allocate memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory (WW) intel(0):
> > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > memory
> > > > > 
> > > > > Backtrace:
> > > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60]
> > > > > 3: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6:
> > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > > (0x400000+0xd4750) [0x4d4750]
> > > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x400000+0xca92e)
> > > > > [0x4ca92e]
> > > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > > > > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > > > > Segmentation fault at address 0x29
> > > > > 
> > > > > Fatal server error:
> > > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > > 
> > > > > 
> > > > > After a little google, I've found the following, seemingly
> > > > > similar issues:
> > > > > 
> > > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html
> > > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > > > > 
> > > > > This crash happens every few days, most of the time when I'm not
> > > > > even using the laptop, and the lid is closed, but today it
> > > > > happened while I was working. Was somewhat interesting to see
> > > > > things just disappear.
> > > > > 
> > > > > I've been trying to track this issue down for a while, someone
> > > > > said it might be an app leaking pixmaps, but I haven't seen
> > > > > xrestop show more than 80MB of pixmaps for quite a while. Also,
> > > > > it usually occurs some time after graphics start getting really
> > > > > slow (though this last time I didn't really notice things
> > > > > getting slow). Talking a second or two for window or desktop
> > > > > switching. At no time was there any errors or warnings in dmesg
> > > > > related to this, nor was I running out of memory according to
> > > > > "free" or the plasma system load viewer applet. Usually I had
> > > > > 1-2GB of ram available (not including cache).
> > > > 
> > > > At least information about the versions of the X stack you are
> > > > using are missing.
> > > 
> > > Doh. Yeah, I must be tired.
> > > 
> > > xserver-xorg/sid uptodate 1:7.5+6
> > > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > > libdrm-intel1/experimental uptodate 2.4.21-1
> > > linux-kernel 2.6.34
> > > 
> > > Using debian sid+experimental to get recent intel drivers.
> > > 
> > > > If you do not get any answer from the developers, I recommend to
> > > > proceed as documented in [1].
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > Paul
> > > > 
> > > > 
> > > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > > 
> > > Will do.
> > 
> > A nice fellow on the irc channel suggested I keep an eye on the
> > gem_objects file. It seems that when the computer is left alone,
> > especially with the lid closed, the number of objects increases a bit:
> > 
> > 20212 objects
> > 325713920 object bytes
> > 6 pinned
> > 8445952 pin bytes
> > 137027584 gtt bytes
> > 234881024 gtt total
> > 
> > Just last night, probably about 14 hours ago, X crashed (which is what
> > prompted the first mail), and was started back up again. The number of
> > objects then was around 19056.
> 
> I just came back to my laptop to find it hung. switching to a terminal
> gave me a bunch of "gpu hung" messages, several a second. It never
> managed to fix itself. Even restarting kdm didn't help.
> 
> Now that I have had to reboot, gem_objects reports 8190 objects. Seems a
> bit more sane than 20k. I've updated libdrm, it seems its version didn't
> match libdrm-intel1, that could have been causing some problems. so I'll
> test this setup. if the same gem_object leak happens I'll try with
> libdrm git as was suggested.

Been up half a day now since the crash,

22352 objects
354799616 object bytes
6 pinned
8445952 pin bytes
114999296 gtt bytes
234881024 gtt total

I don't suppose that is normal?

I'll try the git libdrm today.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 17, 2010, Thomas Fjellstrom wrote:
> On July 17, 2010, Thomas Fjellstrom wrote:
> > On July 16, 2010, Thomas Fjellstrom wrote:
> > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > On July 16, 2010, Paul Menzel wrote:
> > > > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom:
> > > > > > I've been having this little problem with the intel-gfx driver
> > > > > > for a couple months at least. Basically the xorg intel driver
> > > > > > crashes with these errors:
> > > > > > 
> > > > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed:
> > > > > > Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access:
> > > > > > gtt bo map failed: Cannot allocate memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory (WW) intel(0):
> > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > memory
> > > > > > 
> > > > > > Backtrace:
> > > > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60)
> > > > > > [0x7ff19b2a5f60] 3: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6:
> > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > > > (0x400000+0xd4750) [0x4d4750]
> > > > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x400000+0xca92e)
> > > > > > [0x4ca92e]
> > > > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > > > > > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > > > > > Segmentation fault at address 0x29
> > > > > > 
> > > > > > Fatal server error:
> > > > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > > > 
> > > > > > 
> > > > > > After a little google, I've found the following, seemingly
> > > > > > similar issues:
> > > > > > 
> > > > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.ht
> > > > > > ml
> > > > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > > > > > 
> > > > > > This crash happens every few days, most of the time when I'm
> > > > > > not even using the laptop, and the lid is closed, but today it
> > > > > > happened while I was working. Was somewhat interesting to see
> > > > > > things just disappear.
> > > > > > 
> > > > > > I've been trying to track this issue down for a while, someone
> > > > > > said it might be an app leaking pixmaps, but I haven't seen
> > > > > > xrestop show more than 80MB of pixmaps for quite a while. Also,
> > > > > > it usually occurs some time after graphics start getting really
> > > > > > slow (though this last time I didn't really notice things
> > > > > > getting slow). Talking a second or two for window or desktop
> > > > > > switching. At no time was there any errors or warnings in dmesg
> > > > > > related to this, nor was I running out of memory according to
> > > > > > "free" or the plasma system load viewer applet. Usually I had
> > > > > > 1-2GB of ram available (not including cache).
> > > > > 
> > > > > At least information about the versions of the X stack you are
> > > > > using are missing.
> > > > 
> > > > Doh. Yeah, I must be tired.
> > > > 
> > > > xserver-xorg/sid uptodate 1:7.5+6
> > > > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > > > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > > > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > > > libdrm-intel1/experimental uptodate 2.4.21-1
> > > > linux-kernel 2.6.34
> > > > 
> > > > Using debian sid+experimental to get recent intel drivers.
> > > > 
> > > > > If you do not get any answer from the developers, I recommend to
> > > > > proceed as documented in [1].
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Paul
> > > > > 
> > > > > 
> > > > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > > > 
> > > > Will do.
> > > 
> > > A nice fellow on the irc channel suggested I keep an eye on the
> > > gem_objects file. It seems that when the computer is left alone,
> > > especially with the lid closed, the number of objects increases a
> > > bit:
> > > 
> > > 20212 objects
> > > 325713920 object bytes
> > > 6 pinned
> > > 8445952 pin bytes
> > > 137027584 gtt bytes
> > > 234881024 gtt total
> > > 
> > > Just last night, probably about 14 hours ago, X crashed (which is
> > > what prompted the first mail), and was started back up again. The
> > > number of objects then was around 19056.
> > 
> > I just came back to my laptop to find it hung. switching to a terminal
> > gave me a bunch of "gpu hung" messages, several a second. It never
> > managed to fix itself. Even restarting kdm didn't help.
> > 
> > Now that I have had to reboot, gem_objects reports 8190 objects. Seems
> > a bit more sane than 20k. I've updated libdrm, it seems its version
> > didn't match libdrm-intel1, that could have been causing some
> > problems. so I'll test this setup. if the same gem_object leak happens
> > I'll try with libdrm git as was suggested.
> 
> Been up half a day now since the crash,
> 
> 22352 objects
> 354799616 object bytes
> 6 pinned
> 8445952 pin bytes
> 114999296 gtt bytes
> 234881024 gtt total
> 
> I don't suppose that is normal?
> 
> I'll try the git libdrm today.

Other things came up, didn't get around to installing libdrm git yet.

But for kicks I've taken the logged gem_objects "objects" data and piped it 
through gnuplot:

http://strangesoft.net/gem_objects_plot.png

The major dip is the gpu hung issue I had, with a subsequent reboot.

Interestingly enough, I just went to check the current count, between the 
time I started writing the gnuplot spec and the script to convert the log to 
tabular form, the objects count has increased a bunch:

http://strangesoft.net/gem_objects_plot2.png

>From 35k, up to 37k. It seems to keep increasing.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 18, 2010, Thomas Fjellstrom wrote:
> On July 17, 2010, Thomas Fjellstrom wrote:
> > On July 17, 2010, Thomas Fjellstrom wrote:
> > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > > On July 16, 2010, Paul Menzel wrote:
> > > > > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas 
Fjellstrom:
> > > > > > > I've been having this little problem with the intel-gfx
> > > > > > > driver for a couple months at least. Basically the xorg
> > > > > > > intel driver crashes with these errors:
> > > > > > > 
> > > > > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed:
> > > > > > > Cannot allocate memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory (WW) intel(0):
> > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > memory
> > > > > > > 
> > > > > > > Backtrace:
> > > > > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60)
> > > > > > > [0x7ff19b2a5f60] 3:
> > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6:
> > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > > > > (0x400000+0xd4750) [0x4d4750]
> > > > > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X
> > > > > > > (0x400000+0xca92e) [0x4ca92e]
> > > > > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d]
> > > > > > > 14: /usr/bin/X (0x400000+0x256f9) [0x4256f9]
> > > > > > > Segmentation fault at address 0x29
> > > > > > > 
> > > > > > > Fatal server error:
> > > > > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > > > > 
> > > > > > > 
> > > > > > > After a little google, I've found the following, seemingly
> > > > > > > similar issues:
> > > > > > > 
> > > > > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.
> > > > > > > ht ml
> > > > > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html
> > > > > > > 
> > > > > > > This crash happens every few days, most of the time when I'm
> > > > > > > not even using the laptop, and the lid is closed, but today
> > > > > > > it happened while I was working. Was somewhat interesting to
> > > > > > > see things just disappear.
> > > > > > > 
> > > > > > > I've been trying to track this issue down for a while,
> > > > > > > someone said it might be an app leaking pixmaps, but I
> > > > > > > haven't seen xrestop show more than 80MB of pixmaps for
> > > > > > > quite a while. Also, it usually occurs some time after
> > > > > > > graphics start getting really slow (though this last time I
> > > > > > > didn't really notice things getting slow). Talking a second
> > > > > > > or two for window or desktop switching. At no time was there
> > > > > > > any errors or warnings in dmesg related to this, nor was I
> > > > > > > running out of memory according to "free" or the plasma
> > > > > > > system load viewer applet. Usually I had 1-2GB of ram
> > > > > > > available (not including cache).
> > > > > > 
> > > > > > At least information about the versions of the X stack you are
> > > > > > using are missing.
> > > > > 
> > > > > Doh. Yeah, I must be tired.
> > > > > 
> > > > > xserver-xorg/sid uptodate 1:7.5+6
> > > > > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > > > > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > > > > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > > > > libdrm-intel1/experimental uptodate 2.4.21-1
> > > > > linux-kernel 2.6.34
> > > > > 
> > > > > Using debian sid+experimental to get recent intel drivers.
> > > > > 
> > > > > > If you do not get any answer from the developers, I recommend
> > > > > > to proceed as documented in [1].
> > > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Paul
> > > > > > 
> > > > > > 
> > > > > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > > > > 
> > > > > Will do.
> > > > 
> > > > A nice fellow on the irc channel suggested I keep an eye on the
> > > > gem_objects file. It seems that when the computer is left alone,
> > > > especially with the lid closed, the number of objects increases a
> > > > bit:
> > > > 
> > > > 20212 objects
> > > > 325713920 object bytes
> > > > 6 pinned
> > > > 8445952 pin bytes
> > > > 137027584 gtt bytes
> > > > 234881024 gtt total
> > > > 
> > > > Just last night, probably about 14 hours ago, X crashed (which is
> > > > what prompted the first mail), and was started back up again. The
> > > > number of objects then was around 19056.
> > > 
> > > I just came back to my laptop to find it hung. switching to a
> > > terminal gave me a bunch of "gpu hung" messages, several a second.
> > > It never managed to fix itself. Even restarting kdm didn't help.
> > > 
> > > Now that I have had to reboot, gem_objects reports 8190 objects.
> > > Seems a bit more sane than 20k. I've updated libdrm, it seems its
> > > version didn't match libdrm-intel1, that could have been causing
> > > some problems. so I'll test this setup. if the same gem_object leak
> > > happens I'll try with libdrm git as was suggested.
> > 
> > Been up half a day now since the crash,
> > 
> > 22352 objects
> > 354799616 object bytes
> > 6 pinned
> > 8445952 pin bytes
> > 114999296 gtt bytes
> > 234881024 gtt total
> > 
> > I don't suppose that is normal?
> > 
> > I'll try the git libdrm today.
> 
> Other things came up, didn't get around to installing libdrm git yet.
> 
> But for kicks I've taken the logged gem_objects "objects" data and piped
> it through gnuplot:
> 
> http://strangesoft.net/gem_objects_plot.png
> 
> The major dip is the gpu hung issue I had, with a subsequent reboot.
> 
> Interestingly enough, I just went to check the current count, between the
> time I started writing the gnuplot spec and the script to convert the log
> to tabular form, the objects count has increased a bunch:
> 
> http://strangesoft.net/gem_objects_plot2.png
> 
> From 35k, up to 37k. It seems to keep increasing.

Even with git libdrm it keeps going, it doesn't start off as bad, but it 
keeps increasing, even when the system isn't in use.

http://strangesoft.net/gem_objects_plot3.png

The part where it levels off (gets smoother) on the last section is after I 
went to bed.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 19, 2010, Thomas Fjellstrom wrote:
> On July 18, 2010, Thomas Fjellstrom wrote:
> > On July 17, 2010, Thomas Fjellstrom wrote:
> > > On July 17, 2010, Thomas Fjellstrom wrote:
> > > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > > > On July 16, 2010, Paul Menzel wrote:
> > > > > > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas
> 
> Fjellstrom:
> > > > > > > > I've been having this little problem with the intel-gfx
> > > > > > > > driver for a couple months at least. Basically the xorg
> > > > > > > > intel driver crashes with these errors:
> > > > > > > > 
> > > > > > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed:
> > > > > > > > Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory
> > > > > > > > 
> > > > > > > > Backtrace:
> > > > > > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > > > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > > > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60)
> > > > > > > > [0x7ff19b2a5f60] 3:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > > > > > (0x400000+0xd4750) [0x4d4750]
> > > > > > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > > > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X
> > > > > > > > (0x400000+0xca92e) [0x4ca92e]
> > > > > > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > > > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > > > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd)
> > > > > > > > [0x7ff199d9bc4d] 14: /usr/bin/X (0x400000+0x256f9)
> > > > > > > > [0x4256f9]
> > > > > > > > Segmentation fault at address 0x29
> > > > > > > > 
> > > > > > > > Fatal server error:
> > > > > > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > > > > > 
> > > > > > > > 
> > > > > > > > After a little google, I've found the following, seemingly
> > > > > > > > similar issues:
> > > > > > > > 
> > > > > > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashin
> > > > > > > > g. ht ml
> > > > > > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.ht
> > > > > > > > ml
> > > > > > > > 
> > > > > > > > This crash happens every few days, most of the time when
> > > > > > > > I'm not even using the laptop, and the lid is closed, but
> > > > > > > > today it happened while I was working. Was somewhat
> > > > > > > > interesting to see things just disappear.
> > > > > > > > 
> > > > > > > > I've been trying to track this issue down for a while,
> > > > > > > > someone said it might be an app leaking pixmaps, but I
> > > > > > > > haven't seen xrestop show more than 80MB of pixmaps for
> > > > > > > > quite a while. Also, it usually occurs some time after
> > > > > > > > graphics start getting really slow (though this last time I
> > > > > > > > didn't really notice things getting slow). Talking a second
> > > > > > > > or two for window or desktop switching. At no time was
> > > > > > > > there any errors or warnings in dmesg related to this, nor
> > > > > > > > was I running out of memory according to "free" or the
> > > > > > > > plasma system load viewer applet. Usually I had 1-2GB of
> > > > > > > > ram available (not including cache).
> > > > > > > 
> > > > > > > At least information about the versions of the X stack you
> > > > > > > are using are missing.
> > > > > > 
> > > > > > Doh. Yeah, I must be tired.
> > > > > > 
> > > > > > xserver-xorg/sid uptodate 1:7.5+6
> > > > > > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > > > > > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > > > > > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > > > > > libdrm-intel1/experimental uptodate 2.4.21-1
> > > > > > linux-kernel 2.6.34
> > > > > > 
> > > > > > Using debian sid+experimental to get recent intel drivers.
> > > > > > 
> > > > > > > If you do not get any answer from the developers, I recommend
> > > > > > > to proceed as documented in [1].
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 
> > > > > > > Paul
> > > > > > > 
> > > > > > > 
> > > > > > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > > > > > 
> > > > > > Will do.
> > > > > 
> > > > > A nice fellow on the irc channel suggested I keep an eye on the
> > > > > gem_objects file. It seems that when the computer is left alone,
> > > > > especially with the lid closed, the number of objects increases a
> > > > > bit:
> > > > > 
> > > > > 20212 objects
> > > > > 325713920 object bytes
> > > > > 6 pinned
> > > > > 8445952 pin bytes
> > > > > 137027584 gtt bytes
> > > > > 234881024 gtt total
> > > > > 
> > > > > Just last night, probably about 14 hours ago, X crashed (which is
> > > > > what prompted the first mail), and was started back up again. The
> > > > > number of objects then was around 19056.
> > > > 
> > > > I just came back to my laptop to find it hung. switching to a
> > > > terminal gave me a bunch of "gpu hung" messages, several a second.
> > > > It never managed to fix itself. Even restarting kdm didn't help.
> > > > 
> > > > Now that I have had to reboot, gem_objects reports 8190 objects.
> > > > Seems a bit more sane than 20k. I've updated libdrm, it seems its
> > > > version didn't match libdrm-intel1, that could have been causing
> > > > some problems. so I'll test this setup. if the same gem_object leak
> > > > happens I'll try with libdrm git as was suggested.
> > > 
> > > Been up half a day now since the crash,
> > > 
> > > 22352 objects
> > > 354799616 object bytes
> > > 6 pinned
> > > 8445952 pin bytes
> > > 114999296 gtt bytes
> > > 234881024 gtt total
> > > 
> > > I don't suppose that is normal?
> > > 
> > > I'll try the git libdrm today.
> > 
> > Other things came up, didn't get around to installing libdrm git yet.
> > 
> > But for kicks I've taken the logged gem_objects "objects" data and
> > piped it through gnuplot:
> > 
> > http://strangesoft.net/gem_objects_plot.png
> > 
> > The major dip is the gpu hung issue I had, with a subsequent reboot.
> > 
> > Interestingly enough, I just went to check the current count, between
> > the time I started writing the gnuplot spec and the script to convert
> > the log to tabular form, the objects count has increased a bunch:
> > 
> > http://strangesoft.net/gem_objects_plot2.png
> > 
> > From 35k, up to 37k. It seems to keep increasing.
> 
> Even with git libdrm it keeps going, it doesn't start off as bad, but it
> keeps increasing, even when the system isn't in use.
> 
> http://strangesoft.net/gem_objects_plot3.png
> 
> The part where it levels off (gets smoother) on the last section is after
> I went to bed.

More steady increasing, even after killing a silly screensaver that was 
leaking pixmaps. The slight dip, and the smoother line after is what 
resulted from that.. No idea what happened around the spike though.

http://strangesoft.net/gem_objects_plot5.png

So in both the gl and xrender modes for kwin's compositing, I'm getting some 
serious gem_objects leaks. Another couple days and it'll probably crash 
again.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca

Re: 4500MHD driver crash

[Thomas Fjellstrom]

On July 19, 2010, Thomas Fjellstrom wrote:
> On July 18, 2010, Thomas Fjellstrom wrote:
> > On July 17, 2010, Thomas Fjellstrom wrote:
> > > On July 17, 2010, Thomas Fjellstrom wrote:
> > > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > > On July 16, 2010, Thomas Fjellstrom wrote:
> > > > > > On July 16, 2010, Paul Menzel wrote:
> > > > > > > Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas
> 
> Fjellstrom:
> > > > > > > > I've been having this little problem with the intel-gfx
> > > > > > > > driver for a couple months at least. Basically the xorg
> > > > > > > > intel driver crashes with these errors:
> > > > > > > > 
> > > > > > > > (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed:
> > > > > > > > Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map
> > > > > > > > failed: Cannot allocate memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory (WW) intel(0):
> > > > > > > > i830_uxa_prepare_access: gtt bo map failed: Cannot allocate
> > > > > > > > memory
> > > > > > > > 
> > > > > > > > Backtrace:
> > > > > > > > 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808]
> > > > > > > > 1: /usr/bin/X (0x400000+0x67c79) [0x467c79]
> > > > > > > > 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60)
> > > > > > > > [0x7ff19b2a5f60] 3:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x34684) [0x7ff1979ba684] 4:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6:
> > > > > > > > /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X
> > > > > > > > (0x400000+0xd4750) [0x4d4750]
> > > > > > > > 8: /usr/lib/xorg/modules/drivers/intel_drv.so
> > > > > > > > (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X
> > > > > > > > (0x400000+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X
> > > > > > > > (0x400000+0xca92e) [0x4ca92e]
> > > > > > > > 11: /usr/bin/X (0x400000+0x4c7a4) [0x44c7a4]
> > > > > > > > 12: /usr/bin/X (0x400000+0x25b4a) [0x425b4a]
> > > > > > > > 13: /lib/libc.so.6 (__libc_start_main+0xfd)
> > > > > > > > [0x7ff199d9bc4d] 14: /usr/bin/X (0x400000+0x256f9)
> > > > > > > > [0x4256f9]
> > > > > > > > Segmentation fault at address 0x29
> > > > > > > > 
> > > > > > > > Fatal server error:
> > > > > > > > Caught signal 11 (Segmentation fault). Server aborting
> > > > > > > > 
> > > > > > > > 
> > > > > > > > After a little google, I've found the following, seemingly
> > > > > > > > similar issues:
> > > > > > > > 
> > > > > > > > http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashin
> > > > > > > > g. ht ml
> > > > > > > > http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.ht
> > > > > > > > ml
> > > > > > > > 
> > > > > > > > This crash happens every few days, most of the time when
> > > > > > > > I'm not even using the laptop, and the lid is closed, but
> > > > > > > > today it happened while I was working. Was somewhat
> > > > > > > > interesting to see things just disappear.
> > > > > > > > 
> > > > > > > > I've been trying to track this issue down for a while,
> > > > > > > > someone said it might be an app leaking pixmaps, but I
> > > > > > > > haven't seen xrestop show more than 80MB of pixmaps for
> > > > > > > > quite a while. Also, it usually occurs some time after
> > > > > > > > graphics start getting really slow (though this last time I
> > > > > > > > didn't really notice things getting slow). Talking a second
> > > > > > > > or two for window or desktop switching. At no time was
> > > > > > > > there any errors or warnings in dmesg related to this, nor
> > > > > > > > was I running out of memory according to "free" or the
> > > > > > > > plasma system load viewer applet. Usually I had 1-2GB of
> > > > > > > > ram available (not including cache).
> > > > > > > 
> > > > > > > At least information about the versions of the X stack you
> > > > > > > are using are missing.
> > > > > > 
> > > > > > Doh. Yeah, I must be tired.
> > > > > > 
> > > > > > xserver-xorg/sid uptodate 1:7.5+6
> > > > > > xserver-xorg-core/sid uptodate 2:1.7.7-2
> > > > > > xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1
> > > > > > libgl1-mesa-dri/experimental uptodate 7.8.2-1
> > > > > > libdrm-intel1/experimental uptodate 2.4.21-1
> > > > > > linux-kernel 2.6.34
> > > > > > 
> > > > > > Using debian sid+experimental to get recent intel drivers.
> > > > > > 
> > > > > > > If you do not get any answer from the developers, I recommend
> > > > > > > to proceed as documented in [1].
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > 
> > > > > > > Paul
> > > > > > > 
> > > > > > > 
> > > > > > > [1] http://intellinuxgraphics.org/how_to_report_bug.html
> > > > > > 
> > > > > > Will do.
> > > > > 
> > > > > A nice fellow on the irc channel suggested I keep an eye on the
> > > > > gem_objects file. It seems that when the computer is left alone,
> > > > > especially with the lid closed, the number of objects increases a
> > > > > bit:
> > > > > 
> > > > > 20212 objects
> > > > > 325713920 object bytes
> > > > > 6 pinned
> > > > > 8445952 pin bytes
> > > > > 137027584 gtt bytes
> > > > > 234881024 gtt total
> > > > > 
> > > > > Just last night, probably about 14 hours ago, X crashed (which is
> > > > > what prompted the first mail), and was started back up again. The
> > > > > number of objects then was around 19056.
> > > > 
> > > > I just came back to my laptop to find it hung. switching to a
> > > > terminal gave me a bunch of "gpu hung" messages, several a second.
> > > > It never managed to fix itself. Even restarting kdm didn't help.
> > > > 
> > > > Now that I have had to reboot, gem_objects reports 8190 objects.
> > > > Seems a bit more sane than 20k. I've updated libdrm, it seems its
> > > > version didn't match libdrm-intel1, that could have been causing
> > > > some problems. so I'll test this setup. if the same gem_object leak
> > > > happens I'll try with libdrm git as was suggested.
> > > 
> > > Been up half a day now since the crash,
> > > 
> > > 22352 objects
> > > 354799616 object bytes
> > > 6 pinned
> > > 8445952 pin bytes
> > > 114999296 gtt bytes
> > > 234881024 gtt total
> > > 
> > > I don't suppose that is normal?
> > > 
> > > I'll try the git libdrm today.
> > 
> > Other things came up, didn't get around to installing libdrm git yet.
> > 
> > But for kicks I've taken the logged gem_objects "objects" data and
> > piped it through gnuplot:
> > 
> > http://strangesoft.net/gem_objects_plot.png
> > 
> > The major dip is the gpu hung issue I had, with a subsequent reboot.
> > 
> > Interestingly enough, I just went to check the current count, between
> > the time I started writing the gnuplot spec and the script to convert
> > the log to tabular form, the objects count has increased a bunch:
> > 
> > http://strangesoft.net/gem_objects_plot2.png
> > 
> > From 35k, up to 37k. It seems to keep increasing.
> 
> Even with git libdrm it keeps going, it doesn't start off as bad, but it
> keeps increasing, even when the system isn't in use.
> 
> http://strangesoft.net/gem_objects_plot3.png
> 
> The part where it levels off (gets smoother) on the last section is after
> I went to bed.

Just talking with some other people with intel laptops who have similar 
issues, here's her xorg log:

http://pastebin.ca/1904990

Looks like it might be the same problem, the (WW) messages are very similar, 
mine just has some added info.

She also says a few more people happen to have the same crashes. And daily 
crashes, not weekly like mine.

-- 
Thomas Fjellstrom
tfjellstrom@shaw.ca