[7] in linux-scsi channel archive
Upcoming changes in 1.1.76 (fwd)
daemon@ATHENA.MIT.EDU (Paul Gortmaker)
Mon Jan 2 02:43:42 1995
From: Paul Gortmaker <paul@rasty.anu.edu.au>
To: linux-scsi@vger.rutgers.edu
Date: Mon, 2 Jan 1995 18:15:05 +1000 (EST)
This seemed important enough to be seen here on the new lists. Sorry
if you see it twice.
Paul.
Forwarded message:
> From owner-linux-activists@niksula.hut.fi Mon Jan 2 04:35:23 1995
> From: "Linux Activists" <linux-activists@niksula.hut.fi>
> To: "Linux-Activists" <linux-activists@niksula.hut.fi>
> Reply-To: "Linux-Activists" <linux-activists@niksula.hut.fi>
> X-Note1: Remember to put 'X-Mn-Key: SCSI' to your mail body or header
> Subject: Linux-Activists - SCSI Channel digest. 95-0-2-0:21
> X-Mn-Key: SCSI
> Sender: owner-linux-activists@niksula.hut.fi
> Message-Id: <95Jan2.063534eet.59788-2@niksula.hut.fi>
> Date: Mon, 2 Jan 1995 06:35:23 +0200
>
>
> Topics:
> Upcoming changes in 1.1.76.
>
>
> ----------------------------------------------------------------------
>
> From: eric@aib.com (Eric Youngdale)
> Subject: Upcoming changes in 1.1.76.
> Date: Sun, 1 Jan 95 18:48 EST
>
>
>
> Someone reported a problem in the scsi code that was the result of
> using cli/sti to control interrupts. The problem was that the function with
> the cli/sti was in fact called with interrupts turned off, and using sti() when
> we leave the critical section of code is not the right thing to do. In nearly
> every case instead of using sti() to enable interrupts again, you instead want
> to set the state of this back to what it was prior to the matching cli(). The
> code to do this is really quite trivial, and the resulting code looks something
> like:
>
> unsigned long flags;
>
> save_flags(flags); /* Save the current state here... */
> cli();
> /* ... */
> restore_flags(flags); /* Use this instead of sti() */
>
> I changed all of the mid-level and top-level scsi code, and I changed some of
> the low-level scsi drivers, but not all. The low-level drivers that I fixed
> were the aha1542.c, aha1740.c, in2000, and buslogic. Some of the others
> do not require any attention - the ones that remain that still need
> work are NCR5380.c, aha152xc, eata.c, fdomain.c, qlogic.c, u14-34f.c.
> I determined this list by doing a "grep 'sti()' *.c".
>
> Note that in some cases sti() is the correct thing to do - if you are
> about to do a sleep or something, then it probably is the right thing to do,
> but in general the queuecommand and interrupt handlers for all low level
> drivers should probably use the save/restore state functions instead. If in
> fact sti() is the correct thing to do, it would be helpful to do it like this:
>
> sti(); /* Yes, we really want sti() here */
>
> This way I could grep the entire sources and know which ones are correct and
> which ones are not.
>
> I could do the remaining drivers, I suppose, but I was trying to fix
> a specific problem for a specific user, and I was being a bit lazy. If nobody
> else fixes these anytime soon, I will probably come up with some more patches
> to fix the rest.
>
> -Eric
>
>
> ------------------------------
>
> End of SCSI Digest
> ******************
> -------
