Re: CVS commit: src/sys/dev/scsipi

[Erik Fair]

On Aug 9, 2013, at 12:58 , Frank Kardel  wrote:

> Module Name:  src
> Committed By: kardel
> Date: Fri Aug  9 19:58:44 UTC 2013
> 
> Modified Files:
>   src/sys/dev/scsipi: ch.c
> 
> Log Message:
> bump command timeout to 5 minutes. several
> types of changers (Overland PowerLoader, Dell
> PowerVault) have been exceeding the 100 sec
> limit aborting a perfectly (slowly) progressing
> operation.

Upon further reflection, I believe that this timeout value should be a 
device-specific tunable parameter because there is such wide variation in 
changer behavior/performance; perhaps by kernel config, or by sysctl(8) on a 
per-device-node basis. Or some other mechanism you prefer.

I believe that baking it into the kernel as a constant is not good design 
because we'll just see another commit just like this one at some later date, 
continuing to patch around the design problem.

Erik 

Re: CVS commit: src/sys/dev/scsipi

[Erik Fair]

On Aug 9, 2013, at 12:58 , Frank Kardel  wrote:

> Module Name:  src
> Committed By: kardel
> Date: Fri Aug  9 19:58:44 UTC 2013
> 
> Modified Files:
>   src/sys/dev/scsipi: ch.c
> 
> Log Message:
> bump command timeout to 5 minutes. several
> types of changers (Overland PowerLoader, Dell
> PowerVault) have been exceeding the 100 sec
> limit aborting a perfectly (slowly) progressing
> operation.

I think the kernel should uprintf(9) a notice to the effect that it has 
exceeded some (sooner than the 5 minute timeout) threshold and that it's really 
waiting for the device. Five minutes is a very long time for a timeout 
involving nominally local I/O devices. Without some progress indicator, users 
are likely to begin beating the system up (power cycle, etc) absent some 
persuasion to be patient.

Erik