1. 14 Apr, 2006 6 commits
    • Mike Christie's avatar
      [SCSI] iscsi: fix up iscsi eh · 30a6c652
      Mike Christie authored
      The current iscsi_tcp eh is not nicely setup for dm-multipath
      and performs some extra task management functions when they
      are not needed.
      
      The attached patch:
      
      - Fixes the TMF issues. If a session is rebuilt
      then we do not send aborts.
      
      - Fixes the problem where if the host reset fired, we would
      return SUCCESS even though we had not really done anything
      yet. This ends up causing problem with scsi_error.c's TUR.
      
      - If someone has turned on the userspace nop daemon code to try
      and detect network problems before the scsi command timeout
      we can now drop and clean up the session before the scsi command
      timesout and fires the eh speeding up the time it takes for a
      command to go from one patch to another. For network problems
      we fail the command with DID_BUS_BUSY so if failfast is set
      scsi_decide_disposition fails the command up to dm for it to
      try on another path.
      
      - And we had to add some basic iscsi session block code. Previously
      if we were trying to repair a session we would retrun a MLQUEUE code
      in the queuecommand. This worked but it was not the most efficient
      or pretty thing to do since it would take a while to relogin
      to the target. For iscsi_tcp/open-iscsi a lot of the iscsi error handler
      is in userspace the block code is pretty bare. We will be
      adding to that for qla4xxx.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      30a6c652
    • Mike Christie's avatar
      [SCSI] iscsi: add sysfs attrs for uspace sync up · fd7255f5
      Mike Christie authored
      For iscsi boot when going from initramfs to the real root we
      need to stop the userpsace iscsi daemon. To later restart it
      iscsid needs to be able to rebuild itself and part of that
      process is matching a session running the kernel with the
      iscsid representation. To do this the attached patch
      adds several required iscsi values. If the LLD does not provide
      them becuase, login is done in userspace, then the transport
      class and userspace set ths up for the LLD.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      fd7255f5
    • Mike Christie's avatar
      [SCSI] iscsi: rm kernel iscsi handles usage for session and connection · b5c7a12d
      Mike Christie authored
      from hare@suse.de and michaelc@cs.wisc.edu
      
      hw iscsi like qla4xxx does not allocate a host per session and
      for userspace it is difficult to restart iscsid using the
      "iscsi handles" for the session and connection, so this
      patch just has the class or userspace allocate the id for
      the session and connection.
      
      Note: this breaks userspace and requires users to upgrade to the newest
      open-iscsi tools. Sorry about his but open-iscsi is still too new to
      say we have a stable user-kernel api and we were not good nough
      designers to know that other hw iscsi drivers and iscsid itself would
      need such changes. Actually we sorta did but at the time we did not
      have the HW available to us so we could only guess.
      
      Luckily, the only tools hooking into the class are the open-iscsi ones
      or other tools like iscsitart hook into the open-iscsi engine from
      userspace or prgroams like anaconda call our tools so they are not affected.
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      b5c7a12d
    • Kurt Garloff's avatar
      [SCSI] BLIST_ATTACH_PQ3 flags · 13f7e5ac
      Kurt Garloff authored
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This is patch 3/3:
      3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
         scanning code register PQ3 devices and continues scanning; only sg
         will attach thanks to scsi_bus_match().
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      13f7e5ac
    • Kurt Garloff's avatar
      [SCSI] Better log messages for PQ3 devs · 6c7154c9
      Kurt Garloff authored
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This patch 2/3:
      If a PQ3 device is found, log a message that describes the device
      (INQUIRY DATA and C:B:T:U tuple) and make a suggestion for blacklisting
      it.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      6c7154c9
    • Kurt Garloff's avatar
      [SCSI] Try LUN 1 and use bflags · 4186ab19
      Kurt Garloff authored
      Some devices report a peripheral qualifier of 3 for LUN 0; with the original
      code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
      have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
      Also, the device at LUN 0 (which is not connected according to the PQ) is not
      registered with the OS.
      
      Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
      report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
      most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
      reference for an infamous example.
      
      This is patch 1/3:
      If we end up in sequential scan, at least try LUN 1 for devices
      that reported a PQ of 3 for LUN 0.
      Also return blacklist flags, even for PQ3 devices.
      Signed-off-by: default avatarKurt Garloff <garloff@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4186ab19
  2. 12 Apr, 2006 34 commits