[4654] in linux-scsi channel archive
Re: Archive Python DAT DDS-1 tape drive with recent Linux NCR53C8XX driver
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Fri Sep 4 15:33:30 1998
Date: Fri, 4 Sep 1998 20:35:22 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Michael Meissner <meissner@cygnus.com>
cc: linux-kernel@vger.rutgers.edu, linux-scsi@vger.rutgers.edu,
ncr53c810@Colorado.EDU
In-Reply-To: <199809040311.XAA01021@wogglebug.cygnus.com>
On Thu, 3 Sep 1998, Michael Meissner wrote:
> (this is being sent to the scsi groups as well as the kernel groups,
> please adjust replies accordingly).
>
> I've been struggling with recent linux kernels and my Archive Python
> DAT DDS-1 tape drives. I have two computers, each equipped with 3
> year old Archive Python DAT DDS-1 tape drives.
>
> The work computer (tiktok) originally looked like:
>
> computer
> |
> +--- TekRam 390F (Symbios 53c875 based UW controller)
> | |
> | +---- (external 68) ---- wide disk ---- active terminator
> | |
> | +---- (internal 50) -- disk -- disk -- active termiator
> |
> +--- TekRam 390U (Symbios 53c875 based Ultra controller)
> |
> +---- (internal 50) -- tape -- cdrom w/passive term.
>
> I discovered that versions of Linux with the 3.0 scsi driver installed
> would continually reset the scsi bus when the first tape action (a
> rewind, even though the tape usually sits at the beginning of tape).
> The tape was originally set to SCSI-1 and no Parity via the jumpers.
> Linux versions 2.1.105 and before worked fine with this setup and the
> one below.
>
> In the course of rearranging the computer to move the two disks to an
> external enclose and add a removable hard drive, I also played around
> with the tape. I discovered that if I redid the cables for the tape,
> switched to use active termination instead of passive termination, and
> switched it to Scsi-2/Parity, it suddently started working again with
> 3.0g driver. Here is the current configuration:
Hmmm ....
As the driver does, I do prefer a LOT the new SCSI BUS configuration of
your system. ;-)
There is some different default set-up in the new driver version, for
example the NVRAM reading is now enabled and was disabled by default in
previous version.
[ ncr53c875-0: Tekram format NVRAM, ID 7, Fast-20, Parity Checking ]
Could you check the device user setup of your controller. For example,
SCSI disconnections _must_ be enabled for the tape.
> computer
> |
> +--- TekRam 390F (Symbios 53c875 based UW controller)
> | |
> | +---- (external 68) --- wide disk --- 2 narrow disks -- active term.
> |
> +--- TekRam 390U (Symbios 53c875 based Ultra controller)
> |
> +---- (internal 50) -- cdrom --- active terminator.
> |
> +---- (external 50) -- disk --- tape --- active terminator.
>
> Unfortunately, I was not so lucky with the home computer. The home
> computer (wogglebug) orgiinally looked like this:
>
> computer
> |
> +--- TekRam 390F (Symbios 53c875 based UW controller)
> |
> +--- (internal 50) -- disk -- tape -- cdrom w/passive terminator
>
> I recently added a second disk and connected it as follows:
>
> computer
> |
> +--- TekRam 390F (Symbios 53c875 based UW controller)
> |
> +--- (internal 68) -- disk -- disk -- active terminator
> |
> +--- (internal 50) -- tape -- cdrom -- active terminator
>
> and switched the tape to Scsi-2/Parity as in the work computer. If I
> used linux 2.1.105 (ncr 2.5f driver), it worked correctly.
Could you have a look at the boot-up messages and check if 2.5f
detects the NVRAM as 3.0g does. Here is the corresponding message:
[ ncr53c875-0: Tekram format NVRAM, ID 7, Fast-20, Parity Checking ]
You also could give driver 2.5f a try under pre-2.1.120-3. Just have
to move driver files from 2.1.105 and make a kernel.
> If I used a newer version such as 2.1.120_pre3 with the 3.0g version
> of the driver, it hung when I accessed the tape. I borrowed an
> Adaptec 2940UW from work, and determined it too didn't like the
> Archives (though the latest beta drivers do support the drives
[ ... ]
> at did a mt rewind command. The scsi activity light went on and
> stayed on. After awhile with nothing happened, I accessed the cdrom,
This means that the driver did'nt go to WAIT RESELECT and so that the
SCSI BUS was busy. Could be a hangup or just the tape that does not
want to disconnect the BUS.
> Sep 3 22:24:20 wogglebug login[714]: ROOT LOGIN ON tty1
> Sep 3 22:24:37 wogglebug kernel: ncr53c875-0-<2,*>: asynchronous.
This messages means that the tape reported SYNC features from INQUIRY
and just refused the negotiation. If the tape did'nt reported SYNC, the
driver 3.0g should have printed out:
SYNC transfers not supported.
What a strange SCSI device!
> Sep 3 22:27:08 wogglebug PAM_pwdb[715]: (login) session opened for user root by (uid=0)
> Sep 3 22:27:08 wogglebug login[715]: ROOT LOGIN ON tty2
> Sep 3 22:28:10 wogglebug automount[607]: attempting to mount entry /mnt/cdrom
> Sep 3 22:28:40 wogglebug kernel: scsi : aborting command due to timeout : pid 4342, scsi1, channel 0, id 4, lun 0 Test Unit Ready 00 00 00 00 00
> Sep 3 22:28:40 wogglebug kernel: ncr53c8xx_abort: pid=4342 serial_number=4369 serial_number_at_timeout=4369
40-10 = 30 seconds = SR (CD/ROM) driver timeouts.
Bus hang or tape that does not disconnect. Note that the both situations
do not make difference with regards to SCSI BUS signalling.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
