*BSD News Article 6310


Return to BSD News archive

Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!wsu-cs!vela!vtrm01.uucp!dcope
From: dcope@vtrm01.uucp
Newsgroups: comp.unix.bsd
Subject: Re: New scsi system beta3 (part 8 of 10)
Message-ID: <1992Oct9.155651.39@vtrm01.uucp>
Date: 9 Oct 92 15:56:51 EST
References: <1992Oct3.040233.14002@tfs.com> <1992Oct7.082810.38@vtrm01.uucp> <1992Oct8.105206.29338@tfs.com>
Organization: Vickers, Inc. - Troy, MI, USA
Lines: 83

In article <1992Oct8.105206.29338@tfs.com>, julian@tfs.com (Julian Elischer) writes:
> In article <1992Oct7.082810.38@vtrm01.uucp> dcope@vtrm01.uucp writes:
>>In article <1992Oct3.040233.14002@tfs.com>, julian@tfs.com (Julian Elischer) writes:
>>> # This archive contains:
>>> #
>>> #	i386/conf/SCSITEST
>>> #	i386/isa/aha1542.c
>>> #
>>  [ The jury is still out on the beta3 scsi release deleted]
>>The problem is it does not find my tape device during the probe for
>>devices, which makes the tape device unusable.
>> Granted it boots faster because it does not find any disk devices
>>but I still would like to use the tape.
>>I understand that a DEC TK50 may not be the best of tape devices but
>>for now it's all I've got.  BETA2 still in use here
>>
>>Don.
>>email address (vtrm01!dcope@vela.acs.oakland.edu)  it's faster
>>
> Sorry, this is the first I've heard of this problem;
> 
> is it lun 0?
yes
> 
> 1/ in scsiconf.c, in function scsi_attachdevs()
> change the loop that goes through the possible devices and luns to only
> do the device number and lun for the tape.
> 
I didn't try this I did the next one first

> 2/ at the beginning of that loop , set scsi_debug = 0xfff;
> at the end of it set it back to 0;
> 
> during boot, when the device is probed, there should be a TON of debugging.
> 
After a TON of debugging came out and the system came up I found that the tape
also came up.

> maybe your device is not ready because we are taking less time to get to it.
> (the probe is now faster).
> there is a delay in scsiconf.c 
> 
> #ifdef  KODAK_SCANNER
> 	printf("waiting for scsi devices to settle\n");
> 	spinwait(1000 * 30);
> #endif  KODAK_SCANNER
> 
> use this code with a 15 second (instead of 30) timeout and see it that
> gives your tape enough time to recover from the reset.
> 
This is what I did and found that the tape was always found -- so
I then changed the delay to 5.
This also found the tape all the time. -- so
I then chnaged it to 1.  
BETA3 is now used here.
Thanks very much. This is the result of dmesg with a 1sec delay.
--
pc0<mono> at 0x60 irq 1 on isa
com1 at 0x3f8 irq 4 on isa
com2 fifo at 0x2f8 irq 3 on isa
wd0 <st3144AT> at 0x1f0 irq 14 on isa
fd0 drives 0aha0 reading board settings, 150 nSEC ok, use 200 nSEC 
  **aha0 probing for scsi devices**
waiting for scsi devices to settle
  dev4,lu0: type 1(sequential),removable '' scsi1
	st0: scsi tape drive, 0 blocks of 0 bytes
aha0 at 0x330 irq 11 drq 5 on isa
we0 ethernet address 00:00:c0:e4:70:16 at 0x280 irq 9 on isa
lpt0 at 0x3bc irq 7 on isa
lpt1 at 0x378 irq 7 on isa
--
> +----------------------------------+       ______ _  __
> |   __--_|\  Julian Elischer       |       \     U \/ / On assignment
> |  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
> | (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
> +- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
>           v
> 
Thanks again.,
Don.
email (vtrm01!dcope@vela.acs.oakland.edu)