From owner-cvs-all@FreeBSD.ORG Fri Nov 16 16:45:51 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B04B816A41A; Fri, 16 Nov 2007 16:45:51 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-70484.0x50a6c9a6.abnxx16.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id 12F7813C4D5; Fri, 16 Nov 2007 16:45:50 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from ws.local (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id lAGGjn0M048143; Fri, 16 Nov 2007 17:45:49 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <473DC93D.5060205@deepcore.dk> Date: Fri, 16 Nov 2007 17:45:49 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Scott Long References: <200710260859.l9Q8xPdP099307@repoman.freebsd.org> <473DC220.6030809@samsco.org> In-Reply-To: <473DC220.6030809@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, SXren Schmidt Subject: Re: cvs commit: src/sys/dev/ata atapi-cd.c atapi-cd.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 16:45:51 -0000 Scott Long wrote: > SXren Schmidt wrote: >> sos 2007-10-26 08:59:24 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/dev/ata atapi-cd.c atapi-cd.h Log: >> Update the way we get the mode pages on probe. >> Revision Changes Path >> 1.194 +22 -25 src/sys/dev/ata/atapi-cd.c >> 1.47 +1 -0 src/sys/dev/ata/atapi-cd.h > > Just curious, what was the motivation for changing from doing a > TUR to doing a MODE_SENSE in g_access? Your new code now relies > on what I'd consider is a fairly obscure feature of the SFF-8020i > spec, and one that contradicts the MMC and SPC specs that are now > used as the normative references for packet commands. There's at > least once case, the virtual CDROM emulator in Parallels, that > appears not to support this feature, and I'd bet pretty heavily > that there are a number of real devices that won't support it > either. > > Without reverting to the old TUR code, an easy way forward is to > not fail the g_access command for the MST_FMT_NONE case. This is > generally incorrect anyways as it just means that the device can't > specifically identify the media though it knows that the media is > inserted and valid. Since this constant evaluates to 0x00, ignoring > it will also allow devices that don't support it to still work. The > only side effect is that devices that don't support it will also not > be able to report MST_NO_DISC. These devices will get handled later > as a side effect of reporting a bogus media size. > > Ultimately, I do think that the code needs to go back to using a TUR > and interpreting sense, asc, and ascq codes correctly. The code prior > to 10/26 looks like it does this, so again I'm curious as to what , > motivated the change. The code is only intended to work around the verbose error chatter from=20 GEOM as it will read from a nonexisting media (if the drive is empty)=20 during boot, and clutter the console needlessly. There is currently no=20 way to prevent this, but I've talked to phk about it lately so this can=20 be left out alltogether. Anyhow the only failure I've seen so far is Parallels when using a CD=20 image as a virtual CDROM drive, it does a poor HW emu in that case if=20 you ask me :) Anyhow you are free to do what you want with the code until I get a real = fix via GEOM done, but mind you the old code will not work on SATA ATAPI = drives so a simple rollback of the commit is not really a fix... -S=F8ren