On Sun, 31 May 1998, Michael L. Hitch wrote:

> On May 30,  6:39pm, Chris Jones wrote:

>   Actually, the timeouts are specified on each command from the high-level
> device drivers (sd.c, st.c, and in this particular case, ch.c).  It looks
> like whoever wrote the initial ch.c driver arbitrarily used 100 seconds
> as the timeout.

Cool.  I changed the timeout in ch_ielem in dev/scsipi/ch.c to 300
seconds, which is plenty for my purposes.  It works fine now.

> > 2. Do something so that timeouts aren't an issue for the tape
> > changer.  I know this is really vague, but I don't understand the SCSI
> > system at all.  I'm just thinking that, if you had one of these with
> > 10 times as many slots, it would take about 10 times as long, and who
> > knows how large people are going to make changers in the future?
> 
>   Having run into timeout problems with a Wangtek 5150 drive, I wonder
> if maybe it might be worth adding information to the various "quirk"
> tables to specify different timeout values based on the actual device?

The only problem I see with that is that changers are very rare, and it
would be very nice if NetBSD could claim to support most changers out of
the box.  So, if they're rare enough that the developers can't test them
for necessary timeout values, there are going to be a lot that won't work
out of the box.  Many users aren't willing to submit bug reports; they'll
just say, "NetBSD's broken," and do something else.

Perhaps the default timeout for ielem should be about 10 minutes?  Or
maybe it should be based on the number of slots and drives?  Maybe
something like:

max(100, 20 * ( n_slots + n_pickers + n_drives + n_portals ))

Chris

P.S.:  This should probably be appended to by P.R., but I don't know the
address to CC: to in order to have that happen.  If somebody could do that
for me, I'd appreciate it.

-------------------------------------------------------------------------------
Chris Jones                                           cjones@math.montana.edu
           Mad scientist at large                     cjones@honors.montana.edu
"Is this going to be a stand-up programming session, sir, or another bug hunt?"