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

[Erik Fair]

On Aug 9, 2013, at 12:58 , Frank Kardel kar...@netbsd.org 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 f...@netbsd.org

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

[Erik Fair]

On Aug 9, 2013, at 12:58 , Frank Kardel kar...@netbsd.org 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 f...@netbsd.org