[Intel-gfx] 4500MHD driver crash

Thomas Fjellstrom tfjellstrom at shaw.ca
Wed Jul 21 03:42:44 CEST 2010 

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 at shaw.ca

More information about the Intel-gfx mailing list