Messages in this thread |  | | Date | Mon, 27 Nov 2000 15:22:50 +0100 | From | Kurt Garloff <> | Subject | Re: [2.2.17] oops in /proc/scsi/scsi |
| |
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 [unhandled content-type:application/pgp-signature] |  |