1. 20 May, 2006 12 commits
  2. 10 May, 2006 6 commits
  3. 20 Apr, 2006 1 commit
  4. 15 Apr, 2006 1 commit
  5. 14 Apr, 2006 13 commits
    • Guennadi Liakhovetski's avatar
      [SCSI] dc395x: dynamically map scatter-gather for PIO · cdb8c2a6
      Guennadi Liakhovetski authored
      The current dc395x driver uses PIO to transfer up to 4 bytes which do not
      get transferred by DMA (under unclear circumstances). For this the driver
      uses page_address() which is broken on highmem. Apart from this the
      actual calculation of the virtual address is wrong (even without highmem).
      So, e.g., for reading it reads bytes from the driver to a wrong address
      and returns wrong data, I guess, for writing it would just output random
      data to the device.
      
      The proper fix, as suggested by many, is to dynamically map data using
      kmap_atomic(page, KM_BIO_SRC_IRQ) / kunmap_atomic(virt). The reason why it
      has not been done until now, although I've done some preliminary patches
      more than a year ago was that nobody interested in fixing this problem was
      able to reliably reproduce it. Now it changed - with the help from
      Sebastian Frei (CC'ed) I was able to trigger the PIO path. Thus, I was
      also able to test and debug it.
      
      There are 4 cases when PIO is used in dc395x - data-in / -out with and
      without scatter-gather. I was able to reproduce and test only data-in with
      and without SG. So, the data-out path is still untested, but it is also
      somewhat simpler than the data-in. Fredrik Roubert (also CC'ed) also had
      PIO triggering on his system, and in his case it was data-out without SG.
      It would be great if he could test the attached patch on his system, but
      even if he cannot, I would still request to apply the patch and just wait
      if anybody cries...
      
      Implementation: I put 2 new functions in scsi_lib.c and their declarations
      in scsi_cmnd.h. I exported them without _GPL, although, I don't feel
      strongly about that - not many drivers are likely to use them. But there
      is at least one more - I want to use them in tmscsim.c. Whether these are
      the right files for the functions and their declarations - not sure
      either. Actually, they are not scsi-specific, so, might go somewhere
      around other scattergather magic? They are not platform specific either,
      and most SG functions are defined under arch/*/... As these issues were
      discussed previously there were some more routines suggested to manipulate
      scattergather buffers, I think, some of them were needed around
      crypto code... So, might be a common place reasonable, like
      lib/scattergather.c? I am open here.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      cdb8c2a6
    • FUJITA Tomonori's avatar
      [SCSI] ibmvscsi: convert kmalloc + memset to kcalloc · 4c021dd1
      FUJITA Tomonori authored
      Convert kmalloc + memset to kcalloc in ibmvscsi
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: default avatarDave Boutcher <sleddog@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4c021dd1
    • James Bottomley's avatar
      Merge ../scsi-rc-fixes-2.6 · 84d891d6
      James Bottomley authored
      Conflicts:
      
      	include/scsi/scsi_devinfo.h
      
      Same number for two BLIST flags:  BLIST_MAX_512 and BLIST_ATTACH_PQ3
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      84d891d6
    • James Bottomley's avatar
      [SCSI] scsi_transport_sas: don't scan a non-existent end device · 7676f83a
      James Bottomley authored
      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: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      7676f83a
    • Mike Christie's avatar
      [SCSI] iscsi: convert iscsi tcp to libiscsi · 5bb0b55a
      Mike Christie authored
      This just converts iscsi_tcp to the lib
      Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      5bb0b55a
    • Mike Christie's avatar
      [SCSI] iscsi: add libiscsi · 7996a778
      Mike Christie authored
      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: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      7996a778
    • 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
    • Moore, Eric's avatar
      [SCSI] mptfusion - fix panic in mptsas_slave_configure · 3c0c25b9
      Moore, Eric authored
      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: default avatarEric Moore <Eric.Moore@lsil.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      3c0c25b9
  6. 13 Apr, 2006 7 commits
    • adam radford's avatar
      [SCSI] 3ware 9000 disable local irqs during kmap_atomic · 1e08dcb3
      adam radford authored
      Equivalent of the same patch for the 3w-xxxx driver.
      Signed-off-by: default avatarAdam Radford <linuxraid@amcc.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      1e08dcb3
    • Tejun Heo's avatar
      [SCSI] SCSI: fix scsi_kill_request() busy count handling · e36e0c80
      Tejun Heo authored
      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: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e36e0c80
    • James Smart's avatar
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      James Smart authored
      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: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      aedf3497
    • Hannes Reinecke's avatar
      [SCSI] aic79xx: target hotplug fixes · b0d23648
      Hannes Reinecke authored
      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: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      b0d23648
    • FUJITA Tomonori's avatar
      [SCSI] ibmvscsi: remove drivers/scsi/ibmvscsi/srp.h · 441f987c
      FUJITA Tomonori authored
      It's no longer needed after the convrsion to use the linux srp.h file.
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      441f987c
    • Hannes Reinecke's avatar
      [SCSI] aic79xx bus reset update · f41b5cec
      Hannes Reinecke authored
      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: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      f41b5cec
    • James Bottomley's avatar
      [SCSI] add SCSI_UNKNOWN and LUN transfer limit restrictions · 4d7db04a
      James Bottomley authored
      Original From: Ingo Flaschberger <if@xip.at>
      
      To support the RA4100 array from Compaq.
      
      This patch now correctly handles SCSI_UNKNOWN types with regard to
      BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't).
      
      It also allows a BLIST_MAX_512 flag to restrict the maximum transfer
      length to 512 blocks (apparently this is an RA4100 problem).
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4d7db04a