From owner-svn-src-all@FreeBSD.ORG Tue Mar 27 19:45:09 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B8F106566B; Tue, 27 Mar 2012 19:45:09 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo1so.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1728FC12; Tue, 27 Mar 2012 19:45:09 +0000 (UTC) Received: from pd4ml1so-ssvc.prod.shaw.ca ([10.0.141.141]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 27 Mar 2012 13:45:08 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=zu4PKjlF+9DoPrG/TPTQ4CC8dREy1gI1uGhqrRhVwqE= c=1 sm=1 a=g2nFUZfGhBYA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=KQMYF_uwN4BO8LJD1mIA:9 a=Wh7kbxKHxWDQpkvJsNgA:7 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by pd4ml1so-dmz.prod.shaw.ca with ESMTP; 27 Mar 2012 13:45:08 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id DBD7381; Tue, 27 Mar 2012 12:45:07 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.5/8.14.5) with ESMTP id q2RJj6DZ009507; Tue, 27 Mar 2012 12:45:07 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201203271945.q2RJj6DZ009507@slippy.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Marius Strobl In-Reply-To: Message from Marius Strobl of "Mon, 26 Mar 2012 08:50:04 +0200." <20120326065004.GS37560@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Mar 2012 12:45:06 -0700 Cc: Cy Schubert , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r233274 - in head/sys/dev/ata: . chipsets X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:45:09 -0000 In message <20120326065004.GS37560@alchemy.franken.de>, Marius Strobl writes: > On Sun, Mar 25, 2012 at 10:35:33PM -0700, Cy Schubert wrote: > > In message <201203210857.q2L8vFLB062984@svn.freebsd.org>, Marius Strobl > > writes: > > > Author: marius > > > Date: Wed Mar 21 08:57:15 2012 > > > New Revision: 233274 > > > URL: http://svn.freebsd.org/changeset/base/233274 > > > > > > Log: > > > Remove remnants of ATA_LOCKING uses in the ATA_CAM case and wrap it > > > along with functions, SYSCTLs and tunables that are not used with > > > ATA_CAM in #ifndef ATA_CAM, similar to the existing #ifdef'ed ATA_CAM > > > code for the other way around. This makes it easier to understand > > > which parts of ata(4) actually are used in the new world order and > > > to later on remove the !ATA_CAM bits. It also makes it obvious that > > > there is something fishy with the C-bus front-end as well as in the > > > ATP850 support, as these used ATA_LOCKING which is defunct in the > > > ATA_CAM case. When fixing the former, ATA_LOCKING probably needs to > > > be brought back in some form or other. > > > > > > Reviewed by: mav > > > MFC after: 1 week > > > > > > Modified: > > > head/sys/dev/ata/ata-all.c > > > head/sys/dev/ata/ata-cbus.c > > > head/sys/dev/ata/ata-pci.c > > > head/sys/dev/ata/ata-pci.h > > > head/sys/dev/ata/ata-queue.c > > > head/sys/dev/ata/chipsets/ata-acard.c > > > > > [... diff removed for brevity ...] > > > > Hi, > > > > This commit broke kernels with device atapicam specified: > > > > # ATA and ATAPI devices > > device atapicam # emulate ATAPI devices as SCSI ditto via > > CAM > > # needs CAM to be present (scbus & > > pass) > > > > Here are two examples when device atapicam is specified in the kernel > > config: > > > > <...> > > Apparently, you are using both "device atapicam" and "options ATA_CAM", > which are mutually exclusive at run-time. As an intentional side-effect, > r233274 breaks such configurations. The fact that you could compile > both into the same kernel before was a bug, as ATA_CAM always took > precedence. > > > > > And, the patch to fix the issue: > > No, this is backwards. Cool, thanks. I've removed device atapicam from my configs. ;) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org