From: Thomas Fjellstrom <tfjellstrom@shaw.ca>
To: intel-gfx@lists.freedesktop.org
Subject: Re: 4500MHD driver crash
Date: Tue, 20 Jul 2010 21:05:07 -0600 [thread overview]
Message-ID: <201007202105.07474.tfjellstrom@shaw.ca> (raw)
In-Reply-To: <201007190802.11609.tfjellstrom@shaw.ca>
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
prev parent reply other threads:[~2010-07-21 3:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007202105.07474.tfjellstrom@shaw.ca \
--to=tfjellstrom@shaw.ca \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.