[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Random display freezes [was: Less responsive input...blind-typing]


* Osamu Aoki <osamu@debian.org> [120602 21:24]:
> Since you are on sid, I was wondering if this is some regression of
> mounting /tmp as tmpfs (not-exactly RAMDISK but practically the same.
> tmpfs may be swapped out to harddisk, though.)
> You said ...
> >>> This is up-to-date Sid on an X200s ThinkPad, running Screen in a
> >>> framebuffer console.
> Anyway, try disabling tmpfs first by editting /etc/default/rcS nd restart.
> You seem to be on low memory system.

My /etc/default/rcS file has only this:

#UTC=no # OBSOLETE; see /etc/adjtime and hwclock(8).

...don't see anywhere to explicitly disable tmpfs. The output of
`mount` seems to indicate that only /run is mounted tmpfs. Also, I'm
not on a particularly low memory system:

% free -h
             total       used       free     shared    buffers     cached
Mem:          2.9G       1.3G       1.6G         0B        21M       975M
-/+ buffers/cache:       303M       2.6G
Swap:           0B         0B         0B

I'm running a stripped-down setup using Screen in a framebuffer
console because that's what I've gotten used to over the years & I've
optimized it to my needs. Typically this uses ~300-500MB of ram max.

> Also check screen bug pages.  Thare are may bug reported.
>   http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=screen

Didn't see anything on that page that might relate to this issue. I
just now switched over to another framebuffer VT (not running Screen)
and experienced the same 3-second freezes happening fairly regularly.
I've also seen this behavior in an xterm.

The only way I can get this freezing to stop is to get off battery
power and plug into AC. Pretty sure this has to do with the hard-disk
spinning continually. Maybe changing out the HD for a fast SSD would
solve the problem while running on battery? Seems like there should
be another way...



John Magolske

Reply to: