[PLUG] xterm font losing pixels

[Dale Snell]

On Thu, 24 Sep 2015 12:27:38 -0700, in message
20150924192738.GA22781 at gate.kl-ic.com, Keith Lofstrom wrote:

> > Keith Lofstrom wrote:
> > >Sometimes one of the characters in my gnome-terminal instances
> > >(I typically run about 20) loses a few black pixels - on every
> > >instance of that character on every terminal instance.
> 
> On Wed, Sep 23, 2015 at 02:57:39PM -0700, Ken Stephens wrote:
> > Wonder if you can test the video memory.  memtest86 tests the
> > main memory.  Does it have a test for your video card memory? 
> 
> The Intel Express Integrated Graphics Controller (945GM?) uses
> main memory for graphics.  Remember, this is the font table that
> is getting messed up, and I presume it is either X or gnome-terminal
> that manages that table and renders the display windows for that.
> The 945GM does not have a font rendering engine.
> 
> When I switch virtual windows, X rerenders the window, presumably
> with the help and saved state of each application.  Since I don't
> see this behavior in Firefox or the other applications, and the
> disk copy of the font table remains intact (it is there when I
> restart X), I presume the corrupted table is in RAM and belongs
> to gnome-terminal or X.

Something you might try, just to narrow the list of suspects, is a
different terminal emulator.  Instead of Gnome-terminal or any of
its cousins, clones, inlaws, outlaws, etc., try something like
XTerm, or RXVT.  If the problem persists, at least you'll know
that it's not the terminal program.

Do any other programs exhibit this behavior?  Emacs is pretty
demanding; if anything was going to show this up, I'd think it
would.

> However, your suggestion does inspire a clue - since the busted
> pixels are always stored in a table in RAM, perhaps something is 
> interfering with the RAM refresh for that.  I will run memtest86+ 
> with the "bit fade" option  - that takes 3 hours, I'll run it tonight.
> 
> If there is another program I should run that keeps the memory bus
> too busy to run refreshes - is that possible? - I should try that.

I don't think so.  Even in the Good Old Days™, engineers were
smart enough not to interfere with DRAM refresh.  It's been a long
time since I studied DRAM architecture, but as I recall, modern
chips have the refresh circuitry built in.  So unless you
deliberately shut it off (and why would you?) it's always running.
To be honest, I'd be more likely to suspect the graphics chip
rather than the system RAM.  That's assuming (*cough*-*cough*)
that is is a hardware problem.

--Dale

-- 
Mundus vult decipi, ergo decipiatur
("The world wishes to be deceived, so let it be deceived.")
-- Attributed to the Roman satirist Petronius, first century AD.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.pdxlinux.org/pipermail/plug/attachments/20150924/6219a7d2/attachment.asc>