svn commit: r233274 - in head/sys/dev/ata: . chipsets

[Marius Strobl]

On Sun, Mar 25, 2012 at 10:35:33PM -0700, Cy Schubert wrote:
> In message <201203210857.q2L8vFLB062984 at 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.


Marius