We're closing this bug since there has not been a response from the original
reporter. However, the issue still exists please feel free to reopen with the
requested information. If you're not the original reporter, we'd prefer you
file a new bug report.
Some tips:
* Report X.org bugs via
A month has gone by without reproduction, so let's give it another
couple then retire the bug. The heart of the issue I believe is a race
with GPU reset, of which there are more patches that have gone into
v3.9.
** Changed in: xserver-xorg-video-intel (Ubuntu)
Status: Triaged = Incomplete
Steve, could you either watch 'sudo perf top' or grab a few stacktraces
of Xorg to see where the cycles are going?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1117563
Title:
X hard lockup in
On Tue, Feb 19, 2013 at 05:14:17PM -, Chris Wilson wrote:
Steve, could you either watch 'sudo perf top' or grab a few stacktraces
of Xorg to see where the cycles are going?
If and when I reproduce the problem again, sure.
--
You received this bug notification because you are a member of
I believe I've reproduced this bug here. Steps to reproduce:
- load something javascripty that angers firefox and makes it very, very laggy
- watch compiz notice this lagginess and helpfully animate the window as
non-responsive (shading), making everything even more laggy
- switch workspaces
What style of lag is this? Since you mention that compiz rendering makes
it worse, I imagine it to be render latency. Can you paste an example
URL?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
On Wed, Feb 13, 2013 at 05:51:34PM -, Chris Wilson wrote:
What style of lag is this?
The style where firefox is running some javascript of indeterminate origin
instead of responding to input.
Since you mention that compiz rendering makes it worse, I imagine it to be
render latency.
There is udev code to detect gpu lockups which will capture
i915_error_state in that case, but the general apport-collect script
doesn't (we haven't needed it up til now, but probably can't hurt to
collect). Since it sounds like that didn't happen here, it suggests
you're experiencing something
On Fri, Feb 08, 2013 at 09:20:11PM -, Bryce Harrington wrote:
There is udev code to detect gpu lockups which will capture
i915_error_state in that case, but the general apport-collect script
doesn't (we haven't needed it up til now, but probably can't hurt to
collect). Since it sounds
** Changed in: xserver-xorg-video-intel (Ubuntu)
Status: Incomplete = Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1117563
Title:
X hard lockup in raring, can't even switch VTs
To
Looks like you got apport to pick up the gpu lockup after all: bug
#1119793
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1117563
Title:
X hard lockup in raring, can't even switch VTs
To manage
Sounds like a page-fault-of-doom scenario. Is it possible to reproduce?
And if you can, can you grab a few stacktraces of Xorg and firefox, and
also the kernel stacks from /proc/`pidof Xorg`/stack. You will need to
use a ssh login.
--
You received this bug notification because you are a member
** Tags added: freeze
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1117563
Title:
X hard lockup in raring, can't even switch VTs
To manage notifications about this bug go to:
On Thu, Feb 07, 2013 at 12:38:47PM -, Chris Wilson wrote:
Sounds like a page-fault-of-doom scenario. Is it possible to reproduce?
I am loathe to reproduce it. But if it happens again, I will certainly
follow up.
And if you can, can you grab a few stacktraces of Xorg and firefox,
Yes, if
For GPU lockup bugs with Intel graphics, you need to collect the output
of 'dmesg' and your /sys/kernel/debug/dri/0/i915_error_state file. Both
of these must be collected while the machine is locked up (e.g. by
sshing into the sick machine over ethernet). See
Hi Bryce,
For GPU lockup bugs with Intel graphics, you need to collect the output
of 'dmesg' and your /sys/kernel/debug/dri/0/i915_error_state file.
The dmesg output is included in the other kernel bug report I mentioned
(bug #1117499). There was nothing relevant shown.
I didn't know to
16 matches
Mail list logo
