- 03 Jul, 2011 40 commits
-
-
Dan Williams authored
Since libsas takes the domain device sata_dev.ap->lock before submitting a task, error completions in the submit path for SATA devices must unlock/relock when completing the sas_task back to libsas. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
The request may be in the "aborted" or the "completed" state when performing a task management operation on it. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
In the case where a SAS or SATA LUN reset TMF is built a NULL pointer dereference occurred because of the (unused) callback data pointer. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com>
-
Jeff Skirvin authored
Added a request "dead" state for use when a termination wait times-out. isci_terminate_pending_requests now detaches the device's pending list and terminates each entry on the detached list. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
Since the request structure contains a pointer to the completion to be used if the request is being aborted or terminated, there is no reason to pass the completion as a pointer to isci_terminate_request_core(). Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
Made sure the device ready check accounts for all states. Moved the aborted task check into the loop of pulling task requests off of the submitted list. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> [remove host and device starting state checks] Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
The pointer to the core representation of a request is marked NULL at completion, but we need to save the i/o tag for task management. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> [revise changelog] Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
If there is a pending device reset, the I/O is used to accomplish the reset by setting the RESET bit in the task status, and then putting the task into the error handler path using sas abort task. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
Corrected use of the request state_lock in the completion callback. In the case where an abort (or reset) thread is trying to terminate an I/O request, it sets the request state to "aborting" (or "terminating") if the state is still "starting". One of the bugs was to never set the state to "completed". Another was to not correctly recognize the situation where the I/O had completed but the sas_task was still pending callback to task_done - this was typically a problem in the LUN and device reset cases. It is now possible that we leave isci_task_abort_task() with request->io_request_completion pointing to localy allocated aborted_io_completion struct. It may result in a system crash. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Maciej Trela <Maciej.Trela@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
Changes to move management of the reqs_in_process entry for the request here. Made changes to note when the task is already in the abort path and cannot be completed through callbacks. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jeff Skirvin authored
In the condition where outstanding I/Os are being cleaned from the device requests in process list, the cleanup function needs to check that the request is actually a sas-task and not a task management function. Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Reported-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
The remote_device_lock is currently used to protect a controller global resource (RNCs), but the remote_device_lock is per-port. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Until we synchronize against device removal this limits the damage of use after free bugs to the driver's own objects. Unless we implement reference counting we need to ensure at least a subset of a remote device is valid at all times. We follow the lead of other libsas drivers that also preallocate devices. This also enforces maximum remote device accounting at the lldd layer, but the core may still run out of RNC's before we hit this limit. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Replace the device completion infrastructure with the controller wide event queue. There was a potential for the stop and ready notifications to corrupt each other, now that cannot happen. The stop pending flag cannot be used until devices are statically allocated. We temporarily need to maintain a completion to handle waiting for an object that has disappeared, but we can at least stop scribbling on freed memory. A future change will also get rid of the "stopping" state as it should not be exposed to the rest of the driver. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
The midlayer is already throttling i/o in the places where host_quiesce was trying to prevent further i/o to the device. It's also problematic in that it holds a lock over GFP_KERNEL allocations. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
It belies the fact that isci_remote_device and scic_sds_remote_device are one in same object with the same lifetime rules. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
isci_host_by_id() should have been a clue that an array would have been a simpler approach. Reported-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Now that phys_to_virt() and virt_to_phys() have been removed we are no longer violating the dma mapping (or kmap apis). Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Ross says: "The memory allocation for these requests doesn’t take into account the additional memory needed when the code in scic_sds_s[mst]p_request_assign_buffers() shifts the struct scu_task_context so that it is cache line aligned: In an example from my machine, total buffer that I’ve given to SCIC goes from 0x410024566f84 to 0x410024567308. From this same example, this call shifts my task_context_buffer from 0x410024567208 to 0x410024567240. This means that the task_context_buffer that used to range from 0x410024567208 to 0x410024567308 instead now goes from 0x410024567240 to 0x410024567340. When the memset() call at the end of scic_task_request_construct() clears out this task_context_buffer, it does so from 0x410024567240 to 0x410024567340, effectively killing whatever buffer follows this allocation in memory." djbw: Use the kernel's PTR_ALIGN instead of scic_sds_request_align_task_context_buffer() and SMP_CACHE_BYTES instead of the local CACHE_LINE_SIZE definition. TODO: These allocations really want to be better defined in a union rather than opaque buffers carved up by macros. Reported-by: Ross Zwisler <ross.zwisler@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
When aborting a task context we need to be sure that the hardware has acted on this request (retrieved the task context) before invalidating the remote node context. In the case of the "dummy" task context and remote node we do not have the full state machine that goes through the complete tc abort and rnc invalidate states. Instead we ensure the hardware has seen and acted on Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
Moving some of the chattiness of warning messages to debug so only the Linux system messages are shown. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
Adding support for PHY_FUNC_LINK_RESET and PHY_FUNC_DISABLE. This allow the sysfs knob enable (both 0 and 1) and link_reset to work properly. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Pawel Marek authored
Core reworks to support stopping and re-starting the controller, lays the groundwork for phy disable / re-enable and fixes other bugs around port/phy setup/teardown. Signed-off-by: Pawel Marek <pawel.marek@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Piotr Sawicki authored
Observed that some devices return a d2h fis, treat like an sdb error fis. Signed-off-by: Piotr Sawicki <piotr.sawicki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Tomasz Chudy authored
There is a condition whereby TCs (task contexts) can jump to the head of the round robin queue causing indefinite starvation of pending tasks. Posting a TC to a suspended RNC (remote node context) causes the hardware to select that task first, but since the RNC is suspended the scheduler proceeds to the next task in the expected round robin fashion, restoring TC arbitration fairness. Signed-off-by: Tomasz Chudy <tomasz.chudy@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Prepare the timer api for the arrival of dynamic creation and destruction events from the core. It pretended to do this previously but the core to date only used it in a static init-time only fashion. This is an interim fix until a cleaner event queue can be developed. 1/ make all locking external to the api (add WARN_ONCE to verify) 2/ add a timer_destroy interface (to be used by the core) 3/ use del_timer_sync() prior to deallocating timer data 4/ delete the "timer_list" indirection, we only have timers allocated for the isci_host 5/ fix detection of timer list allocation errors Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Undo the open coded and incorrect translation of the oem parameter sas address to its libsas expected format. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
Removed all callbacks in the deprecated.c. Core will call the appropriate functions directly. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
Renaming the callbacks to apparopriate event notify calls for the LLDD. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
Remove abstraction for SG building and get rid of callbacks for getting DMA memory mapping. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
We can copy the data directly to and from sg for SATA PIO read operations. There is no reason to involve the hardware SGL. In the process we also need to kmap the sg because we don't know where that can come from. We also do to not call phys_to_virt(). The driver already has the information. We can just calculcate the appropriate offets. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dave Jiang authored
These macros are not necessary. We can do 64bit math directly. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Piotr Sawicki authored
Sending aborts/resets to SAS/SATA targets in APC mode eventually causes an assert in scic_sds_apc_agent_link_up(). We need to handle the hard reset case for apc mode ports. Signed-off-by: Piotr Sawicki <piotr.sawicki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Tomasz Chudy authored
Update the SCI Core to comprehend the changes in the TC completion codes from A0 to B0. Specifically, there isnew R_ER code differences for command and data FISes. Changes are as follows: 1) 0x16 now additionally indicates an R_ERR received for a COMMAND FIS being sent to a SATA target. 0x16 for SSP still indicates a NAK received for a COMMAND frame. Fix is to retry TC to be compliant with SATA spec or ensure proper error handling of return value (not spec compliant I don't believe). 2) 0x1B was previously called DONE_BREAK_RCVD for STP and DONE_LL_ABORT_ERR for SSP. Now it is universally called DONE_LL_ABORT_ERR. This is purely a superficial change. 3) 0x32 is no longer a reserved code. Now it indicates DONE_CMD_SDMA_ERR for STP/SSP. There was a fatal error on the SDMA for a command IU (includes Raw frames). Consider retry, but at a minimum gracefully fail the request. 4) 0x33 is no longer a reserved code. Now it indicates DONE_CMD_LL_ABORT_ERR for SSP. There was a break receivd during transmission of a command IU. Consider retry, but at a minimum gracefully fail the request. Signed-off-by: Tomasz Chudy <Tomasz.Chudy@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
Use the dynamic revision detection code in scic_sds_phy_link_layer_initialization() and apply some coding style fixups (long deref chains). The compile time max link rate setting is removed in favor of honoring the user-parameter max. Reported-by: Krzysztof Wierzbicki <Krzysztof.Wierzbicki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Jacek Danecki authored
Add support for the following parameters in SCIC: /** * This field specifies the NOTIFY (ENABLE SPIN UP) primitive * insertion frequency for this phy index. */ u32 notify_enable_spin_up_insertion_frequency; /** * This method specifies the number of transmitted DWORDs within which * to transmit a single ALIGN primitive. This value applies regardless * of what type of device is attached or connection state. A value of * 0 indicates that no ALIGN primitives will be inserted. */ u16 align_insertion_frequency; /** * This method specifies the number of transmitted DWORDs within which * to transmit 2 ALIGN primitives. This applies for SAS connections * only. A minimum value of 3 is required for this field. */ u16 in_connection_align_insertion_frequency; Signed-off-by: Krzysztof Wierzbicki <Krzysztof.Wierzbicki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Henryk Dembkowski authored
At init and RNC resume we need to touch every phy in a port to be sure we have initialized STP properties in the case where port_index != phy_index. Also add some missing __iomem annotations. Signed-off-by: Henryk Dembkowski <henryk.dembkowski@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Tomasz Chudy authored
The default should be 5us. The hardware encodes it in 256ns increments, so the value should be 20 to approximate a 5us timeout. Signed-off-by: Tomasz Chudy <Tomasz.Chudy@intel.com> Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
Dan Williams authored
c99 the struct initializers: 1/ allows grep to consistently show method name associations. The naming is mostly consistent (except when it isn't) so this guarantees coverage of present and future exception cases. 2/ let's the compiler guarantee that the state table array entry correlates with an actual state name and detect accidental reordering or deletion of states. / allows default handler's to be identified easily Signed-off-by: Jacek Danecki <Jacek.Danecki@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-