** Changed in: xserver-xorg-video-intel
Importance: Unknown = Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/91966
Title:
screen artifacts after resume, part row of pixels in error (945GM)
** Changed in: xserver-xorg-video-intel
Importance: Medium = Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/91966
Title:
screen artifacts after resume, part row of pixels in error (945GM)
Hey, I'm a debian user, and with xorg's xf86 video intel driver
(versions 2.2.1 and 2.3.1) and using grub2 and using grub2 to have a
splash image, I don't get any real text in my X sessions. Only text
from xterm and xemacs appear. Not windowmaker, gnome, kde, pidgin,
firefox, thunderbird, etc.
Have just installed Hardy Beta. I can confirm, the bug appears to be
fixed in Hardy.
At least, the vbetool post command doesn't produce the artifact, and
uncommenting POST_VIDEO=true (i.e. undoing the workaround) then
suspending doesn't produce the artifact either.
Checking the page tables with
Sometimes the bottom is black rather than garbled, but still
inaccessible.
I note that when I switch users or log off, the bottom row is used by
gdm. But when I log back in, sometimes the problem continues: the
bottom row of pixels is inaccessible, and is either black or shows
garbled screen
I'm having a similar problem on my Lenovo ThinkPad Z60m.
Bottom 30 pixels or so are gabled after resuming. If I log off or
restart X, the problem goes away.
Also, I can't move the mouse cursor onto that garbled area, and the area
does not show up in screenshots.
--
screen artifacts after
Trusting upstream that this is fixed, so closing the bug. If you can
reproduce it with Hardy, please reopen.
** Changed in: xserver-xorg-video-intel (Ubuntu)
Status: Fix Committed = Fix Released
--
screen artifacts after resume, part row of pixels in error (945GM)
Bryce Harrington wrote:
In the upstream bug report, they say it's fixed in the -intel 2.2
release. Can someone test Hardy alpha2 or newer and verify the issue is
fixed? If not, please give feedback on the upstream bug report.
I would test it.
But installing Hardy's X server seems to require
In the upstream bug report, they say it's fixed in the -intel 2.2
release. Can someone test Hardy alpha2 or newer and verify the issue is
fixed? If not, please give feedback on the upstream bug report.
** Also affects: xserver-xorg-video-intel via
** Changed in: xserver-xorg-video-intel
Status: Unknown = Fix Released
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for
** Changed in: xserver-xorg-video-intel (Ubuntu)
Importance: Undecided = High
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for
FWIW, the suggested fix (Edit /etc/default/acpi-support, comment out
POST_VIDEO=true) works for me as well. Thinkpad X60 with external
1680x1050 monitor, running Gutsy. Thanks so much!
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
Phi wrote:
This works for me as far as suspend/resume goes (yay!), but oddly I
still get the artefact if I let GRUB time out when booting. It makes me
wonder what's different between booting normally, and having a timer run
out, then booting. Perhaps it's a separate issue from this bug.
The fix from Jaime worked for me too!
A developer over at freedesktop.org suggested trying version 2.2 of the
xserver-xorg-video-intel driver. Supposedly there are some
suspend/resume fixes.
I would try myself but I can't seem to backport it properly to gutsy.
Heres the link to the bug report:
This works for me as far as suspend/resume goes (yay!), but oddly I
still get the artefact if I let GRUB time out when booting. It makes me
wonder what's different between booting normally, and having a timer run
out, then booting. Perhaps it's a separate issue from this bug.
--
screen artifacts
Wow Jamie, thanks for all that.
I don't understand 3/4 of it, but at least i got rid of that artifact :)
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which
This is great guys!!! Works like a charm for me. Glad this is fixed.
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
This is great guys!!! Works like a charm for me. Glad this is fixed.
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
Found it!
I'll put y'all out of your misery. The workaround is:
Edit /etc/defaults/acpi-support, to comment out POST_VIDEO=true.
This is hardly a general solution for Gutsy (then again, acpi-support
seems to be a seething mass of hacks upon hacks already, it would seem
to fit in
That fixed it for me! I'm sure I fussed with that option before, but I'm
sure glad you did too :)
On Nov 18, 2007 11:47 PM, Jamie Lokier [EMAIL PROTECTED] wrote:
Found it!
I'll put y'all out of your misery. The workaround is:
Edit /etc/defaults/acpi-support, to comment out
Aha! I finally found the right bug report. I have a Fujitsu Lifebook
s7110 with an Intel 945GM/GMS graphics chip that has the exact same
symptoms as described here. I get pixel swapping after resume (and also
when I first boot up, but only if GRUB times out...odd) to text mode
garbage blocks of
And here is the after.
If it helps, my screen resolution is 1440x1050 and I'm running up to
date Xubuntu 7.10.
** Attachment added: Output of intel_reg_dumper after suspend
http://launchpadlibrarian.net/10323275/intel_reg_dumper_after
--
screen artifacts after resume, part row of pixels in
I'll post the output of intel_reg_dumper without the swapped pixels
(before suspend), as well as after a suspend-resume with swapped pixels.
Here is the before.
** Attachment added: Output of intel_reg_dumper before suspend
http://launchpadlibrarian.net/10323270/intel_reg_dumper_before
--
[snip] what is the reason for the corrupt page tables?
Urm... pass on that one ;)
Jamie? Does the page table look the same before suspend? (Or when the
bug is not showing?)
Since the page-table can be acccessed via mapped memory in the video-
card's memory/IO/register space, it seems possible
Compiled binary produced with the above. (Needs to be run as root to
memory map the registers required).
** Attachment added: intel_reg_dumper
http://launchpadlibrarian.net/10214393/intel_reg_dumper
Unfortunately that does not run on Gutsy:
[EMAIL PROTECTED]:~$ sudo ./intel_reg_dumper
Peter Clifton wrote:
Jamie, do you consistently get the above error about non-contiguous GTT
entries? This code doesn't actually look to have changed since 2.1.1,
althoguh lots of other stuff dealing with memory allocation has.
No. Since the previous report, I have rebooted and used the same
Following an idea from some other comment, I decided to look at the
screen corruption more carefully.
I thought it was drawing the wrong thing sometimes, but not always,
because I could drag a window over the affected row and it would be
corrected.
But on looking closer, I see there are _two_
** Attachment added: Xorg.0.log which goes with the preceding comment
http://launchpadlibrarian.net/10270677/Xorg.0.log
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of
[EMAIL PROTECTED]:~$ sudo ./intel_reg_dumper
. /intel_reg_dumper: error while loading shared libraries: libpciaccess.so.0:
cannot open shared object file: No such file or directory
Fixed by (duh) installing the libpciaccess0 package.
The register and page table dump is attached, and it's quite
** Attachment added: Dump of registers and pagetable entries, to go with
preceding comment
http://launchpadlibrarian.net/10270846/intel_regs
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because
Peter Clifton wrote:
Jamie.. 32bit or 64bit?
32-bit CPU, Core Duo.
(EE) intel(0): Non-contiguous GTT entries: (6295552,0x163ffbe000) vs
(131072,0x 3f82)
^ Greater than 32 bits... (ok, a 32bit
Jamie, do you consistently get the above error about non-contiguous GTT
entries? This code doesn't actually look to have changed since 2.1.1,
althoguh lots of other stuff dealing with memory allocation has.
Some possibilities:
Subtle 64bit code bug with the 64bit data-types used, caused by
How do you get it 2048 pixels width?
Your xorg.conf has to be set up with a Virtual screen size at least as
big as the largest you want to resize it to. See my xorg.conf over on
bug 134464. (PS: careful with running OpenGL programs in that
configuration, last time I tried it it made the X server
Compiled binary produced with the above. (Needs to be run as root to
memory map the registers required).
** Attachment added: intel_reg_dumper
http://launchpadlibrarian.net/10214393/intel_reg_dumper
--
screen artifacts after resume, part row of pixels in error (945GM)
Can people experiencing this issue try running the register dumper
program I've hacked together from the intel_reg_dumper utility in the
intel driver source tree...
I'm attaching it here, as external access to where I usually host
packages for testing is down at the moment.
** Attachment added:
Sam, (Picking on you because your screen-res looks the same as mine, and
as such the debugging is more similar), can you post your Xorg.0.log
with the option
Option ModeDebug True
in the device section for the video card in the xorg.conf?
Thanks, Peter C.
--
screen artifacts after resume,
Sorry, actually, it's eeejay's screenshot which matches my resolution,
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
And Peter. here is the registry dump I made with your patch.
Cheers!
** Attachment added: reg_dump.txt
http://launchpadlibrarian.net/10218673/reg_dump.txt
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug
Here is my X log after a suspend/resume, with the debug option enabled.
** Attachment added: Xorg.0.log
http://launchpadlibrarian.net/10218671/Xorg.0.log
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug
Thanks... as hoped, it was very interesting...
At least one of the corruptions starts at the very end of stolen memory,
pagetable entry 1982.
pagetable entry 1981, value 0x87ffbd001
pagetable entry 1982, value 0x87ffbe001 Last physical page in the
stolen address range? (Also mapped to
Although the row of corrupt pixels is fixed for me by the above package,
3d acceleration is now broken. This message is present in Xorg.0.log,
and wasn't before: (EE) AIGLX error: drmMap of framebuffer failed
(Invalid argument)(EE) AIGLX: reverting to software rendering.
In fact, glxgears is
Bug #134464 is marked as a duplicate of this bug. They are related, but
I don't think the corrupt row of pixels has anything to do with
suspend/resume. I think that's a spurious coincidence.
I see the same screen corruption people have described (and shown in
pictures), but _without_
I suspect that the reason the corrupt row is disappearing is because DRI
is disabled when the server reverts to software rendering. This is
something we already knew: disabling DRI makes the screen artifact go
away.
--
screen artifacts after resume, part row of pixels in error (945GM)
You might find this bug report useful:
https://bugs.freedesktop.org/show_bug.cgi?id=12667
I notice that the git changeset which is said to cause the regression
(in that report), adds a check and message Non-contiguous GTT entries.
Interestingly, the package from Bryce (which fixes the screen but
disabling DRI makes the screen artifact go away.
I'm not so sure. I've seen this corruption on my multihead
configuration, and that never has DRI enabled, because the total width
is 2048 pixels so the Intel driver is forced to disable DRI on the 945
chipset...
--
screen artifacts after resume,
Is there any commonality amongst the people who see this bug as to
whether they are on 32bit or 64 bit systems?
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs,
Peter Maydell wrote:
disabling DRI makes the screen artifact go away.
I'm not so sure. I've seen this corruption on my multihead
configuration, and that never has DRI enabled, because the total width
is 2048 pixels so the Intel driver is forced to disable DRI on the 945
chipset...
I'm
32 bit here.
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Jamie.. 32bit or 64bit?
(EE) intel(0): Non-contiguous GTT entries: (6295552,0x163ffbe000) vs (131072,0x
3f82)
^ Greater than 32 bits... (ok, a 32bit processor can do this math,
but it is an
I didn't quite realise what the above commit tells us (forgot to check
when that commit was in the source, and whether it was included in
2.1.1: Answer.. it was)
commit f3168e3b0c5664a322ca6bb1c81fc94844cb30ab
Author: Eric Anholt [EMAIL PROTECTED]
Date: Wed May 2 14:08:30 2007 -0700
Actually, disabling DRI did help.
Sorry about that, I didn't realise I needed to put a 'Disable dri' in
my xorg.conf, instead I just commented out everything that said DRI in
it.
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You
Unlike Juha, disabling DRI, and then doing suspend/resume actually helps.
All of your suggestions Peter, and the package you pointed at don't help.
--
screen artifacts after resume, part row of pixels in error (945GM)
https://bugs.launchpad.net/bugs/91966
You received this bug notification
52 matches
Mail list logo
