Professional Web Applications Themes

Problem reading tape in SCO 5.0.7 - SCO

I have installed SCO 5.0.7 on a Pentium 4-2.4GHZ with 1GB mem, Raid 5 Adaptec 2100S controller with 4-18GB hard drives, Adaptec 2940AU controller for the tape drive, Dell OEM (Seagate STD224000N) tape drive. When I read a tape using (tar -tv8) it will get part of the way through the read and fail. After trying this several times the failure is at different places on the tape. The tape has been verified good on another machine and tape drive. I have tried two different 2940 controllers with the same results. Has anyone had a problem with the Adaptec 2940 ...

  1. #1

    Default Problem reading tape in SCO 5.0.7

    I have installed SCO 5.0.7 on a Pentium 4-2.4GHZ with 1GB mem, Raid 5
    Adaptec 2100S controller with 4-18GB hard drives, Adaptec 2940AU
    controller for the tape drive, Dell OEM (Seagate STD224000N) tape
    drive. When I read a tape using (tar -tv8) it will get part of the
    way through the read and fail. After trying this several times the
    failure is at different places on the tape. The tape has been
    verified good on another machine and tape drive. I have tried two
    different 2940 controllers with the same results. Has anyone had a
    problem with the Adaptec 2940 controllers and Pentium 4 processors? I
    have not ruled out that it is the tape drive that I am using. Any
    thoughts or suggestions would be appreciated.
    Kevin Harris Guest

  2. #2

    Default Re: Problem reading tape in SCO 5.0.7

    Kevin Harris typed (on Wed, Jul 02, 2003 at 08:44:18AM -0700):
    | I have installed SCO 5.0.7 on a Pentium 4-2.4GHZ with 1GB mem, Raid 5
    | Adaptec 2100S controller with 4-18GB hard drives, Adaptec 2940AU
    | controller for the tape drive, Dell OEM (Seagate STD224000N) tape
    | drive. When I read a tape using (tar -tv8) it will get part of the
    | way through the read and fail. After trying this several times the
    | failure is at different places on the tape. The tape has been
    | verified good on another machine and tape drive. I have tried two
    | different 2940 controllers with the same results. Has anyone had a
    | problem with the Adaptec 2940 controllers and Pentium 4 processors? I
    | have not ruled out that it is the tape drive that I am using. Any
    | thoughts or suggestions would be appreciated.

    Usually when this happens there is a mismatch with either the tape block
    factor or the low level scsi block size of the tape drive.

    Check the scsi block size on each system with:

    # tape getblk

    If they are different, change the scsi block scsi of the tape on the system
    which you would like to read the tape on:

    # tape -a "blocksize" setblk

    Also check file file /etc/default/tar and make sure the block factor
    in the line "archive8" matches that of the system where the tape was created.

    --
    Best Regards,
    Eric Nicholson - [email]ericcactus.com[/email]
    .--.
    __________________________ .-. | | _____________________________________
    Lone Star Software Corp. | | | | .-. Home of World Famous LONE-TAR(tm)
    Cactus International, Inc. | |_| | | | Backup Software for UNIX and LINUX
    Sales: 800.525.8649 _ |___ |_| | 24x7 Support Available
    Support: 301.829.1622 _| ~- | ___| RESCUE-RANGER(tm) and AIR-BAG(tm)
    [url]http://www.LONE-TAR.com[/url] \, _} | | Disaster Recovery Software
    -------------------------- \( -- | | --------------------------------------
    | |
    Eric Nicholson (NewsGroup) Guest

  3. #3

    Default Re: Problem reading tape in SCO 5.0.7

    "Eric Nicholson (NewsGroup)" <ericncactus.com> wrote in message news:<20030702181043.GA29434lonestar.cactus.com>. ..
    > Kevin Harris typed (on Wed, Jul 02, 2003 at 08:44:18AM -0700):
    > | I have installed SCO 5.0.7 on a Pentium 4-2.4GHZ with 1GB mem, Raid 5
    > | Adaptec 2100S controller with 4-18GB hard drives, Adaptec 2940AU
    > | controller for the tape drive, Dell OEM (Seagate STD224000N) tape
    > | drive. When I read a tape using (tar -tv8) it will get part of the
    > | way through the read and fail. After trying this several times the
    > | failure is at different places on the tape. The tape has been
    > | verified good on another machine and tape drive. I have tried two
    > | different 2940 controllers with the same results. Has anyone had a
    > | problem with the Adaptec 2940 controllers and Pentium 4 processors? I
    > | have not ruled out that it is the tape drive that I am using. Any
    > | thoughts or suggestions would be appreciated.
    >
    > Usually when this happens there is a mismatch with either the tape block
    > factor or the low level scsi block size of the tape drive.
    >
    > Check the scsi block size on each system with:
    >
    > # tape getblk
    >
    > If they are different, change the scsi block scsi of the tape on the system
    > which you would like to read the tape on:
    >
    > # tape -a "blocksize" setblk
    >
    > Also check file file /etc/default/tar and make sure the block factor
    > in the line "archive8" matches that of the system where the tape was created.
    >
    > --
    > Best Regards,
    > Eric Nicholson - [email]ericcactus.com[/email]
    As a followup to the above posts let me elaborate on what has been
    done since these were posted. The system is a Pentium 4 2.0Ghz w/
    Adaptec 2100S Raid controller, 1GB memory, Archive Python 4106 12/24GB
    DAT tape drive, and 4-18GB hard drives. For the tape drive we have
    tried four SCSI controllers: Adaptec's AHA-2940AU & AHA-2940U, Symbios
    53C8XX, and Tekram's DC-3051E PCI SCSI controllers. I have been able
    to install SCO Openserver 5.0.7 and 5.0.6 on the system. It is
    currently configured with 5.0.6. For the Symbios and Tekram
    controllers, once I install the drivers and the tape drive, Lone Tar
    will fail a read and the tar command will return a blocksize = 0. The
    Adaptec controllers will partially read the tape and will fail at
    various places on the tape giving me the following error:

    tar: tape read error
    read: No such device or address

    I have taken the tape drive to the system this one is replacing (AMD
    K3) and it reads the tape fine on an Adaptec 2940 Ultra/Ultra Wide. I
    have checked the scsi block size and they are 512 in both systems.
    Also the archive 8 matches in both systems. It is terminated properly
    and it is the only device on the chain. It will allow me to read a
    DDS-1 tape that it has written.

    My plan was to set up the system remotely, restore the backup using
    the Lone Tar software, upgrade the O/S from 5.0.5 to 5.0.7 and setup
    any new hardware in the system and remove all the old hardware and
    drivers. It appears that with these problems my only solution is to
    connect the system to the network and move data across to the new
    system after all the programs are reinstalled. Could this problem be
    resolved by replacing the controllers with something new? Does anyone
    have any suggestions for a controller to replace these with, so that I
    can get this system finished?
    Rod Caddy Guest

  4. #4

    Default Re: Problem reading tape in SCO 5.0.7


    "Rod Caddy" <rcaddypro-set.com> wrote in message
    news:1edf0abe.0307090908.23461eafposting.google.c om...
    > "Eric Nicholson (NewsGroup)" <ericncactus.com> wrote in message
    news:<20030702181043.GA29434lonestar.cactus.com>. ..
    > > Kevin Harris typed (on Wed, Jul 02, 2003 at 08:44:18AM -0700):
    > > | I have installed SCO 5.0.7 on a Pentium 4-2.4GHZ with 1GB mem, Raid 5
    > > | Adaptec 2100S controller with 4-18GB hard drives, Adaptec 2940AU
    > > | controller for the tape drive, Dell OEM (Seagate STD224000N) tape
    > > | drive. When I read a tape using (tar -tv8) it will get part of the
    > > | way through the read and fail. After trying this several times the
    > > | failure is at different places on the tape. The tape has been
    > > | verified good on another machine and tape drive. I have tried two
    > > | different 2940 controllers with the same results. Has anyone had a
    > > | problem with the Adaptec 2940 controllers and Pentium 4 processors? I
    > > | have not ruled out that it is the tape drive that I am using. Any
    > > | thoughts or suggestions would be appreciated.
    > >
    > > Usually when this happens there is a mismatch with either the tape block
    > > factor or the low level scsi block size of the tape drive.
    > >
    > > Check the scsi block size on each system with:
    > >
    > > # tape getblk
    > >
    > > If they are different, change the scsi block scsi of the tape on the
    system
    > > which you would like to read the tape on:
    > >
    > > # tape -a "blocksize" setblk
    > >
    > > Also check file file /etc/default/tar and make sure the block factor
    > > in the line "archive8" matches that of the system where the tape was
    created.
    > >
    > > --
    > > Best Regards,
    > > Eric Nicholson - [email]ericcactus.com[/email]
    >
    > As a followup to the above posts let me elaborate on what has been
    > done since these were posted. The system is a Pentium 4 2.0Ghz w/
    > Adaptec 2100S Raid controller, 1GB memory, Archive Python 4106 12/24GB
    > DAT tape drive, and 4-18GB hard drives. For the tape drive we have
    > tried four SCSI controllers: Adaptec's AHA-2940AU & AHA-2940U, Symbios
    > 53C8XX, and Tekram's DC-3051E PCI SCSI controllers. I have been able
    > to install SCO Openserver 5.0.7 and 5.0.6 on the system. It is
    > currently configured with 5.0.6. For the Symbios and Tekram
    > controllers, once I install the drivers and the tape drive, Lone Tar
    > will fail a read and the tar command will return a blocksize = 0. The
    > Adaptec controllers will partially read the tape and will fail at
    > various places on the tape giving me the following error:
    >
    > tar: tape read error
    > read: No such device or address
    >
    > I have taken the tape drive to the system this one is replacing (AMD
    > K3) and it reads the tape fine on an Adaptec 2940 Ultra/Ultra Wide. I
    > have checked the scsi block size and they are 512 in both systems.
    > Also the archive 8 matches in both systems. It is terminated properly
    > and it is the only device on the chain. It will allow me to read a
    > DDS-1 tape that it has written.
    >
    > My plan was to set up the system remotely, restore the backup using
    > the Lone Tar software, upgrade the O/S from 5.0.5 to 5.0.7 and setup
    > any new hardware in the system and remove all the old hardware and
    > drivers. It appears that with these problems my only solution is to
    > connect the system to the network and move data across to the new
    > system after all the programs are reinstalled. Could this problem be
    > resolved by replacing the controllers with something new? Does anyone
    > have any suggestions for a controller to replace these with, so that I
    > can get this system finished?
    1. Can you insert a blank tape on the new system, regardless of which
    controller is being used, and do a full bit-level verified backup using
    Lone-Tar?
    (Don't even bother with tar or cpio, please.) If you can, then there's
    nothing basically wrong with your tape drive and controller. Please
    make sure you're using a blank tape; if not, pop in the tape and issue
    the command: tape wfm
    to essentially erase it.
    As an extra check, remove the tape, re-insert it and do another bit-level
    verify (only) of the tape.

    2. Remove the tape drive and check the DIP switches on the bottom.
    For SCO, switches 9 & 10 should be off.

    3. Check the Lone-Tar tape configuration on each system to see
    that both systems are using the same settings for compression,
    blocksize and hardware blocksize. I have always used hardware
    blocksize of zero (variable blocksize), not the tape drive default
    of 512.

    4. Is the tape drive configured identically in the SCSI controllers'
    BIOS? Synch negotiation, disconnect, bus speed, etc.

    5. Check mkdev tape on each system to ensure that both drives
    are configured as SCSI DAT drives.


    Bob Bailin Guest

  5. #5

    Default Re: Problem reading tape in SCO 5.0.7

    I had a similar issue with 5.0.7 & 5.0.6. Seagate suggested they had
    success on some systems changing the scsi controller to a slower speed
    so the tape could handle it. They specifically mentioned success with
    Adaptec cards/controllers and setting the controller slower than what
    the tape was designed to handle.
    Jeff P Guest

  6. #6

    Default Re: Problem reading tape in SCO 5.0.7

    Jeff P typed (on Fri, Jul 11, 2003 at 10:43:36AM -0700):
    | I had a similar issue with 5.0.7 & 5.0.6. Seagate suggested they had
    | success on some systems changing the scsi controller to a slower speed
    | so the tape could handle it. They specifically mentioned success with
    | Adaptec cards/controllers and setting the controller slower than what
    | the tape was designed to handle.

    Similar to what?

    Please don't post such a "dangling-in-space" message. Do quote something
    from the message to which you are replying. My memory, and I presume
    that of others, is unlikely to connect your thoughts to what went before,
    so provide a hint.

    --
    JP
    Jean-Pierre Radley Guest

  7. #7

    Default Re: Problem reading tape in SCO 5.0.7

    > 1. Can you insert a blank tape on the new system, regardless of which
    > controller is being used, and do a full bit-level verified backup using
    > Lone-Tar?
    > (Don't even bother with tar or cpio, please.) If you can, then there's
    > nothing basically wrong with your tape drive and controller. Please
    > make sure you're using a blank tape; if not, pop in the tape and issue
    > the command: tape wfm
    > to essentially erase it.
    > As an extra check, remove the tape, re-insert it and do another bit-level
    > verify (only) of the tape.
    We can do a full backup and verify to a new tape (formatted or
    otherwise). The problem comes from reading a backup of the old system.
    And yes we have checked the /etc/default/tar file and run tape getblk.
    Everything appears to be setup exactly the same.

    I think we are down to hooking up the new machine to the network with
    the old server and moving files across.
    > 2. Remove the tape drive and check the DIP switches on the bottom.
    > For SCO, switches 9 & 10 should be off.
    DIP switches 9& 10 are off
    > 3. Check the Lone-Tar tape configuration on each system to see
    > that both systems are using the same settings for compression,
    > blocksize and hardware blocksize. I have always used hardware
    > blocksize of zero (variable blocksize), not the tape drive default
    > of 512.

    yes checked this
    > 4. Is the tape drive configured identically in the SCSI controllers'
    > BIOS? Synch negotiation, disconnect, bus speed, etc.
    yes
    > 5. Check mkdev tape on each system to ensure that both drives
    > are configured as SCSI DAT drives.
    yes
    Kevin Harris Guest

Similar Threads

  1. Problem with Seagate/IBM DDS-3 tape drive.
    By Dr. David Kirkby in forum AIX
    Replies: 8
    Last Post: August 12th, 07:01 PM
  2. Problem communicating with AIT tape drive.
    By Peter Cattaneo in forum Linux / Unix Administration
    Replies: 9
    Last Post: July 25th, 01:24 PM
  3. AW: DLT tape problem
    By Yildiz, Murat in forum Debian
    Replies: 0
    Last Post: July 16th, 07:40 AM
  4. DLT tape problem
    By Yildiz, Murat in forum Debian
    Replies: 1
    Last Post: July 14th, 08:00 AM
  5. Root password 2 times and Tape problem
    By Yildiz, Murat in forum Debian
    Replies: 1
    Last Post: July 7th, 07:50 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139