Mike Christie micha...@cs.wisc.edu wrote:
+ ep-conn = cls_conn;
+ cls_conn-ep = ep;
if not, it doesn't look like ep can be null here...
Will fix. Tested offload and did not test software iscsi.
Mike, are you pushing this to 2.6.38? if yes, could you send it to
review @
On 01/11/2011 12:25 AM, Or Gerlitz wrote:
Mike Christiemicha...@cs.wisc.edu wrote:
+ ep-conn = cls_conn;
+ cls_conn-ep = ep;
if not, it doesn't look like ep can be null here...
Will fix. Tested offload and did not test software iscsi.
Mike, are you pushing this to 2.6.38? if
On 01/06/2011 12:54 AM, Or Gerlitz wrote:
Mike Christie wrote:
I went a different way. In the attached patch we detect the problem when
binding and will force a disconnect of the old ep before binding a new one.
Try it out and let me know.
--- a/drivers/scsi/iscsi_tcp.c
+++
Mike Christie wrote:
I went a different way. In the attached patch we detect the problem when
binding and will force a disconnect of the old ep before binding a new one.
Try it out and let me know.
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -651,8 +651,7 @@ free_addr:
On 11/17/2010 09:24 PM, Mike Christie wrote:
On 11/10/2010 05:04 PM, Eddie Wai wrote:
This is the case when iscsid gets re-launched due to features like
iSCSI boot which requires the daemon to re-launch due to
pivot root. If the code detected the connection had an existing
endpoint, the old
On 11/10/2010 05:04 PM, Eddie Wai wrote:
This is the case when iscsid gets re-launched due to features like
iSCSI boot which requires the daemon to re-launch due to
pivot root. If the code detected the connection had an existing
endpoint, the old endpoint must get cleaned up.
Signed-off-by:
This is the case when iscsid gets re-launched due to features like
iSCSI boot which requires the daemon to re-launch due to
pivot root. If the code detected the connection had an existing
endpoint, the old endpoint must get cleaned up.
Signed-off-by: Eddie Wai eddie@broadcom.com
Acked-by:
