On Sun, Feb 21, 1999 at 02:30:21AM -0800, Matthew Jacob wrote:
>
> > Section 5.7 of the SCSI 2 spec mentions a value of 250ms for a hard reset to
> > selection time - but its only a recommendation.
> >
>
> I don't have my SCSI spec in front of me- this may simply be the
> propagation of the recommended selection timeout of 250ms - if initiators
> will wait up to 250ms then try and be ready before that time has elapsed.
> But there's no guarantee past SCSI bus reset whether a device will respond or
> not.
In my SCSI-2 draft (section 4.7, table 7) it says:
Power-On to Selection Time: 10 s recommended
Reset to Selection Time: 250 ms recommended
So, if the devices do comply with SCSI2 standard, it would be save to wait
only for 0.25s after a reset. However, some devices such as scanners or
CD-Rs tend tend to violate specs, resulting in the need to wait for a longer
time after a bus reset.
Now, my interest is in having a proper implementation for handling SCSI
resets. I could imagine something like this:
* Whoever issues or detects a SCSI RESET, should set last_reset (member of
Scsi_Host structure) to jiffies.
* Another variable delay_reset specifies how long to wait (this could be set
by the low-level driver or by the mid-level code, by error-handling or
whatever). Note that this way the delay after a reset would be a per
controller thing.
* The mid-level code does queue commands, but does not send them to the low
level driver, as long as time_before(jiffies,last_reset+delay_reset)
* The same holds for the low-level driver: It may have commands in it's own
queue, but those should not be sent as long as time_before(...).
* In order to start transfers after the delay_reset time is over, the
mid-level as well as the low-level code have to use timers, to be woken up.
Does this look like a reasonable design?
There are some issues with this approach:
* Timeouts: If a command has a timeout of 2 seconds and the bus has a
delay_reset time of 3 seconds, the command would time out, which might not
be the desired behaviour. It would be necessary to make sure that the
timing only starts, when the command is sent to the driver. For commands
already in the low-level queue this is hardly achievable. I don't know,
if the error handling code will react reasonably on situations like this.
* The waiting after a reset caused by the error handling code should be
integrated with this.
I'm not too familiar with mid-level SCSI code, but this looks like a
non-trivial thing to implement. Not a 2.2 project, it seems.
Who is developing mid-level code for 2.3?
--
Kurt Garloff <[EMAIL PROTECTED]> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
PGP signature
