Hi Erik !
I agree that 5 minutes is a really long time. Actually the inventory
command will
wait even longer (5 min per element + 10 minutes as safeguard - I didn't
change that).
Generating a uprintf would mean to manage a separate callout and using,
I believe,
the tprintf() call from the callout function.
I am not sure whether that is worth the trouble. What timeout should we
take for the
uprintf ? People with a slow device with a waiting indicator every 10
seconds will not gain
any additional information other that they happen to have a slow device.
Mostly changers
are used in automated environments. I am not looking at night at the
operations of
our changers, but I am really annoyed when work is being aborted because
of the scsi
timeout being too short.
tl;dr
I'd prefer not to add 'interactive experience' support to the kernel,
Maybe someone can wip
up some tools(commands) for interactive usage. Maybe a warning about
possible long
operation times in the chio man page could help.
Frank
On 08/10/13 00:06, Erik Fair wrote:
On Aug 9, 2013, at 12:58 , Frank Kardel <[email protected]> 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 <[email protected]>
