Red Hat Bugzilla – Bug 68883
sd_init_onedisk() waits approximately 100 seconds for passive-mode device to spin up.
Last modified: 2007-04-18 12:44:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Description of problem:
Filing on behalf of Ed Goggin:
sd_init_onedisk() waits approximately 100 seconds for each clariion passive-
mode device to spin up when the device's driver is loading. Since these
passive-mode devices are non-responsive to the
START_STOP SCSI message used to spin up non-removable media, the delay is
Would it be possible to decrease this delay in such a way that while
active/passive disk arrays like CLARiiON will not be impacted by needless
delays, the delays will still be beneficial for JBOD.
Please note that this is an issue with all RedHat v2.4.x releases.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Attach to the CLARiiON array that has passive-mode devices and boot up your
Linux host. The host will attempt to spin up each individual passive mode
device. For instance, with the 100 second delay for each passive I/O path, a
linux configuration with 128 scsi disk devices, 64 of which are passive, will
incur a 1 hour 46 minute delay on bootup.
which driver is in use here ?
qLogic driver v4.47.8, v4.47.11, v4.47.15 is being used. This also occurs with
Emulex driver v4.20l.
Does this happen with a driver that Red Hat actually supports ?
(eg the qla2200 driver from 2.4.19-34 or 2.4.18-5?)
Emulex is very unsupported (binary only) and the 4.x qlogic drivers are also
rather broken; please try 5.31RH.
I tried loading the v5.31RH driver and the behavior was the same. It is in the
sd.c, not the FC driver itself. Is there any way the sd_init_onedisk() 100
second delay can be decreased? Thanks.
Created attachment 67264 [details]
Proposed patch by Matt Domsch
Very sensible patch, I'll make sure the upstream notices.
Thank you....the attention to this is appreciated.
Larry Troan suggested this patch was be re-considered for Milan and may have to
be changed. I wanted to know if this would impact this patch into a Pensacola
errata (see bug 69956) or if the two releases could have the same fix in two