Date: Mon, 29 Sep 1997 00:14:32 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-scsi@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: Possible ncr problem? Message-ID: <199709281414.AAA22430@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Basically, the IBM drives seem to dislike tagged commands when it >>comes to START STOP UNIT. Removing the scsi_start_unit() from >>sdopen() probably solves your (and my :) problem, but i didn't try so >>far. >> >>The upcoming CAM code is supposed to handle this situation better. > >If there is a rough hack that could be applied to 2.2.5, I think we should. >This problem is becoming more widespread (with the growing popularity of >NCR controllers and IBM disks) and the CAM code will not be here in time. Just don't call scsi_start_unit() if the device is already open. I first saw the problem using something like $ dd if=/dev/zero of=bigfile bs=1m count=20 $ "a program `fileblocks' which opens the raw device behind `bigfile' to determine the file blocks in `bigfile'" It is now obvious how this causes problems: there is a fair amount of i/o in progress when the dd finishes, and opening the raw device causes an scsi_start_unit() which does bad things to the i/o. BTW, shouldn't the device be locked just before scsi_test_unit_ready() instead of just after it? BTW2, locking of open() is still missing from all SCSI drivers except sd. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709281414.AAA22430>