Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uwm.edu!cs.utexas.edu!sun-barr!ames!agate!tfs.com!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: New scsi system beta3 (part 8 of 10)
Message-ID: <1992Oct8.105206.29338@tfs.com>
Organization: TRW Financial Systems
References: <1992Oct3.040233.14002@tfs.com> <1992Oct7.082810.38@vtrm01.uucp>
Date: Thu, 8 Oct 1992 10:52:06 GMT
Lines: 92
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;
when you run on the BETA2 stuff, what is the dmesg
output in relation to the tape drive?
is it lun 0?
I changed a few things in the probe routines but
unfortunatly there's always some device that does something differently.
I can only suggest how i would go about finding the problem
and hope that you can do it. I am afraid I can't do it from here.
When you work out what the changes needed are, send me information and I wil
incorporate it into my masters for the next release.
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.
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.
when you get up and going, type 'dmesg' to examine it at your leasure.
send me a copy if you can and I'll try to work it out too.
if it is not lun0 then I know why it failed, I only test non 0 luns
if there is a device on the 0 lun for that device number.
let me know it that is the case, and I'll change it.
or you can make the change by removing the following code from scsi_attachdevs()
if((lun == 0) && (!bestmatch) && (!predef))
{
break; /* nothing here, skip to next targ */
}
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.
alternatively, if you don't want your tape to need to be turned on
at boot time you could hard wire it in at the top of scsiconf.c
in the structure array pd[]
add
#if NST > 0
{0,<tapes ID#>,<tapes LUN>,stattach,"st"},
/* define a tape at scsibus=0 dev=X lu=Y */
#endif
that way if your device is not ready it won't matter,
(for that matter it need not even be turned on).
I hope this get's you going.
+----------------------------------+ ______ _ __
| __--_|\ 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