** 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. D
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 w
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 arti
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 resume
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)
https://bugs.launchpad.
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 requi
** 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 Ubunt
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
https://bugs.freedesktop.org/show_bug.cgi?id=
** 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 Ub
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
Y
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:
h
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.
Am
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
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.
--
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 is
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 "POST_VI
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 somewhere.
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
--
s
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
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 co
[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 th
** 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 becaus
> [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 quit
** 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
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_ cor
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 sam
> 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_du
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
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 noti
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 notifi
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.
--
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,
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)
https://bugs.launchpad
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:
>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 serve
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 incompa
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 32
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
Disab
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 interest
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...
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
http
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, w
>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
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 bu
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)
https://bug
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 mu
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_ suspend/res
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 rec
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 becaus
52 matches
Mail list logo
