On Sat, 10 Feb 2001, Alan Cox wrote:
> > and then issue a spin_lock again. Your UP system is likely to be very little
> > or
> > not responsive at all during the above process, but this is an unavoidable
> > price to
> > be paid in the last attempt to avoid a full system crash. Pls. note that in
>
> Well the driver isnt allowed to hold interrupts off for > 1 tick because
> that messes up the clock, and at 1 second the watchdog nmi will reboot
>
> scsi driver authors therefore need to adjust their drivers
What about this excerpt from scsi.c (2.4.1):
/*
* We will wait MIN_RESET_DELAY clock ticks after the last reset so
* we can avoid the drive not being ready.
*/
timeout = host->last_reset + MIN_RESET_DELAY;
if (host->resetting && time_before(jiffies, timeout)) {
int ticks_remaining = timeout - jiffies;
/*
* NOTE: This may be executed from within an interrupt
* handler! This is bad, but for now, it'll do. The irq
* level of the interrupt handler has been masked out by the
* platform dependent interrupt handling code already, so the
* sti() here will not cause another call to the SCSI host's
* interrupt handler (assuming there is one irq-level per
* host).
*/
while (--ticks_remaining >= 0)
mdelay(1 + 999 / HZ);
host->resetting = 0;
}
(MIN_RESET_DELAY = 2 seconds)
Btw, some SCSI subsystem may require some large settle delay after reset
for some stupid SCSI device to be ready to accept commands. Using a timer
in low level driver may lead to commands being timed-out by the generic
layer.
Btw2, Currently (2.4.1), the INQUIRY command use a timeout value of:
SCSI_TIMEOUT+4*HZ = 6 seconds.
At least for SCSI, it is the generic layer that must be adjusted by
handling properly a configurable settle delay after SCSI reset, especially
at SCSI BUS initialisation.
IMHO, most of hacks in device specific code are generally due to deficient
generic layers or improper platform specific code.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
