[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/dev/scsipi
Hi Erik !
I agree that 5 minutes is a really long time. Actually the inventory
wait even longer (5 min per element + 10 minutes as safeguard - I didn't
Generating a uprintf would mean to manage a separate callout and using,
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.
are used in automated environments. I am not looking at night at the
our changers, but I am really annoyed when work is being aborted because
of the scsi
timeout being too short.
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
operation times in the chio man page could help.
On 08/10/13 00:06, Erik Fair wrote:
On Aug 9, 2013, at 12:58 , Frank Kardel <kardel%netbsd.org@localhost> wrote:
Module Name: src
Committed By: kardel
Date: Fri Aug 9 19:58:44 UTC 2013
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
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.
Main Index |
Thread Index |