Could anyone who actually got (not tex, but) latex running using
kertex on Plan 9 show the full details? What I have found on the web
so far has not been enough for this novice.
Plain tex works wonderfully. Thanks, Thierry Laronde!
Mark.
Hello Mark,
On Mon, Mar 05, 2012 at 09:45:04AM +, Mark van Atten wrote:
Could anyone who actually got (not tex, but) latex running using
kertex on Plan 9 show the full details? What I have found on the web
so far has not been enough for this novice.
I'm not a LaTeX user, but I'd like to
Hello,
I have added the pkg for AMS-TeX (the plain TeX, e-TeX flavor) and
the pkg for the required Cyrillic for LaTeX to kerTeX.
These can be retrieved from:
http://downloads.kergis.com/
or through the web page:
http://www.kergis.com/kertex.html(français)
My previous message appeared on the list with a delay; in the
meantime, in an off-list exchange, Thierry kindly worked on it
immediately and resolved all the problems. The version that now
appears on the Kertex web page works for me. I use 9vx on FreeBSD 8.2.
I also compiled Kertex successfully
cpu% kprof /n/9fat/9cpcpuf /dev/kpdata
total: 24620 in kernel text: 23890 outside kernel text:730
RTZERO f010 PGSIZE 4Kb
ms % sym
21840 91.3 _strayintr
290 1.2 memmove
290 1.2 iunlock
180 0.7 sched
160 0.6 memset
150 0.6 sleep
if you
it turns out that _strayintr is taking up nearly all the time.
Or maybe it isn't. Taking up nearly all the cpu time isn't the
same as taking up nearly all the time. You can use time(1) while
reading usb disk to see if cpu is really the bottleneck, or if
in fact your machine is spending most of
if you could temporarly run a 9atom kernel,
With the normal kernel, you can use acid or db to look at the intrtimes
array to see the spread of cpu times used in each interrupt vector entry.
See http://9fans.net/archive/2003/11/520
On Mon Mar 5 11:06:43 EST 2012, 9f...@hamnavoe.com wrote:
if you could temporarly run a 9atom kernel,
With the normal kernel, you can use acid or db to look at the intrtimes
array to see the spread of cpu times used in each interrupt vector entry.
See http://9fans.net/archive/2003/11/520
a hisogram sure could be useful, but i think i'd want to taylor it to
a specific problem. and i haven't had one yet.
The problem in hand is to check the hypothesis that usb disk slowness
is due to nearly all the time being spent in interrupt handling.
A quick glance at intrtimes should suffice
You can use time(1) while reading usb disk to see if cpu is really the
bottleneck, or if in fact your machine is spending most of its time
waiting for a usb interrupt. If the machine is mostly idle, profiling
clock ticks should usually find it sitting at the HLT instruction which
happens to
10 matches
Mail list logo
