- 27 Apr, 2009 34 commits
-
-
Chris Leech authored
These probably never should have been exported. If they were needed outside of the fcoe module, they would have been moved to libfcoe. Signed-off-by:
Chris Leech <christopher.leech@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com>
-
Dan Carpenter authored
sk_buff pointers should use kfree_skb() instead of vanilla kfree(). Found by smatch (http://repo.or.cz/w/smatch.git). Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Abhijeet Joglekar authored
When a delete event is queued for an rport, set state to NONE so that no other processing is done on the rport as it is being removed. Signed-off-by:
Abhijeet Joglekar <abjoglek@cisco.com> Signed-off-by:
-
Abhijeet Joglekar authored
After lport_destroy, the local port should not be used again. Transition to state NONE, any incoming frames or link up should not transition out of this state since we are deleting exchange table and cleaning up the local port. Also, mark link as down. Signed-off-by:
-
Abhijeet Joglekar authored
We want to generate the rport queue event (from the logoff) before flushing the queue otherwise the event may still be in the queue when we logoff. Signed-off-by:
-
Abhijeet Joglekar authored
Rogue ports are currently not tracked on any list. The only reference to them is through any outstanding exchanges pending on the rogue ports. If the module is removed while a retry is set on a rogue port (say a Plogi retry for instance), this retry is not cancelled because there is no reference to the rogue port in the discovery rports list. Thus the local port can clean itself up, delete the exchange pool, and then the rogue port timeout can fire and try to start up another exchange. This patch tracks the rogue ports in a new list disc->rogue_rports. Creating a new list instead of using the disc->rports list keeps remote port code change to a minimum. 1) Whenever a rogue port is created, it is immediately added to the disc->rogue_rports list. 2) When the rogues port goes to ready, it is removed from the rogue list and the real remote port is added to the disc->rports list 3) The removal of the rogue from the disc->rogue_rports list is done in the context of the fc_rport_work() workQ thread in discovery callback. 4) Real rports are removed from the disc->rports list like before. Lookup is done only in the real rports list. This avoids making large changes to the remote port code. 5) In fc_disc_stop_rports, the rogues list is traversed in addition to the real list to stop the rogue ports and issue logoffs on them. This way, rogue ports get cleaned up when the local port goes away. 6) rogue remote ports are not removed from the list right away, but removed late in fc_rport_work() context, multiple threads can find the same remote port in the list and call rport_logoff(). Rport_logoff() only continues with the logoff if port is not in NONE state, thus preventing multiple logoffs and multiple list deletions. 7) Since the rport is removed from the disc list at a later stage (in the disc callback), incoming frames can find the rport even if rport_logoff() has been called on the rport. When rport_logoff() is called, the rport state is set to NONE, and we are trying to cancel all exchanges and retries on that port. While in this state, if an incoming Plogi/Prli/Logo or other frames match the rport, we should not reply because the rport is in the NONE state. Just drop the frame, since the rport will be deleted soon in the disc callback (fc_rport_work) 8) In fc_disc_single(), remove rport lookup and call to fc_disc_del_target. fc_disc_single() is called from recv_rscn_req() where rport lookup and rport_logoff is already done. Signed-off-by:
-
Abhijeet Joglekar authored
For instance, if there is a Plogi pending (remote port is in Plogi state), and the state changes to say NONE (because the port is being logged off), then when the Plogi resp times out, do not start a retry. This patch partially reverts an earlier patch (libfc: check for err when recv and state is incorrect), by moving the state check back to before checking for error. However, if the state does not match, then there is an additional check to see if its an error ptr or a real frame before jumping to err or out respectively. Signed-off-by:
-
Abhijeet Joglekar authored
gpn_ft_resp processing currently does not hold the discovery lock. disc_done() thus gets called from gpn_ft_resp or from gpn_ft_parse without the lock held. This then sets disc->pending to zero or calls gpn_ft_req() without disc_lock held. - Hold disc mutex during gpn_ft resp processing - In disc_done, release the disc mutex while calling lport callback Signed-off-by:
-
kxie@chelsio.com authored
(version 2) Fixed a bug in calculating ddp map range when search for free entries: it was going beyond the end by one, thus corrupting gl_skb[0]. Signed-off-by:
Karen Xie <kxie@chelsio.com> Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Mike Christie authored
When doing a lot (128) of large writes (256K) we can hit the cxgb3_snd_win check pretty easily. The driver's xmit thread then takes 100% of the cpu. The driver should not be returning -EAGAIN for this problem. It should be returing -ENOBUFS, then when the window is opened again it should queue the xmit thread (it already wakes the xmit thread). Signed-off-by:
-
Mike Christie authored
cxgb3i was setting can_queue to only 128 commands, and was setting the can_queue and cmd_per_lun to the same value. This sets the can_queue to 1024 commands, and sets the cmd_per_lun to a safer default of 32. Signed-off-by:
-
Mike Christie authored
Set target can queue limit to the number of preallocated session tasks we have. This along with the cxgb3i can_queue patch will fix a throughput problem where it could only queue one LU worth of data at a time. Signed-off-by:
-
Mike Christie authored
If a command's scsi cmd pdu setup fails then we can just fail the IO to the scsi layer. If a DATA_OUT for a R2T fails then we will want to drop the session, because it means we got a bad request from the target (iscsi protocol error). This patch has us propogate the error upwards so libiscsi_tcp or libiscsi can decide what the best action is to take. It also fixes a bug where we could try to grab the session lock while holding it, because if iscsi_tcp drops the session in the pdu setup callout the session lock is held when setting up the scsi cmd pdu. Signed-off-by:
-
Christof Schmitt authored
The zfcp_port might have been removed, while the FC fast_io_fail timer is still running and could trigger the terminate_rport_io callback. Set the pointer to the zfcp_port to NULL and check accordingly before using it. Reviewed-by:
Martin Petermann <martin@linux.vnet.ibm.com> Signed-off-by:
Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by:
-
Christof Schmitt authored
Before dropping the reference count with zfcp_adapter_put, increase it with zfcp_adapter_get when issuing cfdc requests. Reviewed-by:
-
Martin Petermann authored
If this problem appears zfcp ports cannot be de-queued since it is checked for a zero refcount. The port reference counting is wrong for existing zfcp ports when e.g. an adapter gets on-line again. During port scanning the reference counting for existing ports should not be changed. Signed-off-by:
Martin Petermann <martin.petermann@de.ibm.com> Signed-off-by:
-
Martin Petermann authored
The current sbal counting can be wrong if a fsf request is waiting for free sbals and at the same time qdio request queue is shutdown and re-opened. Revering a previous patch fixes this issue. Signed-off-by:
-
Christof Schmitt authored
When the abort handler cannot find a pending FSF request, the request completion could just be running. This means we cannot return SUCCESS, since this would lead to call to scsi_done after exiting the SCSI error handler which is not allowed. Reviewed-by:
-
Swen Schillig authored
A remote port remains in error state even if we receive a RSCN stating that the connection is re-established. The port recovery is not started due to a flag which is not reset. The solution is to clear the flag in question before we trigger a ERP. Signed-off-by:
Swen Schillig <swen@vnet.ibm.com> Signed-off-by:
-
Christof Schmitt authored
Error codes specific to the control file requests are evaluated by the actcli tool, so don't report -ENXIO for those. Generic problems are still checked for outside the command specific handler. Reviewed-by:
-
Martin Petermann authored
On some hardware it can take some time to add a unit. If some remove this unit during this process the remove will fail. Signed-off-by:
-
Swen Schillig authored
The remote port remains in error state even if the connection is re-established. A wrong precondition check was performed on the port status leading to a cancellation of the port reopen. Remove the pre-req check because it's not required and better handled within the ERP. Signed-off-by:
-
Swen Schillig authored
The ERP thread is performing a task before it is executing the corresponding down on the semaphore. The response handler of the just started exchange config should wait for the completion by performing a down on this semaphore. Since this semaphore is still positive from the ERP enqueue the handler won't wait and therefore the exchange config will always fail leaving the adapter in error. The problem can be solved by performing the down on the semaphore before starting an ERP task. This is the logically correct order. Only walk the ERP loop if there is a task to perform. Signed-off-by:
-
Swen Schillig authored
The nameserver port might be in state online when the adapter is offlined. On adapter reactivation the nameserver port is not re-opened due to the PORT_ONLINE status. This results in an unsuccessful recovery. In forcing the nameserver port status to offline on all adapter offline events this issue is prevented. Waiting for the reference count to drop to zero in zfcp_wka_port_offline is not required, so remove it. Signed-off-by:
-
Swen Schillig authored
When running the scsi_scan from the zfcp workqueue and the target device does not respond, the zfcp workqueue can block until the scsi_scan hits a timeout. Move the work to the scsi host workqueue, since this one is also used for the scan from the SCSI midlayer. Signed-off-by:
-
Christof Schmitt authored
Fix problem that zfcp_fsf_exchange_config_data_sync and zfcp_fsf_exchange_config_data_sync could try to call zfcp_fsf_req_free with a NULL pointer. Reviewed-by:
-
Swen Schillig authored
Since we're setting the host port type now to FC_PORTTYPE_NPIV for adapters running in NPIV mode we should allow this port type for auto-port scanning as well. Signed-off-by:
-
Martin Petermann authored
Avoid referencing a fsf request after sending it in fcp_fsf_req_send, it might have already completed and deallocated. Signed-off-by:
-
Mike Christie authored
We cannot call blk_plug_device from scsi_target_queue_ready because the q lock is not held. And we do not need to call it from there because when we return 0, the scsi_request_fn not_ready handling will plug the queue for us if needed. Signed-off-by:
-
James Smart authored
Update driver version to 8.3.1 Also update copyright end year for driver. Signed-off-by:
James Smart <James.Smart@emulex.com> Signed-off-by:
-
James Smart authored
8.3.1 Fixes/Changes : - Fix incorrect byte-swapping on word 4 of IOCB (data length) which caused LUNs to not be discovered on big-endian (e.g. PPC) - Remove a bad cast of MBslimaddr which loses the __iomem (sparse) - Make lpfc_debugfs_mask_disc_trc static (sparse) - Correct misspelled word BlockGuard in lpfc_logmsg.h comment - Replaced repeated code segment for canceling IOCBs from a list with a function call, lpfc_sli_cancel_iocbs(). - Increased HBQ buffers to support 40KB SSC sequences. - Added sysfs interface to update speed and topology parameter without link bounce. - Fixed bug with sysfs fc_host WWNs not being updated after changing the WWNs. - Check if the active mailbox is NULL in the beginning of the mailbox timeout handler - fixes panic in the mailbox timeout handler while running IO stress test - Fixed system panic in lpfc_pci_remove_one() due to ndlp indirect reference to phba through vport - Removed de-reference of scsi device after call to scsi_done() to fix panic in scsi completion path while accessing scsi device after scsi_done is called. - Fixed "Nodelist not empty" message when unloading the driver after target reboot test - Added LP2105 HBA model description - Added code to print all 16 words of unrecognized ASYNC events - Fixed memory leak in vport create + delete loop - Added support for handling dual error bit from HBA - Fixed a driver NULL pointer dereference in lpfc_sli_process_sol_iocb - Fixed a discovery bug with FC switch reboot in lpfc_setup_disc_node - Take NULL termintator into account when calculating available buffer space Signed-off-by:
-
James Smart authored
Signed-off-by:
-
FUJITA Tomonori authored
blk_rq_unmap_user() returns EFAULT if a program passes an invalid address to kernel (the kernel fails to copy data to user space). sg needs to pass the returned value to user space instead of ignoring it. Before the block layer conversion, sg returns EFAULT properly. This restores the old behavior. Signed-off-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Peter Jones authored
So, what's happening here is that the drive is reporting a sense of 2/4/1 ("logical unit is becoming ready") from sr_test_unit_ready(), and then we ask for the media event notification before checking that result at all. The check_media_event_descriptor() call isn't getting a check condition, but it's also reporting that the tray is closed and that there's no media. In actuality it doesn't yet know if there's media or not, but there's no way to express that in the media event status field. My current thought is that if it told us the device isn't yet ready, we should return that immediately, since there's nothing that'll tell us any more data than that reliably: Signed-off-by:
-
- 26 Apr, 2009 6 commits
-
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
Tim Abbott <tabbott@mit.edu> Cc: David S. Miller <davem@davemloft.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
-
Tim Abbott authored
This has the consequence of changing the section name use for head code from ".text.head" to ".head.text". Since this commit changes all users in the architecture, this change should be harmless. Signed-off-by:
-
