Re: scsipi mid-layer, tagged queueing, and ciss(4)

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

On Mon, 30 Aug 2010, Manuel Bouyer wrote:

> > I had thought about mentioning that as another option, since I had
> > actually tried that first, if I remember correctly.  That resulted
> > in a number of invalid command errors, with useless information.

  I switched back to patching the inquiry data, and didn't see any ciss(4)
messages during my initial testing unless I specifically ran scsictl or
dkctl to flush/sync the cache.  When I finally got to the point of 
mounting a wapbl filesystem rw, I started getting a number of them.  What 
I've done currently is supress that ciss(4) message for the 
SCSI_SYNCHRONIZE_CACHE_10 command.  That's the patch I'm going with for 
now.

  There's a comment in the code about emulating the SYNCHRONIZE_CACHE that 
came from the OpenBSD driver.  Looking through the FreeBSD driver, they 
originally were issuing a controller flush command, but it has been 
disabled with a commit message about it hanging the controller.  That 
command isn't in any documentation that I have found, and I don't quite 
understand the way OpenBSD driver is using it.  The cissreg.h file shows a 
CISS_FLUSH_ENABLE and CISS_FLUSH_DISABLE code passed by the command, and 
the OpenBSD/NetBSD driver is setting the CISS_FLUSH_DISABLE code when it 
does a shutdown.  From what I can tell with the FreeBSD and Linux drivers, 
they are using CISS_FLUSH_ENABLE when shutting down.  So I'm not sure if 
we are getting the controller cache flushed properly on shutdown at the 
moment.

--
Michael L. Hitch                        mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University        Bozeman, MT     USA