Source-Changes-D archive

[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 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.

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.


On 08/10/13 00:06, Erik Fair wrote:
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
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 <>

Home | Main Index | Thread Index | Old Index