docs/7082 Fix grammar errors (Dag-Erling Coidan <dag-erli@ifi.uio.no>) admin.sgml: Add section on amd applications.sgml: Add section on installing FrontPage hardware.sgml: Add sections on CAM, P&P modems, serial consoles install.sgml: Add section on why not to remove sc0 preface.sgml: Sync versions-graph with our current temporal co-ordinates x.sgml: Add sections on missing Imake.tmpl, reversing mouse buttons docs/7083 (FAQ maintainer, dwhite) admin.sgml: Something about mounting root. With -a. Dooh! docs/7084 (FAQ maintainer, dwhite)
		
			
				
	
	
		
			427 lines
		
	
	
	
		
			18 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			427 lines
		
	
	
	
		
			18 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
<!-- $Id: troubleshoot.sgml,v 1.5 1998-06-27 01:13:49 hoek Exp $ -->
 | 
						|
<!-- The FreeBSD Documentation Project -->
 | 
						|
 | 
						|
  <sect>
 | 
						|
    <heading>Troubleshooting<label id="troubleshoot"></heading>
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>I have bad blocks on my hard drive!<label id="awre"></heading>
 | 
						|
 | 
						|
      <p>With SCSI drives, the drive should be capable of re-mapping
 | 
						|
      these automatically.  However, many drives are shipped with
 | 
						|
      this feature disabled, for some mysterious reason...
 | 
						|
 | 
						|
      <p>To enable this, you'll need to edit the first device page mode,
 | 
						|
      which can be done on FreeBSD by giving the command (as root)
 | 
						|
 | 
						|
      <verb>
 | 
						|
        scsi -f /dev/rsd0c -m 1 -e -P 3
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>and changing the values of AWRE and ARRE from 0 to 1:-
 | 
						|
 | 
						|
      <verb>
 | 
						|
        AWRE (Auto Write Reallocation Enbld):  1
 | 
						|
        ARRE (Auto Read Reallocation Enbld):  1
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>For other drive types, you are dependent on support from the
 | 
						|
      operating system.  Unfortunately, the ``bad144'' command that
 | 
						|
      FreeBSD supplies for this purpose needs a considerable amount
 | 
						|
      of work done on it. In other words, it doesn't work. If you're
 | 
						|
      lucky, you can create a file that contains the bad blocks and
 | 
						|
      stuff it away with a name like ".BADBLOCKS". This is how I got
 | 
						|
      386BSD Patchkit 24 completed. <tt/NOTE/: don't do this unless
 | 
						|
      your time is effectively free.
 | 
						|
 | 
						|
      <p>IDE drives are <em/supposed/ to come with built-in bad-block
 | 
						|
      remapping; if you have documentation for your drive, you may want
 | 
						|
      to see if this feature has been disabled on your drive.  However,
 | 
						|
      ESDI, RLL, and ST-506 drives normally do not do this.
 | 
						|
 | 
						|
      <p>If remapping is enabled and you are seeing bad blocks, consider
 | 
						|
      replacing the drive.  The bad blocks will only get worse as time
 | 
						|
      goes on.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>FreeBSD does not recognize my Bustek 742a EISA SCSI!</heading>
 | 
						|
 | 
						|
      <p>This info is specific to the 742a but may also cover other
 | 
						|
      Buslogic cards.  (Bustek = Buslogic)
 | 
						|
 | 
						|
      <p>There are 2 general ``versions'' of the 742a card.  They are
 | 
						|
      hardware revisions A-G, and revisions H - onwards.  The revision
 | 
						|
      letter is located after the Assembly number on the edge of the
 | 
						|
      card.  The 742a has 2 ROM chips on it, one is the BIOS chip and
 | 
						|
      the other is the Firmware chip.  FreeBSD doesn't care what
 | 
						|
      version of BIOS chip you have but it does care about what version
 | 
						|
      of firmware chip.  Buslogic will send upgrade ROMS out if you
 | 
						|
      call their tech support dept.  The BIOS and Firmware chips are
 | 
						|
      shipped as a matched pair.  You must have the most current
 | 
						|
      Firmware ROM in your adapter card for your hardware revision.
 | 
						|
 | 
						|
      <p>The REV A-G cards can only accept BIOS/Firmware sets up to
 | 
						|
      2.41/2.21.  The REV H- up cards can accept the most current
 | 
						|
      BIOS/Firmware sets of 4.70/3.37. The difference between the
 | 
						|
      firmware sets is that the 3.37 firmware supports ``round robin''
 | 
						|
 | 
						|
      <p>The Buslogic cards also have a serial number on them.  If you
 | 
						|
      have a old hardware revision card you can call the Buslogic RMA
 | 
						|
      department and give them the serial number and attempt to
 | 
						|
      exchange the card for a newer hardware revision.  If the card is
 | 
						|
      young enough they will do so.
 | 
						|
 | 
						|
      <p>FreeBSD 2.1 only supports Firmware revisions 2.21 onward.  If you
 | 
						|
      have a Firmware revision older than this your card will not be
 | 
						|
      recognized as a Buslogic card.  It may be recognized as an
 | 
						|
      Adaptec 1540, however.  The early Buslogic firmware contains an
 | 
						|
      AHA1540 ``emulation'' mode.  This is not a good thing for an EISA
 | 
						|
      card, however.
 | 
						|
 | 
						|
      <p>If you have an old hardware revision card and you obtain the 2.21
 | 
						|
      firmware for it, you will need to check the position of jumper W1
 | 
						|
      to B-C, the default is A-B.
 | 
						|
 | 
						|
      <p>The 742a EISA cards never had the ``>16MB'' problem mentioned in
 | 
						|
      the section <ref id="bigram" name="on >16 MB machines">. This is a
 | 
						|
      problem that occurs with the Vesa-Local Buslogic SCSI cards.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>
 | 
						|
        My HP Netserver's SCSI controller is not detected!
 | 
						|
      </heading>
 | 
						|
 | 
						|
      <p>This is basically a known problem.  The EISA on-board SCSI controller
 | 
						|
      in the HP Netserver machines occupies EISA slot number 11, so all
 | 
						|
      the ``true'' EISA slots are in front of it.  Alas, the address space
 | 
						|
      for EISA slots >= 10 collides with the address space assigned to PCI,
 | 
						|
      and FreeBSD's auto-configuration currently cannot handle this
 | 
						|
      situation very well.
 | 
						|
 | 
						|
      <p>So now, the best you can do is to pretend there is no address
 | 
						|
      range clash :), by bumping the kernel option <tt/EISA_SLOTS/
 | 
						|
      to a value of 12.
 | 
						|
      Configure and compile a kernel, as described in the
 | 
						|
      <url url="../handbook/kernelconfig.html"
 | 
						|
      name="Handbook entry on configuring the kernel">.
 | 
						|
 | 
						|
      <p>Of course, this does present you with a chicken-and-egg problem when
 | 
						|
      installing on such a machine.  In order to work around this
 | 
						|
      problem, a special hack is available inside <em>UserConfig</em>.
 | 
						|
      Do not use the ``visual'' interface, but the plain command-line
 | 
						|
      interface there.  Simply type
 | 
						|
 | 
						|
      <verb>
 | 
						|
        eisa 12
 | 
						|
        quit
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>at the prompt, and install your system as usual.  While it's
 | 
						|
      recommended you compile and install a custom kernel anyway,
 | 
						|
          
 | 
						|
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?dset" name="dset">
 | 
						|
      now also understands to save this value.
 | 
						|
 | 
						|
      <p>Hopefully, future versions will have a proper fix for this problem.
 | 
						|
 | 
						|
      <p><tt/NOTE:/ You can not use a <bf/dangerously dedicated/ disk with
 | 
						|
      an HP Netserver. See <ref id="dedicate" name="this note"> for
 | 
						|
      more info.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>What's up with this CMD640 IDE controller?</heading>
 | 
						|
 | 
						|
      <p>It's broken.  It cannot handle commands on both channels
 | 
						|
      simultaneously.
 | 
						|
 | 
						|
      <p>There's a workaround available now and it is enabled automatically
 | 
						|
      if your system uses this chip. For the details refer to the
 | 
						|
      manual page of the disk driver (man 4 wd).
 | 
						|
 | 
						|
      <p>If you're already running FreeBSD 2.2.1 or 2.2.2 with a
 | 
						|
      CMD640 IDE controller and you want to use the second channel,
 | 
						|
      build a new kernel with <tt/options "CMD640"/ enabled. This
 | 
						|
      is the default for 2.2.5 and later.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>I keep seeing messages like ``<tt/ed1: timeout/''.</heading>
 | 
						|
 | 
						|
      <p>This is usually caused by an interrupt conflict (e.g., two boards
 | 
						|
      using the same IRQ).  FreeBSD prior to 2.0.5R used to be tolerant
 | 
						|
      of this, and  the  network driver  would  still function  in  the
 | 
						|
      presence  of IRQ conflicts.  However, with  2.0.5R and later, IRQ
 | 
						|
      conflicts are no  longer tolerated.  Boot with the -c option and
 | 
						|
      change the ed0/de0/... entry to match your board.
 | 
						|
 | 
						|
      <p>If you're using the BNC connector on your network card, you may
 | 
						|
      also see device timeouts because of bad termination.  To check this,
 | 
						|
      attach a terminator directly to the NIC (with no cabel) and see if
 | 
						|
      the error messages go away.  
 | 
						|
 | 
						|
      <p>Some NE2000 compatible cards will give this error if there is 
 | 
						|
      no link on the UTP port or if the cable is disconnected.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>When I mount a CDROM, I get ``Incorrect super block''.</heading>
 | 
						|
 | 
						|
      <p>You have to tell 
 | 
						|
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?mount" name="mount">
 | 
						|
      the type of the device that you want to mount.  By default, 
 | 
						|
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?mount" name="mount">
 | 
						|
      will assume the filesystem is of type ``<tt/ufs/''.  You want to mount
 | 
						|
      a CDROM filesystem, and you do this by specifying the ``<tt/-t cd9660/''
 | 
						|
      option to <htmlurl url="http://www.freebsd.org/cgi/man.cgi?mount"
 | 
						|
      name="mount">.  This does, of course, assume that the
 | 
						|
      CDROM contains an ISO 9660 filesystem, which is what most CDROMs
 | 
						|
      have.  As of 1.1R, FreeBSD automatically understands the Rock Ridge
 | 
						|
      (long filename) extensions as well.
 | 
						|
 | 
						|
      <p>As an example, if you want to mount the CDROM device,
 | 
						|
      ``<tt>/dev/cd0c</tt>'', under <tt>/mnt</tt>, you would execute:
 | 
						|
 | 
						|
      <verb>
 | 
						|
        mount -t cd9660 /dev/cd0c /mnt
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>Note that your device name (``<tt>/dev/cd0c</tt>'' in this
 | 
						|
      example) could be different, depending on the CDROM interface.
 | 
						|
      Note that the ``<tt/-t cd9660/'' option just causes the
 | 
						|
      ``<tt/mount_cd9660/'' command to be executed, and so the
 | 
						|
      above example could be shortened to:
 | 
						|
 | 
						|
      <verb>
 | 
						|
        mount_cd9660 /dev/cd0c /mnt
 | 
						|
      </verb>
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>When I mount a CDROM, I get ``Device not configured''.</heading>
 | 
						|
 | 
						|
      <p>This generally means that there is no CDROM in the CDROM drive,
 | 
						|
      or the drive is not visible on the bus. Feed the drive
 | 
						|
      something, and/or check its master/slave status if it is
 | 
						|
      IDE (ATAPI). It can take a couple of seconds for a CDROM drive
 | 
						|
      to notice that it's been fed, so be patient.
 | 
						|
 | 
						|
      <p>Sometimes a SCSI CD-ROM may be missed because it hadn't enough time
 | 
						|
      to answer the bus reset. In you have a SCSI CD-ROM please try to
 | 
						|
      add the following symbol into your  kernel configuration file
 | 
						|
      and recompile.
 | 
						|
 | 
						|
      <verb>
 | 
						|
        options "SCSI_DELAY=15"
 | 
						|
      </verb>
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>My printer is ridiculously slow. What can I do ?</heading>
 | 
						|
 | 
						|
      <p>If it's parallel, and the only problem is that it's terribly
 | 
						|
      slow, try setting your printer port into ``polled'' mode:
 | 
						|
 | 
						|
      <verb>
 | 
						|
        lptcontrol -p
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>Some newer HP printers are claimed not to work correctly in
 | 
						|
      interrupt mode, apparently due to some (not yet exactly
 | 
						|
      understood) timing problem.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>My programs occasionally die with ``Signal 11'' errors.</heading>
 | 
						|
 | 
						|
      <p>This can be caused by bad hardware (memory, motherboard, etc.).
 | 
						|
      Try running a memory-testing program on your PC.  Note that, even
 | 
						|
      though every memory testing program you try will report your
 | 
						|
      memory as being fine, it's possible for slightly marginal memory
 | 
						|
      to pass all memory tests, yet fail under operating conditions
 | 
						|
      (such as during bus mastering DMA from a SCSI controller like the
 | 
						|
      Adaptec 1542, when you're beating on memory by compiling a kernel,
 | 
						|
      or just when the system's running particularly hot).
 | 
						|
 | 
						|
      <p>The SIG11 FAQ (listed below) points up slow memory as being the
 | 
						|
      most common problem. Increase the number of wait states in your
 | 
						|
      BIOS setup, or get faster memory.
 | 
						|
 | 
						|
      <p>For me the guilty party has been bad cache RAM or a bad on-board
 | 
						|
      cache controller. Try disabling the on-board (secondary) cache in
 | 
						|
      the BIOS setup and see if that solves the problem.
 | 
						|
 | 
						|
      <p>There's an extensive FAQ on this at
 | 
						|
      <url url="http://www.bitwizard.nl/sig11/" name="the SIG11 problem FAQ">
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>When I boot, the screen goes black and loses sync!</heading>
 | 
						|
 | 
						|
      <p>This is a known problem with the ATI Mach 64 video card.
 | 
						|
      The problem is that this card uses address <tt/2e8/, and
 | 
						|
      the fourth serial port does too. Due to a bug (feature?) in the
 | 
						|
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sio" name="sio.c">
 | 
						|
      driver it will touch this port even if you don't have the
 | 
						|
      fourth serial port, and <bf/even/ if you disable sio3 (the fourth
 | 
						|
      port) which normally uses this address.
 | 
						|
 | 
						|
      <p>Until the bug has been fixed, you can use this workaround:
 | 
						|
 | 
						|
      <enum>
 | 
						|
        <item>Enter <tt/-c/ at the bootprompt.  (This will put the kernel
 | 
						|
        into configuration mode).
 | 
						|
 | 
						|
        <item>Disable <tt/sio0/, <tt/sio1/, <tt/sio2/ and <tt/sio3/
 | 
						|
        (all of them).  This way the sio driver doesn't get activated
 | 
						|
        -> no problems.
 | 
						|
 | 
						|
        <item>Type exit to continue booting.
 | 
						|
      </enum>
 | 
						|
 | 
						|
      <p>If you want to be able to use your serial ports,
 | 
						|
      you'll have to build a new kernel with the following
 | 
						|
      modification: in <tt>/usr/src/sys/i386/isa/sio.c</tt> find the
 | 
						|
      one occurrence of the string <tt/0x2e8/ and remove that string
 | 
						|
      and the preceding comma (keep the trailing comma).  Now follow
 | 
						|
      the normal procedure of building a new kernel.
 | 
						|
 | 
						|
      <p>Even after applying these workarounds, you may still find that
 | 
						|
      X Window does not work properly.  Some newer ATI Mach 64 video
 | 
						|
      cards (notably ATI Mach Xpression) do not run with the current
 | 
						|
      version of <tt/XFree86/; the screen goes black when you start
 | 
						|
      X Window, or it works with strange problems. You can get
 | 
						|
      a beta-version of a new X-server that works better, by looking at
 | 
						|
      <url url="http://www.xfree86.org" name="the XFree86 site">
 | 
						|
      and following the links to the new beta release. Get the
 | 
						|
      following files:
 | 
						|
 | 
						|
      <p><tt>AccelCards, BetaReport, Cards, Devices, FILES, README.ati,
 | 
						|
      README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc,
 | 
						|
      X312BMa64.tgz</tt>
 | 
						|
 | 
						|
      <p>Replace the older files with the new versions and make sure you
 | 
						|
      run <htmlurl
 | 
						|
      url="http://www.freebsd.org/cgi/man.cgi?manpath=xfree86&query=xf86config"
 | 
						|
      name="xf86config"> again.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>
 | 
						|
        I have 128 MB of RAM but the system only uses 64 MB.
 | 
						|
        <label id="reallybigram">
 | 
						|
      </heading>
 | 
						|
 | 
						|
      <p>Due to the manner in which FreeBSD gets the memory size from the
 | 
						|
      BIOS, it can only detect 16 bits worth of Kbytes in size (65535
 | 
						|
      Kbytes = 64MB) (or less... some BIOSes peg the memory size to 16M).
 | 
						|
      If you have more than 64MB, FreeBSD will attempt to detect it;
 | 
						|
      however, the attempt may fail.
 | 
						|
 | 
						|
      <p>To work around this problem, you need to use the
 | 
						|
      kernel option specified below. There is a way to get complete
 | 
						|
      memory information from the BIOS, but we don't have room in the
 | 
						|
      bootblocks to do it. Someday when lack of room in the bootblocks
 | 
						|
      is fixed, we'll use the extended BIOS functions to get the full
 | 
						|
      memory information...but for now we're stuck with the kernel
 | 
						|
      option.
 | 
						|
 | 
						|
      <tt>
 | 
						|
        options "MAXMEM=<n>"
 | 
						|
      </tt>
 | 
						|
 | 
						|
      <p>Where <tt/n/ is your memory in Kilobytes. For a 128 MB machine,
 | 
						|
      you'd want to use <tt/131072/.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>FreeBSD 2.0 panics with ``kmem_map too small!''</heading>
 | 
						|
 | 
						|
      <p><tt /Note/ The message may also be ``mb_map too small!''
 | 
						|
 | 
						|
      <p>The panic indicates that the system ran out of virtual memory for
 | 
						|
      network buffers (specifically, mbuf clusters). You can increase
 | 
						|
      the amount of VM available for mbuf clusters by adding:
 | 
						|
 | 
						|
      <p><tt>options "NMBCLUSTERS=<n>"</tt>
 | 
						|
 | 
						|
      <p>to your kernel config file, where <n> is a number in the
 | 
						|
      range 512-4096, depending on the number of concurrent TCP
 | 
						|
      connections you need to support. I'd recommend trying 2048 - this
 | 
						|
      should get rid of the panic completely. You can monitor the
 | 
						|
      number of mbuf clusters allocated/in use on the system with
 | 
						|
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
 | 
						|
      name="netstat -m">.  The default value for NMBCLUSTERS is 
 | 
						|
      <tt/512 + MAXUSERS * 16/.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>``CMAP busy panic'' when rebooting with a new kernel.</heading>
 | 
						|
 | 
						|
      <p>The logic that attempts to detect an out of date
 | 
						|
      <tt>/var/db/kvm_*.db</tt> files sometimes fails and using a
 | 
						|
      mismatched file can sometimes lead to panics.
 | 
						|
 | 
						|
      <p>If this happens, reboot single-user and do:
 | 
						|
 | 
						|
      <verb>
 | 
						|
        rm /var/db/kvm_*.db
 | 
						|
      </verb>
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>ahc0: brkadrint,  Illegal Host Access at seqaddr 0x0</heading>
 | 
						|
 | 
						|
      <p>This is a conflict with an Ultrastor SCSI Host Adapter. 
 | 
						|
 | 
						|
      <p>During the boot process enter the kernel configuration menu and
 | 
						|
      disable <htmlurl url="http://www.freebsd.org/cgi/man.cgi?uha(4)"
 | 
						|
      name="uha0">, which is causing the problem.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>Sendmail says ``mail loops back to myself''</heading>
 | 
						|
 | 
						|
      <p>This is answered in the sendmail FAQ as follows:-
 | 
						|
 | 
						|
      <verb>
 | 
						|
        * I'm getting "Local configuration error" messages, such as:
 | 
						|
 | 
						|
        553 relay.domain.net config error: mail loops back to myself
 | 
						|
        554 <user@domain.net>... Local configuration error
 | 
						|
 | 
						|
        How can I solve this problem?
 | 
						|
 | 
						|
        You have asked mail to the domain (e.g., domain.net) to be
 | 
						|
        forwarded to a specific host (in this case, relay.domain.net)
 | 
						|
        by using an MX record, but the relay machine doesn't recognize
 | 
						|
        itself as domain.net.  Add domain.net to /etc/sendmail.cw
 | 
						|
        (if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
 | 
						|
        to /etc/sendmail.cf.
 | 
						|
      </verb>
 | 
						|
 | 
						|
      <p>The current version of the <url
 | 
						|
      url="ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq"
 | 
						|
      name="sendmail FAQ"> is no longer maintained with the sendmail
 | 
						|
      release.  It is however regularly posted to
 | 
						|
      <url url="news:comp.mail.sendmail" name="comp.mail.sendmail">,
 | 
						|
      <url url="news:comp.mail.misc" name="comp.mail.misc">,
 | 
						|
      <url url="news:comp.mail.smail" name="comp.mail.smail">,
 | 
						|
      <url url="news:comp.answers" name="comp.answers">, and
 | 
						|
      <url url="news:news.answers" name="news.answers">.
 | 
						|
      You can also receive a copy via email by sending a message to
 | 
						|
      <url url="mailto:mail-server@rtfm.mit.edu"
 | 
						|
      name="mail-server@rtfm.mit.edu"> with the command "send
 | 
						|
      usenet/news.answers/mail/sendmail-faq" as the body of the
 | 
						|
      message.
 | 
						|
 | 
						|
    <sect1>
 | 
						|
      <heading>Full screen applications on remote machines misbehave!
 | 
						|
      </heading>
 | 
						|
      <p>The remote machine may be setting your terminal type
 | 
						|
	to something other than the <tt>cons25</tt> terminal type used 
 | 
						|
	by the FreeBSD console.
 | 
						|
      <p>There are a number of work-arounds for this problem:
 | 
						|
	<itemize>
 | 
						|
	<item>After logging on to the remote machine, set your TERM shell 
 | 
						|
	  variable to either <tt>ansi</tt> or <tt>sco</tt>.
 | 
						|
	<item>Use a VT100 emulator like <htmlurl 
 | 
						|
	 url="http://www.freebsd.org/cgi/ports.cgi?screen-" name="screen"> 
 | 
						|
	 locally.  <tt>screen</tt> offers you the ability to run
 | 
						|
         multiple concurrent sessions from one terminal, and is a neat
 | 
						|
	 program in its own right.
 | 
						|
	<item>Install the <tt>cons25</tt> terminal database entry on 
 | 
						|
	  the remote machine.
 | 
						|
	<item>Fire up X and login to the remote machine from an 
 | 
						|
	  <tt>xterm</tt>.
 | 
						|
	</itemize>
 | 
						|
  </sect>
 | 
						|
 |