From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 07:54:14 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 5C4BB16A410 for ; Fri, 2 Feb 2007 07:54:13 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id D8CEE13C48D for ; Fri, 2 Feb 2007 07:54:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 44435 invoked from network); 2 Feb 2007 07:27:33 -0000 Received: from ppp-71-139-39-138.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.39.138) by root.org with ESMTPA; 2 Feb 2007 07:27:33 -0000 Message-ID: <45C2E7DB.30204@root.org> Date: Thu, 01 Feb 2007 23:27:23 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Scott Long 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> In-Reply-To: <45C27965.1010803@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 07:54:14 -0000 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? -- Nate