From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 15:18:16 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C485F16A401; Fri, 2 Feb 2007 15:18:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7968C13C4A6; Fri, 2 Feb 2007 15:18:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l12FI91x003091; Fri, 2 Feb 2007 08:18:14 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45C35622.5090504@samsco.org> Date: Fri, 02 Feb 2007 08:17:54 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Nate Lawson References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> In-Reply-To: <45C2E7DB.30204@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 02 Feb 2007 08:18:15 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: mjacob@freebsd.org, scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 15:18:16 -0000 Nate Lawson wrote: > Scott Long wrote: >> mjacob@freebsd.org wrote: >>>> >>>> umass should probably just disable the SYNC_CACHE commands from CAM, >>>> as well as whatever other commands are always quirked. The firewire >>>> SIM >>>> should probably do the same. >>>> >>> >>> Err, probably should be XPORT based? >> >> Ah, very true. Taking that a step further, there should probably be a >> broader concept of RBC and/or MMC as opposed to the assumption that >> everything is SBC. >> >> Scott > > I have some experience with that (see the NO_6_BYTE sim option I added > for usb and firewire). Of course, that was a hack and should be a XPORT > setting as you point out. > > However, I don't think the umass situation is the same. That's why I > haven't acted on it yet. The issue is that SYNC_CACHE is a perfectly > valid RBC command. Some devices support it and it works (50% of flash > drives my guess), some reject it but continue processing commands (25% > maybe), and some hang after receiving it (10-25%). Obviously, the type > of device determines whether it's more likely to support this or not > (usb hard drive, almost certainly; mp3 player, probably not). > > For the devices that hang, I have a strong suspicion that their firmware > state machine looks like this: > case SYNC_CACHE: > OptionallyWriteData(); > while (1); // wait for detach > > Florent Thoumie (flz@) started some work based on some evidence that > Linux checks a "write cache present" bit in the INQUIRY data and decides > whether or not to run SYNC_CACHE based on that. It's unknown yet how > closely this bit correlates with the hanging behavior though. > > I think Windows actually never runs SYNC_CACHE unless you select "detach > device". So if we added the capability for a device_eject() newbus > method and the default implementation ran device_shutdown(), then > scsi_da(4) could run SYNC_CACHE only from its shutdown method and thus > it wouldn't matter if the device hung from it. Right now, we run > SYNC_CACHE from daclose() and so umounting the drive is enough to cause > a hang, and the hangs on boot are from GEOM tasting the drive > (daopen/daclose). With this change, a device could be plugged in and > mounted/umounted multiple times. Only when the user said "about to > eject" would it run SYNC_CACHE. The only limitation is that after > running "eject", the device would have to be unplugged and replugged > before it could be mounted again. But that's expected behavior. > > Combine this with the write cache bit detection and you have a robust > solution. Comments? > What you describe is exactly my intention. I didn't mean to imply that a new XPORT becomes the dumping ground for the quirk table. Btw, for the record, your assumption about SYNC_CACHE also applies to RAID controllers, which is why Pawel's BIO_FLUSH hack is so dangerous and wrong. Scott