lsg07.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

<P>The standard naming convention for SCSI tape drives is /dev/nrst<I>digit</I> for non-rewinding devices (such as /dev/nrst0, /dev/nrst1, etc) and /dev/rst<I>digit</I> for rewinding devices (such as /dev/rst0 and /dev/rst1).



<BR>



<P>Generally, Linux supports tape devices that use either fixed or variable length blocks, as long as the block length is smaller than the driver buffer length (which is set to 32K in most Linux distribution sources, but can be changed by reconfiguring the kernel). Tape drive parameters like block size, buffering process, and tape density are set by the mt program where needed.



<BR>



<P>A common problem with SCSI tape drives occurs when you are trying to read tapes from other systems (or another system can't read a tape made in Linux). This problem occurs because of different block sizes used by the tape system. On a SCSI tape device using a fixed block size, you must set the block size of the tape driver to match the hardware block size used when the tape was written (or to variable). You change this setting with the mt command:



<BR>



<BR>



<PRE>



<FONT COLOR="#000080">mt setblk &lt;size&gt;</FONT></PRE>



<P>Replace size with the block size, such as 20. If you want a variable block length, set size to zero. Some Linux versions don't have a version of mt that lets you change block sizes (usually the GNU version). If that's the case, get the BSD version of mt, which does support this feature.



<BR>



<BR>



<A NAME="E69E74"></A>



<H4 ALIGN=CENTER>



<CENTER>



<FONT SIZE=4 COLOR="#FF0000"><B>Other Devices</B></FONT></CENTER></H4>



<BR>



<P>There are many more SCSI devices available, such as scanners, printers, removable cartridge drives, and so on. The Linux generic SCSI device driver handles these devices. The generic SCSI driver provides an interface for sending commands to all SCSI devices.



<BR>



<P>SCSI generic devices use character mode and major number 21. The minor numbers are assigned dynamically from zero for the first device. Generic devices have the names /dev/sg0, /dev/sg1, /dev/sg2, and so on.



<BR>



<BR>



<A NAME="E68E42"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Troubleshooting SCSI Devices</B></FONT></CENTER></H3>



<BR>



<P>Many common problems with SCSI devices are quite easy to solve. Finding the cause of the problem is often the most difficult step, and reading the diagnostic message displayed by the operating system when it boots or attempts to use a SCSI device can usually help with this step. Table 7.1 lists the most common problems with SCSI devices, their probable causes, and possible solutions.



<BR>



<BR>



<P ALIGN=CENTER>



<CENTER>



<FONT COLOR="#000080"><B>Table 7.1 Common SCSI problems.</B></FONT></CENTER>



<BR>







<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="100%" CELLPADDING=2 >



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



<I>Problem</I>



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



<I>Cause</I>



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



<I>Solution</I></FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



SCSI devices show up at all possible SCSI IDs.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



You have configured the device with the same SCSI address as the controller (which is typically set at SCSI ID seven).



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Change the jumper settings to another SCSI ID. </FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



A SCSI device reports using all possible LUNs.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The device probably has bad firmware.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The file drivers/scsi/scsi.c contains a list of bad devices under the variable blacklist. Try adding the device to this list and see whether it affects the behavior. If not, contact the device manufacturer.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Your SCSI system times out.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Delay in sending signals to the device.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Make sure the interrupts of the controller card are enabled correctly and there are no IRQ, DMA, or address conflicts with other boards in your system.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



You get sense errors from error-free devices.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



You have bad cables or improper termination on the chain.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Make sure the SCSI chain is terminated at both ends using external or on-board terminators. Don't terminate in the middle of the chain, as this can cause problems, too. You can probably use passive termination. For long chains with several devices, try active termination for better behavior.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The tape drive is not recognized at boot time.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Either the SCSI chain didn't recognize the tape drive or the device driver is not installed.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Try booting with a tape in the drive.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



A networking kernel does not work with new SCSI devices.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The autoprobe routines for many network drivers are not passive and can interfere with some SCSI drivers.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Try to disable the network portions to identify the guilty program, and then reconfigure it.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



A SCSI device is detected but the system is unable to access it.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



You probably don't have a device driver file for the device.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Device drivers should be in /dev directory and configured with the proper type (block or character)and unique major and minor device numbers. Run mkdev for the device.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The SCSI controller card fails when it uses memory mapped I/O.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



This problem is common with Trantor T128 and Seagate boards and is caused when the memory mapped I/O ports are incorrectly cached.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



You should have the board's address space marked as uncachable in the XCMOS settings. If you can't mark them as uncachable, disable the cache and see whether the board functions properly.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Your system fails to find the SCSI devices and you get messages like scsi : 0 hosts or scsi%d : type: when the system boots.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



The autoprobe routines on the controller cards rely on the system BIOS autoprobe and can't boot properly. This problem is particularly prevalent with SCSI adapters in the following list: Adaptec 152x, Adaptec 151x, Adaptec AIC-6260, Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950, Future Trantor T128, Trantor T128F, Trantor T228F, Seagate ST01, Seagate ST02, or Western Digital 7000.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Check that your BIOS is enabled and not conflicting with any other peripheral BIOSs (such as<A NAME="I2"></A> on some adapter cards). If the BIOS is properly enabled, find the board's signature by running DOS' DEBUG command to check whether the board is responding. For example, use the DEBUG command d=c800:0 to see whether the board replies with an acknowledgment (assuming you have set the controller card to use address 0xc8000; if not, replace the DEBUG command with the proper address). If the card doesn't respond, check the address settings.</FONT>



<TR>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Sometimes the SCSI system locks up completely.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Many possible causes,including a problem with the host adapter.



</FONT>



<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>



Check the host adapter with any diagnostics that came with the board. Try a different SCSI cable to see whether that is the problem. If the lockups seem to occur when multiple devices are in use at the same time, you probably have a firmware problem. Contact the manufacturer to see whether upgrades are available that could correct the problem. Finally, check the disk drives to ensure that there are no bad blocks that could affect the device driver files, buffers, or swap space.</FONT>



</TABLE><BR>



<A NAME="E68E43"></A>



<H3 ALIGN=CENTER>



<CENTER>



<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>



<BR>



<P>More information about some specific SCSI devices is in the following chapters, but SCSI on the whole is a convenient and reliable interface that is well worth the investment. Adding SCSI devices is much simpler than adding any other kind of devices. For this reason, SCSI is popular among UNIX users, and now, among Linux PC users, despite its extra costs. The next few chapters look at some general hardware devices in more detail. This information is necessary when you expand your system by adding new peripherals.



<P ALIGN=LEFT>



























</td>
</tr>
</table>
<!-- begin footer information -->


</body></html>