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;drI'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 <kardel%netbsd.org@localhost> 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 <fair%netbsd.org@localhost>