os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add questions for:

Browse source 
1.  Adding mre pty's
2.  Solutions to the 'calcru' problems under -current
    Submitted by:	Poul-Henning Kamp <phk@FreeBSD.ORG>
This commit is contained in:
Doug White 1998-12-05 00:24:11 +00:00
parent 723d065c2e
commit 9f73002a0c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=3871
2 changed files with 64 additions and 2 deletions

38
FAQ/admin.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: admin.sgml,v 1.11 1998-08-27 05:57:20 motoyuki Exp $ -->
<!-- $Id: admin.sgml,v 1.12 1998-12-05 00:24:11 dwhite Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -860,6 +860,42 @@ cd /cdrom/bin
./install.sh
</verb>
<sect1>
<heading>How do I add pseudoterminals to the system?</heading>
<p>If you have lots of telnet, ssh, X, or screen users, you'll probably run
out of pseudoterminals. Here's how to add more:
<enum>
<item>Build and install a new kernel with the line
<verb>
pseudo-device pty 256
</verb>
<p>in the configuration file.
<item>Run the command
<verb>
# cd /dev
# ./MAKEDEV pty{1,2,3,4,5,6,7}
</verb>
<p>to make 256 device nodes for the new terminals.
<item>Edit <tt>/etc/ttys</tt> and add lines for each of the 256
terminals. They should match the form of the existing entries, i.e. they look like
<verb>
ttyqc none network
</verb>
<p>The order of the letter designations is <tt>tty[pqrsPQRS][0-9a-v]</tt>,
using a regular expression.
<item>Reboot the system with the new kernel and you're ready to go.
</enum>
</sect>

28
FAQ/troubleshoot.sgml
View file

@ -1,4 +1,4 @@
<!-- $Id: troubleshoot.sgml,v 1.8 1998-11-23 04:40:33 jkh Exp $ -->
<!-- $Id: troubleshoot.sgml,v 1.9 1998-12-05 00:24:11 dwhite Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect>
@ -472,5 +472,31 @@
<item>Fire up X and login to the remote machine from an
<tt>xterm</tt>.
</itemize>
<sect1>
<heading>My machine prints "calcru: negative time..."</heading>
<p>This can be caused by various hardware and/or software ailments
relating to interrupts. It may be due to bugs but can also happen
by nature of certain devices. Running TCP/IP over the parallel
port using a large MTU is one good way to provoke this problem.
Graphics accelleratorscan also get you here, in which case you
should check the interrupt setting of the card first.
<p>A side effect of this problem are dying processes with the
message "SIGXCPU exceeded cpu time limit".
<p>For FreeBSD 3.0 and later from Nov 29, 1998 forward: If the
problem cannot be fixed otherwise the solution is to set
this sysctl variable:
<verb>
sysctl -w kern.timecounter.method=1
</verb>
<p> This means a performance impact, but considering the cause of
this problem, you probably will not notice. If the problem
persists, keep the sysctl set to one and set the "NTIMECOUNTER"
option in your kernel to increasingly large values. If by the
time you have reached "NTIMECOUNTER=20" the problem isn't
solved, interrupts are too hosed on your machine for reliable
timekeeping.
</sect>