Re: aac(4) and multiple ld(4)s

[Allen Briggs <briggs%netbsd.org@localhost>]

On Tue, Sep 23, 2008 at 08:57:06AM +0100, Stephen Borrill wrote:
> On Mon, 22 Sep 2008, Allen Briggs wrote:
> >This patch doesn't quite work for me.  Both of my controllers support
> >64-bit arrays, but neither has one above 2TB and the 64-bit quirk isn't
> >set.
> >
> >I needed to modify it so that I can accept a VM_NameServe response
> >that's 4 bytes less than the size of aac_mntinforesponse.  My adjustment
> >to your patch is here:
> >ftp://ftp.netbsd.org/pub/NetBSD/misc/briggs/aac64bit.diff2
> 
> Do you get the "Enable raw I/O" and/or "Enable 64-bit array support" 
> messages?

Yes.  The first.  On my Adaptec SCSI controller.  On my Dell CERC
SATA controller, neither:
aac0 at pci2 dev 6 function 0: Adaptec ASR-2200S
aac0: interrupting at ioapic1 pin 0
aac0: Enabling 64-bit address support
aac0: Enable raw I/O
aac0: New comm. interface enabled
aac0: i80303 at 100MHz, 64MB mem (48MB cache), optional battery present
aac0: Kernel 4.2-0 [Build 8205], Monitor 4.2-0 [Build 8205], S/N B74F1F
aac0: Controller supports: 
31d7e<CLUSTERS,WCACHE,DATA64,HOSTTIME,RAID50,WINDOW4GB,SOFTERR,SGMAP64,ALARM,NONDASD>
ld0 at aac0 unit 0: RAID 5
ld0: 34902 MB, 8864 cyl, 128 head, 63 sec, 512 bytes/sect x 71479296 sectors

aac1 at pci3 dev 9 function 0: Dell CERC SATA RAID 1.5/6ch
aac1: interrupting at ioapic2 pin 0
aac1: GETCOMMPREF appears untrustworthy.  Ignoring.
aac1: i80303 at 100MHz, 64MB mem (48MB cache), optional battery not installed
aac1: Kernel 4.1-0 [Build 7417], Monitor 4.1-0 [Build 7417], S/N 4FADCF
aac1: Controller supports: 
1097c<WCACHE,DATA64,HOSTTIME,RAID50,WINDOW4GB,SOFTERR,ALARM>
ld1 at aac1 unit 0: RAID 1 (Mirror)
ld1: 232 GB, 30389 cyl, 255 head, 63 sec, 512 bytes/sect x 488213504 sectors


> Any reason for zeroing mir.MntTable[0].CapacityHigh (as it won't be used 
> if AAC_QUIRK_LBA_64BIT isn't set)?

Just to make the cases a little more uniform.  If we're using one
structure, my inclination is to make it backward compatible and
then use all the parts of it rather than only fill in parts of it
and then make the use conditional in one or more other places.  If
that makes any sense.  In fact, along those lines, I'm inclined to
just use CapacityHigh in the calculation of hd_size rather than
having the conditional on QUIRK_LBA_64BIT.  But I can't get too
excited about that part of the patch.  The important part is to
check against the right response size for the command you're sending.

Hmm...  It might also be nice to note in aacreg.h that CapacityHigh
is only returned if the command is VM_NameServe64.  Just something like
        u_int32_t       CapacityHigh; /* Only if VM_NameServe64 */

-allen

-- 
Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  
briggs%ninthwonder.com@localhost