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. 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 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, I agree with this very much. Actually I have been toying around with this idea quite some time. My thoughts where to build a sysctl tree for all scsi commands with their default values and another level of sysctl timeout nodes where the vendor and device name or driver name is part of the hierarchy to override timeouts for some commands. Solaris has, I believe some of those knobs. So far I didn't manage to invest the time for a complete implementation. But maybe, as we currently are only suffering with changers, it would be sufficient to add a single timeout knob for the changers. Like dev.ch0.scsi_timeout=300 (s) How about that? Frank On 08/10/13 00:14, Erik Fair wrote: 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
Re: CVS commit: src/sys/dev/usb
On 8/10/13 2:15 PM, John Nemeth wrote: Module Name:src Committed By: jnemeth Date: Sat Aug 10 21:15:26 UTC 2013 Modified Files: src/sys/dev/usb: if_urtwn.c usbdevs usbdevs.h usbdevs_data.h Log Message: PR/48112 - Kai-Uwe Eckhardt -- add support for Sitecom N300 usb wifi adapter To generate a diff of this commit: cvs rdiff -u -r1.24 -r1.25 src/sys/dev/usb/if_urtwn.c cvs rdiff -u -r1.651 -r1.652 src/sys/dev/usb/usbdevs cvs rdiff -u -r1.643 -r1.644 src/sys/dev/usb/usbdevs.h cvs rdiff -u -r1.644 -r1.645 src/sys/dev/usb/usbdevs_data.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. When making changes to usbdevs (or pcidevs, or similar files), you should always commit the change *first*, then regenerate usbdevs.h and usbdevs_data.h, because they embed the version of usbdevs. Also, it makes for easier pullups. +j
