* 4500MHD driver crash @ 2010-07-16 7:50 Thomas Fjellstrom 2010-07-16 8:04 ` Paul Menzel 0 siblings, 1 reply; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-16 7:50 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-16 7:50 4500MHD driver crash Thomas Fjellstrom @ 2010-07-16 8:04 ` Paul Menzel 2010-07-16 8:12 ` Thomas Fjellstrom 0 siblings, 1 reply; 11+ messages in thread From: Paul Menzel @ 2010-07-16 8:04 UTC (permalink / raw) To: intel-gfx [-- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-16 8:04 ` Paul Menzel @ 2010-07-16 8:12 ` Thomas Fjellstrom 2010-07-16 21:02 ` Thomas Fjellstrom 0 siblings, 1 reply; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-16 8:12 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-16 8:12 ` Thomas Fjellstrom @ 2010-07-16 21:02 ` Thomas Fjellstrom 2010-07-16 21:17 ` Niccolò Belli 2010-07-17 6:16 ` Thomas Fjellstrom 0 siblings, 2 replies; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-16 21:02 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-16 21:02 ` Thomas Fjellstrom @ 2010-07-16 21:17 ` Niccolò Belli 2010-07-17 6:16 ` Thomas Fjellstrom 1 sibling, 0 replies; 11+ messages in thread From: Niccolò Belli @ 2010-07-16 21:17 UTC (permalink / raw) To: intel-gfx Try librdm git, latest stable version is known to be bugged with intel-2.12. Darkbasic ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-16 21:02 ` Thomas Fjellstrom 2010-07-16 21:17 ` Niccolò Belli @ 2010-07-17 6:16 ` Thomas Fjellstrom 2010-07-17 20:01 ` Thomas Fjellstrom 1 sibling, 1 reply; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-17 6:16 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-17 6:16 ` Thomas Fjellstrom @ 2010-07-17 20:01 ` Thomas Fjellstrom 2010-07-18 17:46 ` Thomas Fjellstrom 0 siblings, 1 reply; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-17 20:01 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-17 20:01 ` Thomas Fjellstrom @ 2010-07-18 17:46 ` Thomas Fjellstrom 2010-07-19 14:02 ` Thomas Fjellstrom 0 siblings, 1 reply; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-18 17:46 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-18 17:46 ` Thomas Fjellstrom @ 2010-07-19 14:02 ` Thomas Fjellstrom 2010-07-21 1:42 ` Thomas Fjellstrom 2010-07-21 3:05 ` Thomas Fjellstrom 0 siblings, 2 replies; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-19 14:02 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-19 14:02 ` Thomas Fjellstrom @ 2010-07-21 1:42 ` Thomas Fjellstrom 2010-07-21 3:05 ` Thomas Fjellstrom 1 sibling, 0 replies; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-21 1:42 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4500MHD driver crash 2010-07-19 14:02 ` Thomas Fjellstrom 2010-07-21 1:42 ` Thomas Fjellstrom @ 2010-07-21 3:05 ` Thomas Fjellstrom 1 sibling, 0 replies; 11+ messages in thread From: Thomas Fjellstrom @ 2010-07-21 3:05 UTC (permalink / raw) To: intel-gfx 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-07-21 3:05 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-07-16 7:50 4500MHD driver crash Thomas Fjellstrom 2010-07-16 8:04 ` Paul Menzel 2010-07-16 8:12 ` Thomas Fjellstrom 2010-07-16 21:02 ` Thomas Fjellstrom 2010-07-16 21:17 ` Niccolò Belli 2010-07-17 6:16 ` Thomas Fjellstrom 2010-07-17 20:01 ` Thomas Fjellstrom 2010-07-18 17:46 ` Thomas Fjellstrom 2010-07-19 14:02 ` Thomas Fjellstrom 2010-07-21 1:42 ` Thomas Fjellstrom 2010-07-21 3:05 ` Thomas Fjellstrom
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.
