[Intel-gfx] 4500MHD driver crash

Mon Jul 19 16:02:11 CEST 2010

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