1. 15 4月, 2006 10 次提交
    • J
      Merge ../scsi-rc-fixes-2.6 · 84d891d6
      James Bottomley 提交于
      Conflicts:
      
      	include/scsi/scsi_devinfo.h
      
      Same number for two BLIST flags:  BLIST_MAX_512 and BLIST_ATTACH_PQ3
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      84d891d6
    • J
      [SCSI] scsi_transport_sas: don't scan a non-existent end device · 7676f83a
      James Bottomley 提交于
      Any end device that can't support any of the scanning protocols
      shouldn't be scanned, so set its id to -1 to prevent
      scsi_scan_target() being called for it.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      7676f83a
    • M
      [SCSI] iscsi: convert iscsi tcp to libiscsi · 5bb0b55a
      Mike Christie 提交于
      This just converts iscsi_tcp to the lib
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      5bb0b55a
    • M
      [SCSI] iscsi: add libiscsi · 7996a778
      Mike Christie 提交于
      There is a lot of code duplcited between iscsi_tcp
      and the upcoming iscsi_iser driver. This patch puts
      the duplicated code in a lib. There is more code
      to move around but this takes care of the
      basics. For iscsi_offload if they use the lib we will
      probably move some things around. For example in the
      queuecommand we will not assume that the LLD wants
      to do queue_work, but it is better to handle that
      later when we know for sure what iscsi_offload looks
      like (we could probably do this for iscsi_iser though to).
      
      Ideally I would like to get the iscsi_transports modules
      to a place where all they really have to do is put data
      on the wire, but how to do that will hopefully be more clear
      when we see other modules like iscsi_offload. Or maybe
      iscsi_offload will not use the lib and it will just be
      iscsi_iser and iscsi_tcp and maybe the iscsi_tcp_tgt if that
      is allowed in mainline.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      7996a778
    • M
      [SCSI] iscsi: fix up iscsi eh · 30a6c652
      Mike Christie 提交于
      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: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      30a6c652
    • M
      [SCSI] iscsi: add sysfs attrs for uspace sync up · fd7255f5
      Mike Christie 提交于
      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: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      fd7255f5
    • M
      [SCSI] iscsi: rm kernel iscsi handles usage for session and connection · b5c7a12d
      Mike Christie 提交于
      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: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b5c7a12d
    • K
      [SCSI] BLIST_ATTACH_PQ3 flags · 13f7e5ac
      Kurt Garloff 提交于
      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: NKurt Garloff <garloff@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      13f7e5ac
    • K
      [SCSI] Better log messages for PQ3 devs · 6c7154c9
      Kurt Garloff 提交于
      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: NKurt Garloff <garloff@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6c7154c9
    • K
      [SCSI] Try LUN 1 and use bflags · 4186ab19
      Kurt Garloff 提交于
      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: NKurt Garloff <garloff@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      4186ab19
  2. 14 4月, 2006 7 次提交
    • M
      [SCSI] mptfusion - fix panic in mptsas_slave_configure · 3c0c25b9
      Moore, Eric 提交于
      Driver panic when RAID logical volume was present when driver
      loaded, or when a RAID logical volume was created on the fly.
      
      This issue was created in due to recent scsi_transport_sas change,
      when sas_read_port_mode_page was added into the mptsas drivers
      slave_config entry point.
      
      This new API expects that all sdev's to be assocated to an rphy, however
      that is not the case for logical volumes, as they are created using
      scsi_add_device, instead of sas_rphy_add().
      Signed-off-by: NEric Moore <Eric.Moore@lsil.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3c0c25b9
    • A
      [SCSI] 3ware 9000 disable local irqs during kmap_atomic · 1e08dcb3
      adam radford 提交于
      Equivalent of the same patch for the 3w-xxxx driver.
      Signed-off-by: NAdam Radford <linuxraid@amcc.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      1e08dcb3
    • T
      [SCSI] SCSI: fix scsi_kill_request() busy count handling · e36e0c80
      Tejun Heo 提交于
      scsi_kill_request() completes requests via normal SCSI completion path
      which decrements busy counts; however, requests which get passed to
      scsi_kill_request() aren't holding busy counts and scsi_kill_request()
      don't increment them before invoking completion path resulting in
      incorrect busy counts.  Bump up busy counts before invoking completion
      path.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      e36e0c80
    • J
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      James Smart 提交于
      As previously reported via Michael Reed, the FC transport took a hit
      in 2.6.15 (perhaps a little earlier) when we solved a recursion error.
      There are 2 deadlocks occurring:
      - With scan and the delete items sharing the same workq, flushing the
        workq for the delete code was getting it stalled behind a very long
        running scan code path.
      - There's a deadlock where scsi_remove_target() has to sit behind
        scsi_scan_target() due to contention over the scan_lock().
      
      This patch resolves the 1st deadlock and significantly reduces the
      odds of the second. So far, we have only replicated the 2nd deadlock
      on a highly-parallel SMP system. More on the 2nd deadlock in a following
      email.
      
      This patch reworks the transport to:
      - Only use the scsi host workq for scanning
      - Use 2 other workq's internally. One for deletions, the other for
        scheduled deletions. Originally, we tried this with a single workq,
        but the occassional flushes of the scheduled queues was hitting the
        second deadlock with a slightly higher frequency. In the future, we'll
        look at the LLDD's and the transport to see if we can get rid of this
        extra overhead.
      - When moving to the other workq's we tightened up some object states
        and some lock handling.
      - Properly syncs adds/deletes
      - minor code cleanups
        - directly reference fc_host_attrs, rather than through attribute
          macros
        - flush the right workq on delayed work cancel failures.
      
      Large kudos to Michael Reed who has been working this issue for the last
      month.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      aedf3497
    • H
      [SCSI] aic79xx: target hotplug fixes · b0d23648
      Hannes Reinecke 提交于
      When a target is added aic79xx tries to be overly clever: it changes
      the command on the fly to TEST UNIT READY and tries to requeue the
      original command. Sadly this breaks SCSI compability and of course
      the midlayer is getting a bit confused by it.
      
      So we're just removing that bit of code and let the midlayer deal with
      it. It's clever enough by now. And the driver code is getting simpler.
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b0d23648
    • F
      [SCSI] ibmvscsi: remove drivers/scsi/ibmvscsi/srp.h · 441f987c
      FUJITA Tomonori 提交于
      It's no longer needed after the convrsion to use the linux srp.h file.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      441f987c
    • H
      [SCSI] aic79xx bus reset update · f41b5cec
      Hannes Reinecke 提交于
      As James B. correctly noted, ahd_reset_channel() in
      ahd_linux_bus_reset() should be protected by ahd_lock().  However, the
      main reason for not doing so was a deadlock with the interesting
      polling mechanism to detect the end a bus reset.
      
      This patch replaces the polling mechanism with a saner signalling via
      flags; it also gives us the benefit of detecting any multiple calls to
      ahd_reset_channel().
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      f41b5cec
  3. 13 4月, 2006 23 次提交