ddbffe7f70
ThunderBolt cannot read sector >= 2^32 or 2^21 with supplied patch. Second the bigger change, fix RAID operation on ThunderBolt base card such as physically removing a disk from a RAID and replacing it. The current situation is the RAID firmware effectively hangs waiting for an acknowledgement from the driver. This is due to the firmware support of the driver actually accessing the RAID from under the firmware. This is an interesting feature that the FreeBSD driver does not use. However, when the firmare detects the driver has attached it then expects the driver will synchronize LD's with the firmware. If the driver does not sync. then the management part of the firmware will hang waiting for it so a pulled driver will listed as still there. The fix for this problem isn't extremely difficult. However, figuring out why some of the code was the way it was and then redoing it was involved. Not have a spec. made it harder to try to figure out. The existing driver would send a MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge a LD state change. In read mode it gets the RAID map from the firmware. The FreeBSD driver doesn't do that currently. It could be added in the future with the appropriate structures. To simplify things, get the current LD state and then build the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends an acknowledgement for each LD. The map would probably state which LD's changed so then the driver could probably just acknowledge the LD's that changed versus all. This doesn't seem to be a problem. When a MFI_DCMD_LD_MAP_GET_INFO/write command is sent to the firmware, it will complete later when a change to the LD's happen. So it is very much like an AEN command returning when something happened. When the MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the sync'ing of the LD state. This needs to be done in as an event so that MFI_DCMD_LD_GET_LIST can wait for that command to complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write. The prior code didn't use the call-back function and tried to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when processing an interrupt. This added a bunch of code complexity to the interrupt handler. Using the call-back that is done for other commands got rid of this need. So the interrupt handler is greatly simplified. It seems that even commands that shouldn't be acknowledged end up in the interrupt handler. To deal with this, code was added to check to see if a command is in the busy queue or not. This might have contributed to the interrupt storm happening without MSI enabled on these cards. Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away. It would be interesting to see what other complexity could be removed from the ThunderBolt driver that really isn't needed in our mode of operation. Letting the RAID firmware do all of the I/O to disks is a lot faster since it can use its caches. It greatly simplifies what the driver has to do and potential bugs if the driver and firmware are not in sync. Simplify the aen_abort/cm_map_abort and put it in the softc versus in the command structure. This should get merged to 9 before the driver is merged to 8. PR: 167226 Submitted by: Petr Lampa MFC after: 3 days
This is the top level of the FreeBSD source directory. This file was last revised on: $FreeBSD$ For copyright information, please see the file COPYRIGHT in this directory (additional copyright information also exists for some sources in this tree - please see the specific source directories for more information). The Makefile in this directory supports a number of targets for building components (or all) of the FreeBSD source tree, the most commonly used one being ``world'', which rebuilds and installs everything in the FreeBSD system from the source tree except the kernel, the kernel-modules and the contents of /etc. The ``world'' target should only be used in cases where the source tree has not changed from the currently running version. See: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html for more information, including setting make(1) variables. The ``buildkernel'' and ``installkernel'' targets build and install the kernel and the modules (see below). Please see the top of the Makefile in this directory for more information on the standard build targets and compile-time flags. Building a kernel is a somewhat more involved process, documentation for which can be found at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html And in the config(8) man page. Note: If you want to build and install the kernel with the ``buildkernel'' and ``installkernel'' targets, you might need to build world before. More information is available in the handbook. The sample kernel configuration files reside in the sys/<arch>/conf sub-directory (assuming that you've installed the kernel sources), the file named GENERIC being the one used to build your initial installation kernel. The file NOTES contains entries and documentation for all possible devices, not just those commonly used. It is the successor of the ancient LINT file, but in contrast to LINT, it is not buildable as a kernel but a pure reference and documentation file. Source Roadmap: --------------- bin System/user commands. cddl Various commands and libraries under the Common Development and Distribution License. contrib Packages contributed by 3rd parties. crypto Cryptography stuff (see crypto/README). etc Template files for /etc. games Amusements. gnu Various commands and libraries under the GNU Public License. Please see gnu/COPYING* for more information. include System include files. kerberos5 Kerberos5 (Heimdal) package. lib System libraries. libexec System daemons. release Release building Makefile & associated tools. rescue Build system for statically linked /rescue utilities. sbin System commands. secure Cryptographic libraries and commands. share Shared resources. sys Kernel sources. tools Utilities for regression testing and miscellaneous tasks. usr.bin User commands. usr.sbin System administration commands. For information on synchronizing your source tree with one or more of the FreeBSD Project's development branches, please see: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html