Also seeing this behavior since upgrading to 13.04.
- Lenovo Z570 (00:02.0 VGA compatible controller: Intel Corporation 2nd
Generation Core Processor Family Integrated Graphics Controller (rev 09))
- Ubuntu 13.04
- linux-image-3.8.0-30-generic (amd64)
- xserver-xorg-video-intel
You aren't the only one. It's happening to me as well, only since the
Ubuntu 13.04 upgrade:
- Lenovo T420
- Ubuntu 13.04
- 3.8.0-26 kernel x64
- xserver-xorg-video-intel 2:2.21.6-0ubuntu4
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Sorry to bother but it seems, for the lack of comments, that the bug has been
solved, but not in my case..
I'm experiencing it every day
- Raring updated to 5/2/13 on DELL LATITUDE E4200
- kernel 3.8.0-4 on x64
- xserver-xorg-video-intel 2:2.20.19-0
for the comment #156 it is supposed to be
I can confirm I have not experienced the bug with drm-intel-next after
several days of testing. What's the procedure next? Are the patches
going to be backported to 3.7.x?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Ah, thanks, great! Now I see that the two patches from Comment #144 and
Comment #145 are included in 3.7.3. So I guess the real fix you're
talking about it the one from Comment #143.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
(In reply to comment #148)
Ah, thanks, great! Now I see that the two patches from Comment #144 and
Comment #145 are included in 3.7.3. So I guess the real fix you're talking
about it the one from Comment #143.
Yep, that's right.
--
You received this bug notification because you are a member
(In reply to comment #146)
I can confirm I have not experienced the bug with drm-intel-next after
several days of testing. What's the procedure next? Are the patches going to
be backported to 3.7.x?
The band-aid is backported already afaik, the real fix should show up in
the next 3.7.x point
Created attachment 72697
Longshot 1: remove g4x/g5 specific MI_FLUSH
This bit is described as disabling the reload of indirect state pointers
from the context. Since we aren't using any of that, toggling this bit
shouldn't do anything. However, it is g4x/g5 specific...
--
You received this bug
Created attachment 72698
Longshot 2: make the shrinker less aggressive towards instruction bo
A variation on the shrinker, with the theory being that it is the kernel
/ instruction state that is being corrupted by the rebinding.
--
You received this bug notification because you are a member of
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) didn't
Created attachment 72770
i915 error state, 3.8.0-rc2, no patches
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR:
Everyone please retest with latest drm-intel-fixes from
http://cgit.freedesktop.org/~danvet/drm-intel
I've just merged a bunch of duct-tapes for this issue. For those who can
only reproduce the hangs with rc6 enabled, please also try reenabling
that with i915.i915_enable_rc6=1.
--
You received
Created attachment 72847
Hang me
So now the workaround is upstream, we need to find a way to retrigger
the bug...
This patch causes us to unbind everything after each batch - but it also
causes execution to be serialised. So the timing is going to be
completely different versus the IO related
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
*** Bug 56916 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
*** Bug 57122 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
*** Bug 57136 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
Created attachment 73082
Drop caches
I can reproduce this using the attached patch and UXA on ilk:
$ while sleep .5; do echo 15 /sys/kernel/debug/dri/0/i915_gem_drop_caches ;
done
$ DISPLAY=:0 CAIRO_TEST_TARGET=xlib ./cairo-perf-trace -i6
cairo-traces/benchmark/firefox-fishtank.trace
Dies
Created attachment 73105
Invalidate the presumed_offsets along the slow relocation path
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU
commit 262b6d363fcff16359c93bd58c297f961f6e6273
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Tue Jan 15 16:17:54 2013 +
drm/i915: Invalidate the relocation presumed_offsets along the slow
path
--
You received this bug notification because you are a member of Desktop
Packages,
*** Bug 59280 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
A patch referencing this bug report has been merged in Linux v3.8-rc4:
commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Jan 10 18:03:00 2013 +0100
drm/i915: Revert shrinker changes from Track unbound pages
--
You received this bug
A patch referencing this bug report has been merged in Linux v3.8-rc4:
commit 901593f2bf221659a605bdc1dcb11376ea934163
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Dec 19 16:51:06 2012 +
drm: Only evict the blocks required to create the requested hole
--
You received this
** Changed in: xserver-xorg-video-intel
Status: Incomplete = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup
this should be fixed at least with the current raring kernel, reopen if
not.
** Changed in: xserver-xorg-video-intel (Ubuntu)
Status: Incomplete = Fix Released
** Changed in: linux (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a
(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.
I can confirm this. Very stable now.
Thinkpad X220 (SNB), Linux 3.7.1 (w/ patch), intel 2.20.17 (SNA)
--
(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/
Ok.
xf86-video-intel commit 736b89504a32239a0c7dfb5961c1b8292dd744bd
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sun Dec 30 10:32:18 2012 +
uxa: Align surface allocations to even tile rows
Align surface sizes to an even number of tile rows to cater for sampler
prefetch.
** Bug watch added: freedesktop.org Bugzilla #56916
https://bugs.freedesktop.org/show_bug.cgi?id=56916
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
(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 it is
(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
I got the gpu hung error after 45 minutes on 3.7.1 with rc6=0 and the
evict blocks patch applied.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[/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);
...
--
(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 + i915.i915_enable_rc6=1 and it still
(In reply to comment #103)
Created attachment 71651 [details]
i915_error_state.txt.gz
An easily reproducible hung, though might be unrelated to the one we are
after here.
That's a spectacular broken mesa batch buffer. Its surface state base
doesn't point anywhere near a buffer.
--
You
Created attachment 72022
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/
--
You received this bug notification because you are a
(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 +
(In reply to comment #116)
the rc6 needs to be disabled *in*any*case*, that is known by now.
And it is a standalone patch of xf86-video-intel. Did you recompile it?
With rc6 disabled I cannot trigger the bug. Yes, I recompiled and restarted X.
[reply to comment 111]
I tried to apply
Created attachment 71926
Mark unused portions of the GTT as invalid
Working on the theory that this is an invalid access beyond the end of a
bo, this should hopefully enable GPU detection.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
I am unable to reproduce any hang with rc6 disabled. Chris, should I test it
with rc6 enabled?
Norbert, do you have a reliable test-case? My sw/hw details:
- Distro: Arch Linux x86_64 (with testing repos enabled)
- DDX: xf86-video-intel 2.20.16 on Xorg 1.13.1
- KDE 4.9.4 as desktop environment,
Created attachment 71933
Align surface sizes to an even tile row
And this is the complaint the GPU found. Please test this with your IO
heavy workloads.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
(In reply to comment #110)
Hi Daniel, hi Chris
(In reply to comment #107)
Created attachment 71805 [details] [review] [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
(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 Desktop
Packages, which is subscribed to
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
Created attachment 71805
make the shrinker less aggressive
Duct-tape solution if it is one, but imo very much worth a try.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
Created attachment 71651
i915_error_state.txt.gz
An easily reproducible hung, though might be unrelated to the one we are
after here.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
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
(In reply to comment #118)
[/usr/src/git-kernel/linux-2.6] grep -rn drm_mm_hole_node_end
Binary file drivers/gpu/drm/drm.ko matches
...
I saw that, but I have a symbol with a __ prefix.
Looking at the comments, there are two versions of that patch. comment
105 and comment 111 (v3). I guess you
(In reply to comment #124)
I am unable to reproduce any hang with rc6 disabled. Chris, should I test it
with rc6 enabled?
One bug at a time! ;-)
The rc6=0 bug seems much more nasty as it is affecting gen4/gen5 and
seems to imply a deep underlying synchronisation issue (so could
actually be all
Please try out the patch at
https://patchwork.kernel.org/patch/1885411/
It has a decent chance to reduce gtt trashing, which might be good
enough to again ducttape over the hangs. Or maybe change the pattern to
be able to reproduce it much quicker. In any case, should be interesting
...
--
You
(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
[reply to comment 107]
I haven't tried it yet, do you still want me to test it?
[reply to comment 108]
I cannot apply it on top of 3.7.1. What base do you want me to test it on?
[reply to comment 109]
Do I need to apply this to xf86-video-intel? If yes, which version/commit?
[reply to comment
(In reply to comment #92)
Another thing: I have now tried to hit the bug with SNA for a long time,
without *any* success. As soon as I switched back to IXA the bug was
triggered within short time.
Does this help you?
As a null data-point, yes. My interpretation is then back towards a
Created attachment 71437
Keep reserved objects pinned until after reloction processing.
An idea at last: earlier objects are moved in order to perform the
relocations. This should be impossible as we try to detect when we are
going to require GTT access for relocation processing and reserve it in
Created attachment 71439
Keep reserved objects pinned until after reloction processing.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU
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
Created attachment 71521
i915_error_state and Xorg log for 3.7.0+keep reserved pinned patch
Requested files
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
A patch referencing this bug report has been merged in Linux v3.7-rc8:
commit 6567d748c4e94e3481e523803ec07ebd825c80d6
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sat Nov 10 10:00:06 2012 +
Revert drm/i915: enable rc6 on ilk again
--
You received this bug notification because
(In reply to comment #100)
Created attachment 71521 [details]
i915_error_state and Xorg log for 3.7.0+keep reserved pinned patch
rc6 is disabled on Ironlake precisely because it is causing the lockup
you are encountering. We already know that we are missing workarounds
for enabling rc6 on
The Keep reserved objects pinned patch on 3.7.0 does not fix the hang
for me. The only thing I've seen so far that stops it is the last kernel
I compiled for my bisect to bad commit
6c085a728cf000ac1865d66f8c9b52935558b328. I believe a couple others have
also bisected to the same result.
--
You
(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 me
(In reply to comment #97)
(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
(In reply to comment #96)
The Keep reserved objects pinned patch on 3.7.0 does not fix the hang for
me. The only thing I've seen so far that stops it is the last kernel I
compiled for my bisect to bad commit
6c085a728cf000ac1865d66f8c9b52935558b328. I believe a couple others have
also
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
this bug is similar or the same as this..:
https://bugzilla.kernel.org/show_bug.cgi?id=49571
my bisect is pointing to the changes with device_cgroup.c
[66b8ef67756b3051bf42a077a82c3c5c279caa5b] device_cgroup: add deny_all in
dev_cgroup structure
I have two more revisions to test, but am sure
(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
screen got completely blue, but I could in
** Bug watch added: Linux Kernel Bug Tracker #49571
http://bugzilla.kernel.org/show_bug.cgi?id=49571
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
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
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 Desktop
Packages, which is subscribed
(In reply to comment #87)
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.
Dave didn't want to muddy the waters and make sure we make sure we
understand the root cause of the regression with UXA; I'm
Norbet, if you can reproduce it with SNA, due to the packing of the
batchbuffer I can have much better idea of what is going on. The
suspicion is definitely some dodgy state in the surface packet - but at
this moment in time, it could even be an alignment issue that's been
hidden by buffer layout.
For the record, I have run 3.7.0-4 with i915.i915_enable_rc6=0 for more
than 24 hours in sum without a single freeze. So I confirm Timo's theory
that this is the cause, and he said RC6 is going to be reverted for
Arrandale in the next kernel upload.
** Changed in: linux (Ubuntu)
Status:
Created attachment 70577
Don't force GTT/CPU relocations
Today's patch, please disable rc6 whilst testing.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
(In reply to comment #80)
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?
In isolation, so on top of 3.7-rc7 or drm-intel-fixes. The goal is to
both understand the issue and develop a minimal patch in time for 3.7.
No news... Has the instadeath gone, but the slow lingering death
remains?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup
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
i915.i915_enable_rc6=0 unables me to trigger the bug. With the patch
applied on top of 3.7-rc7, the bug is still not exposed (as expected).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
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 Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
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
(In reply to comment #69)
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
Created attachment 70428
Script to trigger the bug.
This seems to be quickest way to repro the bug on Ville's ILK
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
(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
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
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
Ok, after banging my head against this for several days, I have decreed
that the death within the render ring (inside the sequence of FLUSH
PIPE_CONTROLx8 FLUSH) is due to enabling of rc6 on ILK. That doesn't
explain all the crashes, but it does explain the immediate crashes on
danvet-ilk using
With http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=bug55984,
the situation does not change, i.e. still lockup message and vanishing
3D capailities.
(this bug is still marked NEEDINFO, do you need more details?)
--
You received this bug notification because you are a member of Desktop
The last bit of information we need is how to reproduce the non-rc6
related hangs - all the killscripts we've generated so far seem to hit
the rc6 issue, afaik.
(The highest priority is used for internal bug tracking.)
--
You received this bug notification because you are a member of Desktop
I've put a smaller selection of patches in
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=bug55984. It's
still a shotgun approach, but a good first step will be to see if it
cures the hang..
--
You received this bug notification because you are a member of Desktop
Packages, which is
** Bug watch added: freedesktop.org Bugzilla #55984
https://bugs.freedesktop.org/show_bug.cgi?id=55984
** Also affects: xserver-xorg-video-intel via
https://bugs.freedesktop.org/show_bug.cgi?id=55984
Importance: Unknown
Status: Unknown
--
You received this bug notification
Martin: I was told the linked upstream bug is the same one, and there is
a branch with some proposed fixes on it, but no confirmation so far.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: xserver-xorg-video-intel (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
** Tags removed: need-duplicate-check
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
[arrandale] GPU lockup IPEHR: 0x0222
Status in
Probably a kernel regression in drm. Not much has changed on the X side
since the quantal release.
Tried rebooting against the quantal kernel? Assuming that works, bisect
using http://kernel.ubuntu.com/~kernel-ppa/mainline/ would be the next
easiest. Or a full git bisection search if you'd
This change was made by a bot.
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1081009
Title:
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.7 kernel[0] (Not a kernel in the daily directory) and install both
the linux-image and linux-image-extra .deb packages.
If the bug also exists in
I confirm that it is definitively the kernel. I ran with the quantal 3.5
kernel for the remainder of yesterday and got no freeze. I now install
linux-
image-3.7.0-030700rc6-generic_3.7.0-030700rc6.201211162135_amd64.deb and
will follow up with the results.
--
You received this bug notification
I just got the freeze again with linux-
image-3.7.0-030700rc6-generic_3.7.0-030700rc6.201211162135_amd64.deb.
Does the GPU dump give any information as to which upstream commits
could be the culprit? I don't have a reliable way to reproduce this, I
always just need to work with the computer for a
Public bug reported:
These hangs started a few days ago in raring. There is no discernible
trigger, it happens out of the blue. When it happens, the X screen stays
uncorrupted, but totally freezes. The mouse cursor still works.
I can switch to VT1 and work there. Killing my processes and
99 matches
Mail list logo
