If you are unable for any reason to get control of the IntelliServer, you can user the following procedure to force the IntelliServer to load the factory default configuration . You may need to do this if the root password was lost or corrupted, or if the IntelliServer is disconnected from the network while booting.
IntelliServer, Release 1.0.0
Set factory defaults
init:need ip address to start network
At this point, the IntelliServer is running under factory defaults. You are logged in as root. The network software is not active at this time. The configuration stored in non-volatile RAM is available but not loaded.
You can restore the IntelliServer configuration from internal non-volatile RAM (you cannot restore from the host since the network software is not running) by typing restore at the # prompt.
Then make any necessary changes to the configuration, save the configuration to non-volatile RAM and then reboot.
The latest IntelliServer kernel files are available on the Computone ftp site. Use your e-mail address for the password. The IntelliServer kernel files are located
The cnx prefix files are for the IntelliServer, and the rac prefix files are the PowerRack IntelliServer kernels. The latest recommended kernel version is 1.7.2. Please be aware that this is not a flash-ROM update, but is the actual kernel data file, which must be installed to a host system which has the tftp service installed and active. See the readme for Release Notes.
You will need to point the IntelliServer to tftp boot to the host system under the IntelliServer Bootstrap configuration menu. Additionally, we have made a shareware Windows 95 and NT tftp file available, which is also in the pub/other/iserver/tftp directory. We make these available as a service to our customers, and assume no further responsibility for them, although they have been tested, and qualified to function correctly. It is also possible to have the kernel burned into an EPROM chip, and have it shipped to you. There is generally a fee associated with this service. Should you wish to obtain the EPROM, please call us directly at (770) 625-0000 or (800) 241-3946. Dial out to the operator, and ask to be connected with the Sales Associate for your state or region.
In regard to upgrading the Intelliserver kernel, bear in mind that it does not have a hard disk drive to store the new kernel, nor is the PROM chip in the PowerRack engine card flashable. For these reasons, if you want to boot from our new kernel, you will need to download the kernel to a host machine on your network, and then point the PowerRack to boot from that host machine. This letter will outline the steps that should be taken to get the PowerRack to boot from a host machine.
Once you have followed these steps, the PowerRack will be able to boot from the host machine. If you reset the PowerRack, you should see that the new kernel says 1.5.4d.
Please understand that the PowerRack
has no way of storing the new kernel, and that the host machine needs
to be up each time you wish to reboot the new kernel. If
the host machine is not up and you reboot the PowerRack, it will try
to find the host 5 times and then boot from its original kernel.
If you have to reload your IntelliPort drivers, you should follow these directions. Before you go to all the trouble, try running fipinst. If you are only trying to re-install a driver, fipinst will work. The only time you should have to remove a driver is when you are running the 2.17 driver, or earlier.
To save the current configuration of an IntelliPort II, you must save the following files.
You can accomplish this by creating
a directory called " save" or what ever you want to call it and then
use the cp command to copy all of these files over to this directory
. Uninstall the Computone IntelliPort drivers, reboot and then reinstall
the drivers, and copy these files back into the appropriate directories.
After you reboot, your ports will be configured as they were before.
The following installation process is for IntelliPort drivers version 2.2.1 and below.
This is a step by step guide for accomplishing this.
You must first create
a directory called "safe" using the following commands.
Once the directories have been created begin copying existing IP2 files into it with the commands below.
cp -R /etc/default/fip.d/*
cp /etc/inittab /safe
cp /etc/ttytype /safe
When you finish copying the
files above go into "custom" and begin the driver removal process. You
must re-link the kernel and reboot for the process to complete. When
the sytem boots back up once again in "custom" add the newer version
of the IP2 driver. You must now copy the files from the "safe" directory
back into the /etc directory.
cp -R /safe/default/fip.d/*
cp /safe/inittab /etc
cp /safe/ttytype /etc
What does the error message mean: ST_HWfail
The error you are seeing can
be caused from any one of the following.
To check these error messages on Unix machines, go to the /usr/adm directory and look at the messages file. This file may be quite large, because it will contain the boot logs from every time your machine has booted. Search for ST_HWFAIL and you will see every occurrence, and any other problems reported. Look for Interrupt conflicts. Note that Unix will call these "vectors".
You really can't extend the distance from the Card to the Board. What the cable and expansion box represent is an extension to the PC bus. This distance is limited to six feet by those standards written for PC buses. I would recommend that you investigate the possibility of using the IntelliServer line of products if distance is the problem. You can put an IntelliServer anywhere on your network, within the limitations of Ethernet, and you will have the serial ports that you need.
What are three common problems that can lead to a printer losing data on the IP2?
There are three common problems that can lead to a printer losing data:
(1) Flow control improperly configured. In this case a short print job may appear to lose data only at the end, and a very short one may not lose data at all. A sufficiently long job will lose data throughout the report, not just at the end.
(2) Port-close flushing. Under Unix, when a port is closed, the OS does not expect to wait indefinitely for data to drain. It asks the driver to "resume" sending that may have been stopped by flow control, and afterward to "flush" any remaining output. This is how serial ports work as a matter of design; it is not driver-specific. Because of this, it is common for spooling scripts to include the command "drain_output" (I think it is called). This command performs a certain ioctl() on the standard output, the effect of which is to wait _INDEFINITELY_ for output to drain, before continuing. This is typically the last command in the script, so by the time the script exits (and the port is closed) the output has already drained. In some circumstances, this solution is not practical, so there are two other solutions available. Correctly placing NOFLUSH=y! in the intellitype entry for this port, or in the corresponding intellicap entry, will prevent the driver from issuing the "resume" and "flush" commands and should prevent any loss of data from that cause. In this case, the port would be closed before the buffered data had drained, but this data would be sent in due course. Since this solution allows the close to complete before data is sent, it may be that another process may re-open the port and begin to use it. This would not ordinarily be a problem, since any additional data would naturally follow what was already buffered. If this new process performs any deliberate flush or drain operations, it could of course affect any buffered data, even data buffered by earlier jobs. Also remember, whenever you make a change to intellitype/intellicap files, you must run fip_reinit or restart the system before the change takes effect. Another solution, similar in effect to noflush=y!, is to use a "hold open" script on the port. This will eliminate ALL side-effects of closing the port by preventing it from being closed at all. (The driver's "open" function is called when any process opens the port, but the driver's "close" function is called only when the _last process to still have the port open, closes it. If there is always some process with the port open, the driver's close function is never called.
Typical hold-open script:
done < /dev/ttys05 &
(in this case, port 5 is being held open)
You will typically write a script containing these lines, use chmod to give the script execute permissions, and arrange to have it automatically run at startup (by appropriate manipulations of the rc scripts, for example). Or, as an experiment, you can simply type the script at the console (it runs in background) just before attempting to use the port for printing a job that is known to lose data.
Data-set signal anomalies. Another side effect of close(), depending on stty settings, is that the DTR signal may be dropped. Depending on your printer, and what printer pin (if any) the DTR signal may be connected to, this action may in itself cause some printers to toss data. In such case, a change in cabling or printer configuration, or using a hold-open script, may remedy the problem.
* * * * *
It is important to note the _exact character of the data loss. Is the missing data _always at the end of the job, or is it sometimes a missing piece shortly before the end, while the actual end of the job does appear?
* * * * *
Another interesting note: when you have flow control problems, increasing the baud rate (with a fixed rendering speed) will tend to make the problem _worse, while if you have an end-of-job flushing problem, DECREASING the rate will tend to make it worse.
SYNOPSIS: Preventing an IntelliServer reboot from halting the Sun system
Patches for Solaris 2.6 and Solaris 7 are available:
The patches do not describe how to implement
the alternate break signal.
The following procedure will enable the alternate break signal.
Step 1. Install patch 105924-10
on Solaris 2.6 or patch 107589-02 on Solaris
Step 2. Modify the /etc/default/kbd file, by removing the # from the entry:
and changing it to:
Step 3. Reboot the IntelliServer.
Now only the alternate break sequence
will be recognized as the abort sequence.
The bug report also offers the following commentary:
A proposed solution is quite
straightforward and simple: when the
In order for this change
to provide the same high level interrupt