Subject: Re: kern/7300: 'chio ielem' does not work well
To: None <gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org>
From: Kenneth D. Merry <ken@plutotech.com>
List: netbsd-bugs
Date: 04/02/1999 23:23:57
Greg A. Woods wrote...
> [ On Friday, April 2, 1999 at 10:56:28 (+0200), Manuel Bouyer wrote: ]
> > Subject: Re: kern/7300: 'chio ielem' does not work well
> >
> > How many time do you get between the command and the error ?
> > It's possible that the timeout value is too low (a single tape load
> > on my LXS library takes 90s, so I guess a 'chio ielem' on it would take
> > 90 * 15 = about 23 mn (I never tried chio ielem).
> > However I guess the default value should be enouth here, without the bug:
> > there is a '* 60' missing, meaning this makes a timeout of 5s per element,
> > instead of 5mn.
> 
> That would indeed appear to be the problem.  The timeout in 1.3.3 is a
> fixed 100 seconds -- definitely not long enough to load and unload 10
> tapes with a slow-as-molasses-in-Antarctica EXB-8505 drive.

FWIW, in the FreeBSD/CAM ch driver (which is based upon Jason Thorpe's ch
driver), we use a timeout of 500 seconds for initialize element status.
I'm not citing that as a canonical value or anything, but I haven't heard
much complaint lately about it.  I've got a borrowed Exabyte 10i changer
with an onboard 8500:

sa0 at ahc0 bus 0 target 4 lun 0
sa0: <EXABYTE EXB-8500-85Qanx0 0415> Removable Sequential Access SCSI-2 device 
sa0: 4.032MB/s transfers (4.032MHz, offset 11)
ch0 at ahc0 bus 0 target 3 lun 0
ch0: <EXABYTE EXB-10i 2.6> Removable Changer SCSI-2 device 
ch0: 3.300MB/s transfers
ch0: 10 slots, 1 drive, 1 picker, 0 portals

And it takes about 88 seconds to do a 'chio ielem':

# /usr/bin/time chio ielem
       87.91 real         0.00 user         0.00 sys

> > Here is a patch against 1.3I sources, the 1.3.3 should not be very different.
> 
> I'll try pulling in the new timeout calculation and add your fix for the
> bug....  This will at least give the machine time to do something, even
> if it doesn't do the right thing!  Thanks for pointing me at the
> problem, and the fix!  Here's hoping the library does the right thing too!


Ken
-- 
Kenneth Merry
ken@plutotech.com