1. 13 2月, 2007 1 次提交
  2. 12 2月, 2007 2 次提交
  3. 11 2月, 2007 1 次提交
    • H
      [SCSI] aic79xx: use dma_get_required_mask() · 19966769
      Hannes Reinecke 提交于
      As originally noted by Frederic Temporelli, the aic79xx supports 64
      bit addressing, but the initialization code of the driver is wrong: it
      tests the available memory size instead of testing the maximum
      available memory address.
      
      This patch uses the correct dma_get_required_mask() macros to
      determine the correct addressing method.
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Cc: Xavier Bru <xavier.bru@bull.net>
      CC: Frederic Temporelli <frederic.temporelli@bull.net>
      
      cosmetic fixes
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      19966769
  4. 10 2月, 2007 3 次提交
  5. 08 2月, 2007 8 次提交
  6. 04 2月, 2007 2 次提交
  7. 03 2月, 2007 8 次提交
    • B
      [SCSI] scsi_error: Fix lost EH commands · 292148f8
      Brian King 提交于
      If an EH command times out today, the LLDD's abort handler
      will be called to abort the command. It is assumed that this
      completes successfully, which can result in the command getting
      completed later resulting in an oops. Improve the current
      implementation by escalating all the way to host reset if
      necessary in order to clean up the EH command.
      Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      292148f8
    • D
    • D
      [SCSI] aic94xx: Remove TMF result code munging · 058e2c47
      Darrick J. Wong 提交于
      In asd_initiate_ssp_tmf, the TMF result code is replaced with
      TMF_RESP_FUNC_FAILED except when the TMF returns a result code immediately.
      However, TMFs can return result codes via an ESCB... yet these codes are
      also replaced with "FAILED".  The only values that can fall into that case
      are TMF_* codes anyway, so get rid of this code where COMPLETE and SUCCESS
      are turned into FAILED.  This also lets us propagate those TMF_* codes up
      to the caller.
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      058e2c47
    • D
      [SCSI] libsas: Add an LU reset mechanism to the error handler · a9344e68
      Darrick J. Wong 提交于
      After discussion with andmike and dougg, it seems that the purpose of
      eh_device_reset_handler is to issue LU resets, and that
      eh_bus_reset_handler would be a more appropriate place for a phy reset.
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a9344e68
    • D
      [SCSI] libsas: Don't BUG when connecting two expanders via wide port · 423f7cf4
      Darrick J. Wong 提交于
      libsas: Don't BUG when connecting two expanders via wide port
      
      When a device is connected to an expander, the discovery process goes through
      sas_ex_discover_dev to figure out what's attached to the phy.  If it is the
      case that the phy being discovered happens to be the second phy of a wide link
      to an expander, that discover_dev function will incorrectly call
      sas_ex_discover_expander, which creates another sas_port and tries to attach the
      other sas_phys to the new port, thus triggering a BUG.  The correct thing to do is
      to check the other ex_phys of the expander to see if there's a sas_port for this
      sas_phy, and attach the sas_phy to the existing sas_port.
      
      This is easily triggered if one enables the phys of a wide port between
      expanders one by one.
      
      This second version of the patch fixes a small regression in the case where
      all the phys show up at once and we accidentally try to attach to a port
      that hasn't been created yet.
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      423f7cf4
    • K
      [SCSI] st: fix Tape dies if wrong block size used, bug 7919 · 9abe16c6
      Kai Makisara 提交于
      On Thu, 1 Feb 2007, Andrew Morton wrote:
      > On Thu, 1 Feb 2007 15:34:29 -0800
      > bugme-daemon@bugzilla.kernel.org wrote:
      >
      > > http://bugzilla.kernel.org/show_bug.cgi?id=7919
      > >
      > >            Summary: Tape dies if wrong block size used
      > >     Kernel Version: 2.6.20-rc5
      > >             Status: NEW
      > >           Severity: normal
      > >              Owner: scsi_drivers-other@kernel-bugs.osdl.org
      > >          Submitter: dmartin@sccd.ctc.edu
      > >
      > >
      > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14
      > >
      > > Other Kernels Tested and Results:
      > >
      > >     OK 2.6.15.7
      > >     OK 2.6.16.37
      > >     OK 2.6.17.14
      > >     BAD 2.6.18.6
      > >     BAD 2.6.18-1.2869.fc6
      > >     BAD 2.6.19.2 +
      > >     BAD 2.6.20-rc5
      > >
      > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are from kernel.org
      > >
      ...
      > > Steps to reproduce:
      > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive,
      > > install a recent kernel
      > > set the tape block size - mt setblk 4096
      > > read from or write to tape using wrong block size - tar -b 7 -cvf /dev/tape foo
      > >
      Write does not trigger this bug because the driver refuses in fixed block
      mode writes that are not a multiple of the block size. Read does trigger
      it in my system.
      
      The bug is not associated with any specific HBA. st tries to do direct i/o
      in fixed block mode with reads that are not a multiple of tape block size.
      
      The patch in this message fixes the st problem by switching to using the
      driver buffer up to the next close of the device file in fixed block mode
      if the user asks for a read like this.
      
      I don't know why the bug has surfaced only after 2.6.17 although the st
      problem is old. There may be another bug in the block subsystem and this
      patch works around it. However, the patch fixes a problem in st and in
      this way it is a valid fix.
      
      This patch may also fix the bug 7900.
      
      The patch compiles and is lightly tested.
      Signed-off-by: NKai Makisara <kai.makisara@kolumbus.fi>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      9abe16c6
    • E
      502c62f1
    • N
      [SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash · 017f2e37
      Nagendra Singh Tomar 提交于
      	sd_probe() calls class_device_add() even before initializing the
      sdkp->device variable. class_device_add() eventually results in the user mode
      udev program to be called. udev program can read the the allow_restart
      attribute of the newly created scsi device. This is resulting in a crash as
      the show function for allow_restart (i.e sd_show_allow_restart) returns the
      attribute value by reading the sdkp->device->allow_restart variable. As the
      sdkp->device is not initialized before calling the user mode hotplug helper,
      this results in a crash.
      	The patch below solves it by calling class_device_add() only after the
      necessary fields in the scsi_disk structure are initialized properly.
      Signed-off-by: NNagendra Singh Tomar <nagendra_tomar@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      017f2e37
  8. 01 2月, 2007 15 次提交