On Mon, Nov 27, 2000 at 08:57:03AM +0100, Matthias Andree wrote:
> Good thing first: I can't trigger the oopses with 2.0e6. I tried hard, didn't
> manage to.
Nice to learn.
> However, trying to trigger a race condition, I found that your script suffers
> from too small a kernel API in this place, since it uses the
> remove-single-device and all-single-devices in a non-locked manner, so if you
> run several instances of your script in parallel (simple rescan-scsi-bus.sh -r
> & will do) it will give a mess and may leave you with missing devices.
>
> I don't currently recall if your web site states that your script may only be
> run once at the same time; lock files would be nice :-]
Well, it's one of these root-only admin tools.
I assume, root knows about what (s)he's doing.
So, I'll add some line to the documentation that tells you not to run the
scripts in parallel. Locking is really overkill, IMHO.
> A subsequent rescan-scsi-bus.sh will find the PX-32TS and add it, this time,
> without bus resets and aborts.
>
> Should the reset->inquiry delay be applied after ANY reset? Is it actually
> applied but too short for my Plextor?
Well, the default for tmscsim is 1.5s time after a reset before it start
command processing again. This can be changed by echoing DelayReset values tp
the proc file. If your Plextor requires 5s, just do
echo "delayreset 5" >/proc/scsi/tmscsim/? and the driver will wait for 5.5s
...
Regards,
-- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:17 EST