lkml.org 
[lkml]   [2000]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2005-03-22 12:47    [W:0.092 / U:3.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site