• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1098
  • Last Modified:

HP DAT 40 configuration

I have an HP DAT 40 tape drive I'd like to put in my Linux box. I need advice on whether what I want to do will work.

The drive is labeled SureStore DAT 40 and is from an old NetServer LH 3 running Windows NT. I assume it is SCSI (but if not, please advise). It takes tapes labeled DDS-4. These tapes also have DDS-150 imprinted.

My Linux machine has a SCSI tape drive taking tapes which are the same size as the DAT 40, but they are labeled DDS-3 and also DGD125P.

1. Will the DAT 40 work with the Linux machine? If so, any advice on which drive to select? If so, any advise on which SCSI card to use? (Currently, it plugs into the NetServer motherboard, no separate card).

2. What is the difference between DDS-3 and DDS-4 tapes?

3. Will the DAT 40 read and/or write DDS-3 tapes? Primarily, I want to read the DDS-3 tapes, not write them.
0
jmarkfoley
Asked:
jmarkfoley
  • 7
  • 7
  • 4
2 Solutions
 
pjedmondCommented:
1. Yes the SureStore DAT 40 will work with your Linux Netserver LH3. You will need to ensure that the SCSI card is configured to recognise the drive, however, most SCSI cards will recognise the drive automatically. You should get the option to configure the SCSI during the boot process if it requires manual configuration. Only warning on this is that the RHEL4, and clones DO NOT by default recognise megaRAID SCSI cards.

2.  DDS-3 tapes are nominally 125m, and DDS-4 tapes are nominally 150m, although both tend to be slightly longer in order to 'guarantee' the amount of data that can be stored on them.

3.  A DDS-4 drive can use 'DDS-3' tapes, and can read and write to them....but if the tape has been written to by a DDS-3 drive, then the default configuration definitely DOES NOT read them. However, looking here:

http://star.pst.qub.ac.uk/help/tapes.shtml

appears to imply that it should be able to read DDS-3 tapes created on a DDS-3 tape drive. Bear in mind that some DDS3, and DDS4 drives have 'compression' 'build in', or selected using a jumper. Trying to use these tapes on a different tape drive is doomed to failure. Overall, I can say 100% that you'll be unable to read them, but only that there are a number of factors stacked against you. It could work....provided a number of 'ifs' are satisfied.

HTH:)

0
 
jmarkfoleyAuthor Commented:
Thanks. I'm going to try this today. I am trying to read DDS3 tapes on this DDS4 drive. We'll see.

Your comment about compression concerns me. I understood that most of these drives did the compression automatically. If the compression is proprietary, that would make interchanging tapes impossible. That isn't real good for a backup medium. I have lost an entire computer in a fire before and was able to restore on a different computer with different drive, so maybe the compression thing isn't as hopeless as all that. I'll post results later.
0
 
Duncan RoeSoftware DeveloperCommented:
I think almost all SCSI drives do compression, hence the way the tapes are marketed with a "native capacity" (i.e. uncompressed). They used to be marketed with a "typical(?)" capacity about twice that. I have never had any trouble with another tape drive reading such tapes, except DDS-1 (plain DDS) reads very slowly on a DDS-3 drive. You are going to try it, so you'll soon find out. You should be able to put your new drive on the same SCSI bus (cable) as your old one if your cable as extra connectors, else just move the existing connector. If attaching both, make sure the new drive has a unique LUN (SCSI unit number) - usually tape drives seem to come jumpered to be LUN 4.
As DDS revs go up, so do the tape lengths. 90 (meters) for DDS, 125 for DDS-3, 150 for DDS-4 ...
If you want to add a SCSI card - I've found the Adaptecs tio be very good. My old VESA DX2-66 had a BusLogic which worked flawlessly for many years. Really any named brand with Linux support should be OK - it's just that there seem to be a lot of second-hand Adaptecs at the swap meets right now and they've never given me any trouble.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
pjedmondCommented:
The 'normal' default state for a purchased DDS-4 drive is without hardware compression, however, there is often a jumper that provides additional hardware compression, without the PC having to do work. It's a optional feature rather than a fixed 'no choice' feature.

I've been doing a little more research, and been messing around with my collection of parts. It is possible to read on a Surestore DDS-4 DAT tape from a tape written to by an HP DDS-3. I did however have to specify the block size (so it is worth checking what the default block size is for , and also both of the drives concerned have had minimal use. I also wrote on a 'well-used' Seagate DDS-3, and could not recover the data on the Surestore.

Also out of curiousity, I tried transferring between a Seagate and Surestore DDS-4, and both drives will read tapes written by the other.

So, my general feeling is that you may need to find out the default block size used for your DDS-3 tapes in order to 'force' tar to work properly. I thought that it should be 96:

http://wwwwbs.cs.tu-berlin.de/user-taipan/kraxel/gnuinfo/tar/Blocking_Factor.html

I suspect that my Seagate DDS-3 tape drive may be worn/clogged up, and tape speed may be slightly different. However, I was under the impression that tape drives should be more tolerant of this type of problem than other devices in order t ocope with the slight tape 'stretch' during the first few uses. Although I have seen problems of this nature in the past with 1.44M FD, I haven't ever played around with DDS drives enough to consider that there may (or may not) be an issue here. (DDS drives tend to be more expensive than FDs!!)

So...it definitely IS POSSIBLE to read a tape written on a DDS-3 drive using a Surestore DDS-4 drive. However this is not always the case, and these tests were done using tar on a Surestore DDS-4 in a RHEL system. The Seagate DDS-4, and HP DDS-3 were an externally connected drives, and the Seagate DDS-3 was on my fileserver (running, dare I admit it RH7.3...so something may have changed with the way tar works since then) ....which leads me to the final point - If your backup isn't based around tar, then the backup software concerned MAY choose different default configurations for different DAT drives.

Anyway, I hope this rambling helps! I can't assist any further I'm afraid.



 
0
 
jmarkfoleyAuthor Commented:
OK - now the hard part. The computer can't see the drive.

I've got an Adaptec 2944UW installed and connected to my DAT-40. When I boot, I can get the the adaptec SCSI bios with CTRL-A, so I know the card is working hardware-wise. According to the SCSI utility, the host adapter is SCSI ID 7, IRQ 3, Port 2400h.

At boot, dmesg gives me:

SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2

If I do any tape operations like mt status, I get: /dev/tape: No such device
/dev/tape is linked to /dev/nst0, just like on my computer that works.

HELP! What's am I doing wroing?

This is Linux version 2.4.31, slackware distribution.

On the kernel I just built I have the .config has (these are all the same settings as my system that does work):

    <*> SCSI support
     --- SCSI support type (disk, tape, CD-ROM)
     <*>   SCSI disk support
     (40) Maximum number of SCSI disks that can be loaded as modules
     <*>   SCSI tape support
     <M>   SCSI OnStream SC-x0 tape support  
     < >   SCSI CD-ROM support
     <*>   SCSI generic support
     --- Some SCSI devices (e.g. CD jukebox) support multiple LUNs
     [*]   Enable extra checks in new queueing code
     [*]   Probe all LUNs on each SCSI device
     [*]   Verbose SCSI error reporting (kernel size +=12K)  
     [*]   SCSI logging facility  
 
Under low level drivers, pretty much everything is a module. The first page of setting is below (where most of the adaptec stuff is). I did make modules and make modules_install.

 <M> 3ware Hardware ATA-RAID support
 <M> 7000FASST SCSI support
 <M> ACARD SCSI support  
 <M> Adaptec AHA152X/2825 support
 <M> Adaptec AHA1542 support  
 <M> Adaptec AHA1740 support  
 <M> Adaptec AACRAID support (EXPERIMENTAL)
 <M> Adaptec AIC7xxx support
 (8)   Maximum number of TCQ commands per device
 (15000)   Initial bus reset delay in milli-seconds
 [ ]   Probe for EISA and VL AIC7XXX Adapters  
 [ ]   Build Adapter Firmware with Kernel Build
 [ ]   Compile in Debugging Code  
 (0)   Debug code enable mask (2048 for all debugging)
 [ ]   Decode registers during diagnostics  
 <M> Adaptec AIC79xx support
 (32)   Maximum number of TCQ commands per device
 (15000)   Initial bus reset delay in milli-seconds
 [ ]   Build Adapter Firmware with Kernel Build
 [ ]   Enable Read Streaming for All Targets
 [ ]   Compile in Debugging Code  
 (0)   Debug code enable mask (16384 for all debugging)
 [ ]   Decode registers during diagnostics  
 <M> Old Adaptec AIC7xxx support  
 [ ]   Enable Tagged Command Queueing (TCQ) by default
 (8)   Maximum number of TCQ commands per device
 [ ]   Collect statistics to report in /proc  
 <M> Adaptec I2O RAID support
 <M> AdvanSys SCSI support    
 <M> Always IN2000 SCSI support        
 <M> AM53/79C974 PCI SCSI support  
 
0
 
pjedmondCommented:
You're probably not doing anything wrong. I'm going to guess that you are using a Redhat derivative.....If not, then let us know...but I've seen this problem on CentrOs 4.3 and RHEL 3 and 4. (You may also need to do a similar mod with your network cards!)

You need to add a line 'alias scsi_hostadapter' to your /etc/modules.conf    My file is:
--------8X----------------------------
alias eth0 via-rhine
alias scsi_hostadapter atp870u
alias usb-controller usb-uhci
--------8X----------------------------
For you it will probably be aic7xxx or aic79xx (rather than atp870u), or if you need to check the names of the other possible modules have a look in the:

/lib/modules/2.4.21-15.EL/kernel/drivers/scsi/

Obviously change the kernel directory name depending on your version.

However, if this doesn't work, then fire up a Knoppix disk:

http://www.knoppix.org/

It is probably the best (well know) linux distribution for the identification of  hardware. It's a live disto, so it boots from a CDROM and will not touch your hard-drive. Once booted, run the command:

lsmod

It will list the installed modules, and a little intelligent guesswork will identify the correct module for you to use.

HTH:)
0
 
pjedmondCommented:
If you're running an old version of RH, then this post may be of use:

https://www.redhat.com/archives/valhalla-list/2002-June/msg01726.html
0
 
pjedmondCommented:
To help with diagnostics, you could try:

ls /proc/scsi

which will show you scsi cards installed.

cat /proc/scsi/scsi

Also gives valuable indications as to what the system has recognised.

HTH:)
0
 
pjedmondCommented:
It also appears, that there may be rare cases where even the above doesn't work!:
---------8X-----------------
# [Potential Pitfall]: Case study - Dell Precision 340 with IDE hard drives, CD and DVD, Adaptec SCSI 29160. The SCSI module would not load even though it is listed in the /etc/modules.conf. The SCSI driver module (aic????) was not listed as loaded when the /sbin/lsmod command was issued. I had to add an entry to the file: /etc/rc.d/rc.local:
insmod aic7xxx
---------8X-----------------

From:

http://yolinux.com/TUTORIALS/LinuxTutorialRedHatInstallation.html#ADAPTECDATACORRUPTION

Again, looks like a RH issue. To defend RH here, they put together from loads of bits an extremely reliable distro. Because they are reliable, and reasonably consistant, more people use their setup, AND as a result the reporting infrastructure for faults is much better than for other distros. This means that any problems are more likely to be reported and documented. I use RH and its derivatives:)
0
 
Duncan RoeSoftware DeveloperCommented:
OK I know - you are not running RedHat or a derivative. You are running Slackware 10.2. I am running Slackware 10.0, which we also have at work (guess why:). My wife's machine is Slackware 10.2, but no SCSI.
It seems you may not have done a modprobe for the SCSI driver - init won't do that for you unless you configure it. lspci shows me:
    00:08.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01)
pretty close to yours, and I use:
   22:15:39$ grep aic7xxx /etc/rc.d/rc.modules
   # This is support for the various aic7xxx based Adaptec SCSI
   /sbin/modprobe aic7xxx

Try a modprobe from the command line and see if that fixes it
0
 
jmarkfoleyAuthor Commented:
Thanks for all the tips. No it is not redhat - slackware. lspci gives me

00:04.0 SCSI storage controller: Adaptec AHA-2944UW / AIC-7884U (rev 01)

I did insmod aic7xxx. lsmod now gives me:

Module                  Size  Used by    Not tainted
aic7xxx               141016   0  (unused)
usb-ohci               19368   0  (unused)
usbcore                59084   1  [usb-ohci]
8139too                13928   1
mii                     2272   0  [8139too]
crc32                   2880   0  [8139too]
pcmcia_core            39140   0
ide-scsi                9392   0
agpgart                45508   0  (unused)

ls /proc/scsi now shows:
aic7xxx/  ide-scsi/  scsi

cat /proc/scsi/scsi says Attached devices: none

I still get /dev/tape: No such device

using alias scsi_hostadapter aic7xxx in /etc/modules.conf didn't appear to help.

I also tried /sbin/modprobe aic7xxx and it loaded the aic7xxx module as the insmod aix7xxx did, but still no go.

I haven't tried the knopix tools yet. I'll do that next, but I wanted to get this info out there for some more feedback. Is it possible the 2940UW isn't supported? Yest duncan_roe appears to have one.
0
 
Duncan RoeSoftware DeveloperCommented:
Looks like the card is not seeing the drive - I did wonder about that when you posted earlier. The SCSI BIOS test you did earlier with cntrl-A should have shown you the tape drive. If not, don't expect to see it under Linux.
Usual things - check SCSI connector is fully home at both ends and drive has power connected.
Failing that, wait for a convenient time to power off the "working" system (with the DDS-3). Remove power cord and cover, unplug signal & data cables to DDS-3 drive, plug into DDS-4 drive, power on system and enter SCSI BIOS test. If you can now see the new drive, you must have a bad cable or controller on your new system. Extra possibility: new drive has high LUN (>7) but there is a 50-wire component to the cable path (i.e. you have an adaptor to convert from 80 or 68 pin somewhere).
0
 
jmarkfoleyAuthor Commented:
Well, I just finished doing a similar test. I swapped the DSS-3 drive and Buslogic SCSI controller card into the "new" system. SAME THING! dmesg still gives the 'kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2' message.

I know the SCSI card works, I know the cable is good, I know the drive is good. lspci sees the card and gives:

00:04.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 08)

What could possibly be wrong now? I need this system by tomorrow! Help!
0
 
jmarkfoleyAuthor Commented:
Here's an update: I also copied the kernel from my working machine to my new machine. It worked! I can read and write the DDS-4 tapes using the HP DAT-40 drive, and I can read DDS-3 tapes! So far so good.

The main difference between the working and non-working kernels was that the BusLogic driver was compiled into the working kernel, but was configured as a module on the non-working kernel. When I did a insmod BusLogic.o on the module-kernel, it also worked.

So, question 1: does modprobe just not find this adapter/driver? I suppose I might as well compile it into the kernel if I know what adapter and driver I need, but I would think this would be rather easy to find.

I then tried to use the Adaptec AHA-2944UW adapter. I tried compiling in all the configured Adaptec drivers one-by-one. None of them worked. The closest were the AIC7XXX driver and the Old Adaptec AIC7xxx. Their dmesg output is below.

So, Question 2: is there a driver that works for this adapter? The Buslogic bios is 1995 and the Adaptec is 1997, so I can't imagine that the card is too old. duncan_roe, you indicated you used aic7xxx for your Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01). Can the 2944UW really be that much different? I hate to go to the trouble of returning this Adaptec AND I'd like to put the Buslogic back in my main computer -- it can't do backups until I do.

dmesg for aic7xxx:

SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 3 for device 00:04.0
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec 2944 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

dmseg for old aic7xxx driver:

SCSI subsystem driver Revision: 1.00
Loading Adaptec I2O RAID: Version 2.4 Build 5
Detecting Adaptec I2O RAID controllers...
PCI: Found IRQ 3 for device 00:04.0
(scsi0) <Adaptec AHA-2944 Ultra SCSI host adapter> found at PCI 0/4/0
(scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs
(scsi0) Cables present (Int-50 NO, Int-68 YES, Ext-68 NO)
(scsi0) Downloading sequencer code... 436 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
       <Adaptec AHA-2944 Ultra SCSI host adapter>

dmesg for BusLogic adapter. Note that it actually finds the tape drive, unlike the Adaptec output above:

SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 3 for device 00:04.0
scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 *****
scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
scsi0:   Firmware Version: 5.07B, I/O Address: 0x2070, IRQ Channel: 3/Level
scsi0:   PCI Bus: 0, Device: 4, Address: 0x41000000, Host Adapter SCSI ID: 7
scsi0:   Parity Checking: Enabled, Extended Translation: Enabled
scsi0:   Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
scsi0:   Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
scsi0:   Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
scsi0:   Driver Queue Depth: 211, Host Adapter Queue Depth: 192
scsi0:   Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
scsi0:   Error Recovery Strategy: Default, SCSI Bus Reset: Enabled
scsi0:   SCSI Bus Termination: Both Enabled, SCAM: Enabled, Level 1
scsi0: *** BusLogic BT-958 Initialized Successfully ***
scsi0 : BusLogic BT-958
  Vendor: HP        Model: C5683A            Rev: C111
  Type:   Sequential-Access                  ANSI SCSI revision: 02
scsi0: Target 2: Queue Depth 3, Wide Synchronous at 40.0 MB/sec, offset 15
st: Version 20040102, bufsize 32768, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
0
 
jmarkfoleyAuthor Commented:
More Info: I was looking at other postings and found: http://www.experts-exchange.com/Hardware/Q_21221929.html?query=AHA+2944&clearTAFilter=true

The Adaptec website gives the specs for the 2944UW: http://www.adaptec.com/worldwide/support/techspecs.jsp?sess=no&language=English+US&cat=%2FProduct%2FAHA-2940UW&prodkey=AHA-2944UW

and the 2940UW: http://www.adaptec.com/worldwide/support/techspecs.jsp?sess=no&language=English+US&cat=%2FProduct%2FAHA-2940UW&prodkey=AHA-2940UW

It appears that the 2944 uses a voltage differential cable and the 2940 is single ended. So, perhaps the electrical connections are different and the 2944 can't possible work with the HP DataStore because it is 'normal' not differential. If any of you go back in time far enough, it might be analogous to the difference between RS-232 and RS-422. Same connector but single-voltage signal versus differential voltage. Case solved?

Any comments before I hand out points?
0
 
Duncan RoeSoftware DeveloperCommented:
Did you get the 'kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2' message even though you had uncommented the appropriate modprobe line in rc.modules? Unlike a live CD or install disk, a regular running system does not try to guess what card is installed. Putting lines in rc.modules should be as good as compiling-in (except for the boot device:)
Don't use insmod BTW, unless you have good reason - modprobe is much safer / more comprehensive / whatever.
It does seem that your Buslogic card can see the tape drive but your Adaptec card can't.
0
 
pjedmondCommented:
1.    Modprobe is not guaranteed to work 100%...- You need to add the relavent bit to modules.conf or equivalent in a similar manner to that outlined for the RH system above.

2.    I think from what you've said that you need the AIC79XX module NOT the AIC7XXX module. Try insmod once system is booted.

HTH:)
0
 
jmarkfoleyAuthor Commented:
Here's the wrap-up: I exchanged my 2944 card for a 2940 card. DONE! It worked just fine. I am copying DSS-3 tapes as I write.

The Adaptec card couldn't see the drive because the drive was configured as a 'normal' direct voltage cable connection and the 2944 is differential. To elaborate a bit more on what I believe this means: in the line-pairs in a 'normal' cable one line carried the signal voltage (usually +/- 12V) and the other line is ground. In a differential cable, one line pair carries +12V and the other carries -12V. When the signal changes, the polarity changes. You have, in effect a 24V differential instead of 12V which permits longer cable lengths and better noise attenuation (therefore more physical devices on the same cable).

I have no doubt that some of the HP SureStore switches let you choose interface type, but I really don't want to make this my life's work! Plus, I'd rather have the more common interface to permit swapping amongst machines.

pjedmond: I did use the AIC79XX driver. I had tried the old AIC7XXX driver which did see the tape drive, but it always ejected the tape after I inserted it. I didn't try the 'new' AIC7XXX driver ... AIC79XX worked so why bother.

duncan_roe: No, I never did try uncommenting the appropriate modprobe line in rc.modules. Frankly, I'd never used this before and I didn't quite "get it" when we started this conversation on Saturday. Now, I know more about this stuff than I ever dreamed! Nevertheless, I think I'm going to stick with compling the driver into the kernel. I'm sure there are some advantages to using the modules, but this card is probably going to stay in this computer until a better byte-per-dollar/byte per cu/inch storage medium comes along. I don't change drivers every boot, so I don't see the advantage to using rc.modules for me. But thanks for the guidance! At least now I know how to use it.

Thanks all
0

Featured Post

Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

  • 7
  • 7
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now