src-test2/sys/dev/aac, branch release/6.4.0_cvs

Copy releng/6.4 to release/6.4.0 in preparation for 6.4-RELEASE.

2008-11-26T01:09:48Z

Approved by: re (implicit) This commit was manufactured to restore the state of the 6.4-RELEASE image.

MFC r177899:

2008-07-02T14:44:09Z

Allow crashdumps on machines with >4GB of RAM as long as the adapter can do 64-bit S/G.

MFC additional driver enhancements.

2008-06-30T21:22:59Z

r174385 Allow simultaneous opens of the device for issuing commands to the controller. This is merged from Adaptec driver build 11669. r177462 Add ioctls FSACTL_SEND_LARGE_FIB, FSACTL_SEND_RAW_SRB, FSACTL_LNX_SEND_LARGE_FIB, and FSACTL_LNX_SEND_RAW_SRB, and correct size checks on FIBs passed in from userspace. Both changes were obtained from Adaptec's driver build 15317. Adaptec's commandline RAID tool arcconf uses these ioctls when creating a RAID-10 array (and probably other operations too). r177567 Diff reduction to Adaptec's driver (around build 15317): catch up with a change in debugging routines. The fwprintf macro in the AAC_DEBUG case (mapping to printf) isn't from the Adaptec driver. r177619 Add 64-bit array support for RAIDs > 2TB. This corresponds to ~ Adaptec driver build 15317. r177635 Add \n to the end of a printf string and remove it from panic strings. r177695 Implement FSACTL_LNX_GET_FEATURES and FSACTL_GET_FEATURES ioctls. RAID tools (e.g. arcconf) need this to be able to create arrays larger than 2TB. r179969 Fix test for waiting AIFs in aac_poll(). This seems to solve the problem where Adaptec's arcconf monitoring tool hangs after producing its expected output.

MFC aac.c 1.137:

2008-04-07T14:19:57Z

Calling RequestSupplementAdapterInfo before RequestAdapterInfo appears to trip a bug causing the latter to return a zeroed struct aac_adapter_info. This causes two issues. One is cosmetic only -- a verbose boot prints information about the controller, and shows all zero: aac0: Unknown processor 0MHz, 0MB memory (0MB cache, 0MB execution), unknown battery platform The second problem is that the firmware version information is stored away for aac_rev_check, for userland tools (like aaccli) to query via the FSACTL_MINIPORT_REV_CHECK and FSACTL_LNX_MINIPORT_REV_CHECK ioctls. When aaccli encounters this issue it prints Command Error: Move the RequestSupplementAdapterInfo call after RequestAdapterInfo, which seems to fix both problems.

Acquire Giant in aac_cam_event for xpt_release_simq. Not necessary with

2008-04-01T00:09:29Z

MPSAFE CAM so not an MFC.

MFC aac.c r1.126:

2008-03-31T23:16:05Z

Do not recursively acquire aac_io_lock in aac_ioctl_event.

MFC aac_cam.c 1.30:

2008-03-31T20:11:46Z

Merge from Adaptec a 64 bit fix and a workaround for luns != 0 returning CAM_SEL_TIMEOUT on SAS controllers, which prevented passthrough devices from being created.

MFC aac.c 1.125, aac_pci.c 1.66, aacreg.h:1.24:

2008-03-31T20:03:31Z

Add family support to allow the driver to attach to new devices that share the same interface.

MFC aac.c 1.130:

2008-03-31T19:50:53Z

Restore creation of passthrough devices with newer controller firmware by putting the correct size in the fib header. Presumably the older firmware silently ignored a bad size field. (This change tested with a 3805 controller. Passthrough devices were created when running firmware build 12814, but not 15323 or later. With this change they're created for both old and new firmware versions.) Submitted by: Adaptec

MFC aac.c 1.131:

2008-03-31T17:04:10Z

Diff reduction to Adaptec driver build 15317 (refactoring and code shuffling): - Resource allocation in aac_alloc (moved from from aac_init) - Interrupt setup in aac_setup_intr (from aac_attach) - Container probing in aac_get_container_info (from aac_startup and aac_handle_aif) - Firmware status check moved to aac_check_firmware from aac_init