FAQ Tahoma Technology

FAQ

After 49 years in business, 2015 will be our last. Please use the Contact Us link for details.

Welcome to Tahoma Technology's Frequently Asked Questions page. This page will be added to over time.

The most common problem when installing one of our boards that supports both Versatec and Centronics interfaces is incorrect strapping. On boards like the 10117 Pci hardcopy and 10111 ISA/EISA hardcopy the VPI Differential, VPI TTL (on the 10111), and Centronics mode is selected by the on-board jumper cable. One end connects to the I/O Out pins, the other end to the appropriate interface pins (V-DIFF, V-TTL, or Cent). Please examine the board before installation, and set the jumper appropriately. Most Versatec compatible plotters use differential mode, a few use TTL.

There are (at least) two possible explanations for this message. One is trying to load a driver for a board that isn't present in the system. The other is trying to load a driver incompatible with the operting system.

When a driver actually fails to attach, it indicates that the driver didn't find the board. This will happen if the user attempts to install the driver before installing the board. It will also happen if the user attempts to install the wrong driver for the board. The hardcopy interfaces use the ihcp driver, the DR11 interfaces use the idr driver. Some of our driver packages include both drivers. Only install the one appropriate for the board. Using the "all" option will install the wrong driver along with the correct one. This is harmless, but will cause the troubling error message, and add an unnecessary module to the kernel.

If the user attempts to load a 32 bit driver into a 64 bit operating system, this error message will also be issued. The error message should probably be something like "can't link driver with kernel", but Sun chose to use the "failed to attach" message. See the "32 bit driver in 64 bit OS FAQ" below.

Tahoma's Centronics capable boards are shipped with an extra termination resistor network. This 470 Ohm pull-up is used when connected to a printer/plotter that can't drive our default terminations. This most often occurs with 1284 compatible printers that use weak, series-matched cable drivers. NovaJet printers frequently require the alternate network. If the Hardcopy board is correctly configured to use the Centronics interface, and isn't communicating with the plotter, try the 470 Ohm network. The default network should be used for all VPI applications. If needed, install the alternate network in the socket labelled "TERM".

In our README files, we suggest testing a VPI board/driver/plotter combination by sending a file to /dev/ihcp0, using something like (for a text file "textfile"): pr textfile | ./filtertest >/dev/ihcp0, or cat textfile >/dev/ihcp0. If the plotter has ascii print capability, AND the board/driver combo is in print mode, this should print the text file. If the plotter does not have ascii capability OR the board/driver combo is in plot mode, this will produce a row of dots, or no printing at all. Sending a plot file to a plotter in text mode may produce (many) blank pages, or pages filled with nonsense text. For historical reasons, some Tahoma boards/drivers default to print mode, and some to plot mode. This can be changed for Solaris by modifying the ihcp.conf file and reloading the driver. For Linux, modify the install script before loading the driver. See the driver README files for details.

The utility program ikonex may also be used to test the board/driver/plotter combination. It can be used to send a pre-existing file to the plotter in either print or plot mode. Ikonex can also manipulate other board/driver functions, and return board/driver/plotter status. Ikonex is found in the utilities directory under Downloads.

Some early versions of Sun's Enterprise 450 have a bug in the open boot prom that causes certain Pci board's Vendor and Device IDs to be reversed. In this case, the pkgadd command loads the driver, but does not create the /dev nodes, which are (supposed to be) links to entries in the /devices directory.

One can verify the ID reversal problem by examining the entries in /devices/pci@x,y000 (x,y varies w/bus & slot). Our boards should look something like: pci11d5,117, but show up as pci117,11d5.

1) Download corrected firmware from Sun. The following link should point to correct firmware - but the user MUST verify this before flashing their OBP!

2) Modify /etc/devlink.tab to look for the reversed IDs. This example is for hardcopy boards. For DR11 boards, replace 117 with 118, and ihcp with idr.

As super user:
Install our board(s), and pkgadd the appropriate driver package.
Manually uninstall the driver: rem_drv ihcp.
Edit /etc/devlink.tab - find the line that says: type=ddi_pseudo;name=pci11d5,117 \M0
Change to read: type=ddi_pseudo;name=pci117,11d5 \M0
(Note that the whitespace before the \M0 above is a TAB)
Manually reinstall the driver: add_drv -m '* 0666 bin bin' -i '"pci11d5,117"' ihcp
You should now see ihcp nodes in /dev, and modinfo should show the ihcp driver loaded.

It is generally not necessary to compile a Solaris driver. All driver versions include a pre-compiled driver object which may be installed and run as is. All Solaris 7/8 drivers use a .conf file which defines driver parameters which may be set at load time, without recompiling. Use a text editor to modify these parameters. Recompilation will only be required when the user modifies the driver's source code, or when parameters are modified in older drivers which do not use the .conf file.

Rarely, a customer has a VPI compatible plotter and cable which will not operate when connected to a hardcopy board, even though they operate correctly with another data source. There are, of course, several possible explanations, but one that bears checking has to do with how the VPI differential (long lines) interface works. Each logical signal (data bit or control) is transmitted via a pair of wires. The pair consists of a + and - signal, rather than a signal and ground. If one of the pair is disconnected, either in the cable, or in the logic at either end of the cable, some differential receivers may still switch correctly, even with one floating input. This varies with receiver type, and even from one receiver to another of the same type. When this behavior is encountered, it is advisable to try another cable, and/or inspect all connectors for bent or missing pins.

A "paper clip plotter" is occasionally useful to someone trying to troubleshoot a driver/board/cable/plotter problem. If an attempt to send data to the plotter simply hangs (ie, no plotter data, and no return to the Unix command prompt), it can be difficult to determine where in the driver/board/cable/plotter chain the problem lies. By using paper clips (or other wires) to loop the board's data strobe back to its READY/-ACK input, testing can be isolated to the board and and driver. With the paper clips in place, a "cat" of data to the /dev/ihcp device should always return to the command prompt. If it does not, there is likely a board or driver problem. Note that most Tahoma hardcopy boards have an internal fifo. If the test file used is smaller than approximately 1/2 the fifo depth, the command prompt may return even if the board's i/o logic is defective. Use a file of 10K bytes or so, or do multiple "cat" commands to properly test with a "paper clip plotter."

For Centronics configurations connect a paper clip from pin 1 (-STROBE) to 10 (-ACK), and another from pin 11 (BUSY) to pin 30 (GROUND).
For VPI TTL configurations (short lines), connect a paper clip between pins 10 (PICLK) and 11 (-READY).
For VPI Differential configurations (long lines), connect a paper clip between pins 10 ( +PICLK) and 11 (-READY), and another between pins 29 (-PICLK) and 30 (+READY).

To insure that the hardcopy board is properly initialized prior to starting the test, it may be necessary to power cycle the host, or unload and reload the driver. Note that this test loops the data strobe, but not the VPI pulsed command lines. Attempting to send pulsed commands to the "paper clip plotter" will hang.

The short answer is no. If the user attempts to load a 32 bit driver into a 64 bit kernel, the "failed to attach" error message will be issued. Generally speaking, our Solaris (2.x) drivers can be used with a Solaris 7/8/9 kernel if the kernel is booted in 32 bit mode. A better choice would be to use one of our 32/64 bit Solaris 7 drivers (compatible with Solaris 7/8/9). As of this writing, Tahoma has Solaris 7 drivers for all Solaris compatible products except the 10103 Sbus DR11-W emulator.

The RedHat 7.2 "stock" kernel - 2.4.7-10 works with our earlier 2.4 drivers. For some reason, RedHat is basing its updated kernels on 2.4.9-xx, which is a side branch that uses alloc|free_kiovec_sz routines instead of the alloc|free_kiovec routines supported by earlier and later kernels. Our newer drivers and install scripts will autodetect which kiovec functions are supported, and compile accordingly. The newer driver and script code also autodetects some other compile/load options, and provides additional user-configurable parameters. If you are experiencing compile warnings and/or insmod errors with RedHat 7.2, please download the latest Linux driver(s).

Earlier 2.4.x drivers did not handle the >1G of RAM case correctly. The latest drivers detect the kernel and driver memory mode at compile time. If the kernel is configured for large memory (>1G, CONFIG_HIGHMEM true), but does not support the new style scatterlist, the driver will create a kernel copy buffer, and do DMA from that. In all other cases, the driver will do user buffer DMA. The driver install script will attempt to use the new style scatterlist by default. If the kernel does not support it, the compile will fail with a message suggesting that the install script be edited to use the old style scatterlist.

For maximum performance, it is recommended that a newer kernel that supports the new style scatterlist be used with machines equipped with more that 1G of RAM.

When running the standard Solaris 7 driver with a PCI DR11 10116 or 10118 in certain Sun SPARC machines (SunBlade 1500, 2500, V440 and possibly others) idr.loop.test may indicate intermittent errors, which may also occur when running application software. The exact cause is yet to be determined, but seems to relate to the PCI bridge chip used by these machines. A modified driver is available which avoids triggering this problem. Follow the driver download link Solaris 7 -> pci -> sparc -> packages and download and install the pci_idr_sparc_S8_2004.05.21.0942.Z compressed driver package. idr.loop.test may be used in loopback mode to demonstrate errors and verify the fix. The modified driver may be used on other Sun platforms as well. It has been tested with Solaris 8 and 9.

As of January 1 2016, Tahoma Technology is no longer in business.

We will continue to monitor email for at least one year.

Please use the Contact Us link for information.