> 3.7.0 plus patch from #122 with patched intel driver is rock solid
> 3.8.0-rc2 with patched intel driver (but no kernel patch) hangs (uploading
> the error state file soon)
>
> I will try 3.8.0-rc3 with #122 patch plus the two from Chris 130/131 now.
3.8.0-rc3 with patches from #122, #130, #131
Created attachment 72770
i915 error state, 3.8.0-rc2, no patches
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
To m
Hi everyone,
(In reply to comment #129)
> (In reply to comment #126)
> > Ok. seems to work very stable now. I am running now a few days with the
> > patches xf86-intel driver and this patch (#122), and didn't have any hiccups
> > at all.
>
> Ok, I got one. It took a *long* time, and I (stupidly)
(In reply to comment #126)
> Ok. seems to work very stable now. I am running now a few days with the
> patches xf86-intel driver and this patch (#122), and didn't have any hiccups
> at all.
Ok, I got one. It took a *long* time, and I (stupidly) didn't grab the
error state (too tired after 24 hours
(In reply to comment #122)
> Created attachment 72022 [details] [review]
> Only evict the blocks required to free the hole
>
> (In reply to comment #121)
> > Indeed, patchwork 1896161 from comment 111 does not compile.
>
> It's just based on a slightly more recent tree. Meta-patch: s/__drm/drm/
(In reply to comment #120)
> > Looking at the comments, there are two versions of that patch. comment 105
> > and comment 111 (v3). I guess you applied the earlier one? Chris, can you
>
> Indeed ... indeed ... I don't know why, but checking not the git log I
> wrote, but the actual diff I see that
Hi,
I will try the patch from 109 in combination with the patchwork patch
next. I think I *did* try the patchwork test recently.
So I will go silent now and report back in a few days if no problems
arose, or immediately if it freezes again.
Thanks
Norbert
--
You received this bug notification
(In reply to comment #113)
> [reply to comment 109]
> Do I need to apply this to xf86-video-intel? If yes, which version/commit?
Yes, it is xf86-video-intel. I am running it with the current version of
Debian/sid + this patch now (2.20.14-1 + the patch)
> [reply to comment 111]
> I tried to apply
(In reply to comment #119)
> I saw that, but I have a symbol with a __ prefix.
Aren't these created by the compiler ???
> Looking at the comments, there are two versions of that patch. comment 105
> and comment 111 (v3). I guess you applied the earlier one? Chris, can you
Indeed ... indeed ... I
(In reply to comment #115)
> (In reply to comment #114)
> > Yes, it is xf86-video-intel. I am running it with the current version of
> > Debian/sid + this patch now (2.20.14-1 + the patch)
> Is it a standalone patch or does it depend on the former DRM patch? Anyway,
> I have tested it with 3.7.1 +
[/usr/src/git-kernel/linux-2.6] grep -rn drm_mm_hole_node_end
Binary file drivers/gpu/drm/drm.ko matches
...
drivers/gpu/drm/drm_mm.c:126: unsigned long hole_end =
drm_mm_hole_node_end(hole_node);
drivers/gpu/drm/drm_mm.c:210: unsigned long hole_end =
drm_mm_hole_node_end(hole_node);
...
--
Hi Daniel, hi Chris
(In reply to comment #107)
> Created attachment 71805 [details] [review]
> make the shrinker less aggressive
>
> Duct-tape solution if it is one, but imo very much worth a try.
There have been a lot of patches floating around, but I was running
3.7.0 plus this patch now for a
(In reply to comment #122)
> It's just based on a slightly more recent tree. Meta-patch: s/__drm/drm/
Thanks, rebooting now with new kernel (and still patched intel xf86
driver)
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-
(In reply to comment #93)
> Norbert, a quick scan of the bug report doesn't yield any information as to
> whether you tested the mb() theory. Can you please try:
>
> http://cgit.freedesktop.org/~ickle/linux-2.6 #master
Comment 74 and 75 seem to indicate that I tried at least a subset.
Do you want
Hi Chris,
(In reply to comment #90)
> (In reply to comment #89)
> > First report on SNA: I got a very very strange thing yesterday. After
> > resuming from suspend-to-ram I continued working with GIMP on some graphics,
> > and first it started with some blue flashes on the screen, and finally the
First report on SNA: I got a very very strange thing yesterday. After
resuming from suspend-to-ram I continued working with GIMP on some
graphics, and first it started with some blue flashes on the screen, and
finally the screen got completely blue, but I could in principle still
interact with the
Hi Chris,
ok, will switch to SNA, although in one of the email threads predating
this bug report I switched to SNA and then was told not to.
Anyway, trying to recreate it with SNA.
Norbert
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserve
Created attachment 70855
i915 error state, rc6=0, patch from comment 79
Hi Chris,
sorry to say it, but I got a hang today. In the background some
update.mlocate etc was running, plus some git checkout of a big
repository.
i915 error state uploaded.
Norbert
--
You received this bug notificatio
Hi Chris,
> No news... Has the instadeath gone, but the slow lingering death
remains?
Well, I am running the latest patch on top of git and try to trigger the
bug, till now without success, though.
I cannot say more or less, at least the frequency has reduced.
Let me know if I can help more tha
Chris, please let us know on top of what? On top of the bug55984 git
branch you created earlier, or is that one not necessary?
Thanks
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/
(In reply to comment #72)
> Script to trigger the bug.
>
> This seems to be quickest way to repro the bug on Ville's ILK
I couldn't trigger anything with that, it just happily continued for
ages. Here it seems that big IO for read and write to be necessary,
while here is only read.
--
You recei
Okay, I guess I have to recall my statement, I didn't realize it at
first. Due to the i915.enable_hangcheck=0 it seemss that not simply the
3d died and Gnome3 WM died, but with this the screen went black and
didn't react on anything. Interestingly there were no messages at all in
the log files.
I
Running current linux HEAD with
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=bug55984 pulled
in I cannot trigger the crash, how hard I have tried now for some time.
Compared with the for-imre branch also the strange artifacts are gone,
so it looks much better now.
I have still the follo
Hi Chris,
I am now running with
http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=for-imre pulled into
main linux git.
The first thing I realized that there are some very strange effects
happening: I have docky (a panel) running, and set to auto-hide. If it
is shown, then there are boxes around
24 matches
Mail list logo
