lkml.org 
[lkml]   [1996]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Keyboard buffer stacking not queueing in 2.0.0?
Date
From
> 
> On Mon, 12 Aug 1996, Peter T. Breuer wrote:
>
> > easily. Running under X in particular, if some disk activity starts up
> > while I am typing then my typing seems to be buffered as the disk is
> > serviced. When disk activity levels off a couple of seconds later the
> > characters appear on screen.
> >
> > Well, I am tired of correcting my typing. I have concluded it isn't me
> > making the errors. The simplest explanation is that the characters are
> My answer could seem to be stupid, but,... do you have a swap partition ?
>
> Ciao. Pierluigi. -- pderosa@mbox.vol.it - PGP key available

:-)
Yes - don't worry. Or is that what you are worried about! I'll post the
memory statistics of my 486sx below. It really is a lightweight
machine (running 2.0.0). If you have any insight please share it!

% free
total used free shared buffers
Mem: 7160 6924 236 4700 724
-/+ buffers: 6200 960
Swap: 4056 1020 3036
MemTotal: 6
MemFree: 0
MemShared: 4
Buffers: 0
Cached: 3
SwapTotal: 3
SwapFree: 2

% ps auxm
PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND
2 ? 0 0 0 0 0 0 0 0 0 0 (kflushd)
3 ? 427 0 0 0 0 0 0 0 0 0 (kswapd)
128 6 75 25 0 76 164 88 76 76 0 0 (agetty)
127 2 74 25 0 80 168 88 80 80 0 0 (agetty)
137 1 74 25 0 108 196 88 108 108 0 0 (agetty)
23 ? 15 45 16 112 196 68 128 112 0 3 /sbin/kern
181 ? 1 3 8 132 208 68 140 128 0 3 update
1 ? 171 46 24 164 228 40 188 140 0 11 init
891 p0 87 44 32 368 400 0 400 288 0 28 ps auxm
154 ? 334 287 56 604 764 104 660 336 0 79 rxvt -T Co
158 p0 201 1928 240 496 792 56 736 448 0 71 -tcsh
820 p0 272 60 96 760 856 0 856 672 0 46 fvwm
138 ? 534 184 716 496 1436 224 1212 832 0 89 X :0


I have been trying to get the machine into the same state again for
about a week without success. That's why I haven't posted any more
results. I think perhaps the keyboard has to be sticky as well as the
machine being heavily loaded .. and I have unstuck it somewhat by typing.

I have also had a hard time loading the machine the same way. I think
running gettys+uugetty before was part of the problem, and now I am
back to agettys. As soon as I get back to a reproducible keyboard-reversing
state I will post more details.

I have noticed something strange though - with the configuration listed
above I can't run latex. It dies at its second attempted brk(). I have
to kill fvwm, run latex and restart fvwm while it is going. Latex just
seems to need some extra room to do the brk else it segfaults. Is that
right? Does stack space really have to come from physical memory?

Here's the portion of the strace that is relevant (kernel 2.0.0 8M ram
and 4M swap, minimal configuration, modularized 2.0).

execve("/usr/bin/latex", ["latex", "zgram"], [/* 34 vars */]) = 0
...
close(3) = 0
geteuid() = 501
getuid() = 501
brk(0x8576f18) = 0x8576f18
brk(0x8577000) = 0x8577000
^^-- **** that's where it would die usually **** --^^
open("/home/ptb/.zlibrc", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4709, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000
...

What I would be very grateful for is someone telling me why latex
segfaults at the marked point unless I kill something like fvwm, then
runs even though I start up fvwm again immediately it has passed the
critical point.

There seems to be a memory leak/lock somewhere in X/fvwm because
eventually after a few cycles of this I can't start latex anyway and I
have to exit X. Sometimes even that doesn't free up whatever is holding
on to resources. As you can see I don't have any processes running that
might be doing damage. By this time I have usually killed my pcmcia
card-services daemon and anything else I can lay my hands on too! No
help. I have also commented out all the fonts and icons I can find in
my files. I can't see anything suspicious via /proc either. What should
I be looking for to find out what is going on?

I don't know what the brk() call represents. Is that an increment or
the new boundary? The latter, I suppose. Where did they get that number
from anyway! (I don't think anyone could understand the manpage for
brk() if they didn't already know what it meant!)

Regards (time to get back to editing ...)


Peter T. Breuer
,---------------------------------------------------------------------------
|Departamento de Ingenieria de Sistemas Telematicos, Universidad Politecnica
|de Madrid, Escuela Tecnica Superior de Ingenieros de Telecomunicacion,
|Ciudad Universitaria, E--28040 Madrid, SPAIN.
|Tel. Office : +34 (1)336 6831
| Fax : +34 (1)543 2077 or 336 7333
|Internet : <ptb@eng.cam.ac.uk, ptb@comlab.ox.ac.uk, ptb@dit.upm.es>
| URL : http://www.dit.upm.es:80/~ptb/
`---------------------------------------------------------------------------

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.039 / U:1.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site