1. 05 9月, 2005 4 次提交
  2. 31 8月, 2005 3 次提交
    • J
      [SCSI] embryonic RAID class · 61a7afa2
      James Bottomley 提交于
      The idea behind a RAID class is to provide a uniform interface to all
      RAID subsystems (both hardware and software) in the kernel.
      
      To do that, I've made this class a transport class that's entirely
      subsystem independent (although the matching routines have to match per
      subsystem, as you'll see looking at the code).  I put it in the scsi
      subdirectory purely because I needed somewhere to play with it, but it's
      not a scsi specific module.
      
      I used a fusion raid card as the test bed for this; with that kind of
      card, this is the type of class output you get:
      
      jejb@titanic> ls -l /sys/class/raid_devices/20\:0\:0\:0/
      total 0
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 component-0 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:0/20:1:0:0/
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 component-1 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:1/20:1:1:0/
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 device -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:0:0/20:0:0:0/
      -r--r--r--  1 root root 16384 Aug 16 17:21 level
      -r--r--r--  1 root root 16384 Aug 16 17:21 resync
      -r--r--r--  1 root root 16384 Aug 16 17:21 state
      
      So it's really simple: for a SCSI device representing a hardware raid,
      it shows the raid level, the array state, the resync % complete (if the
      state is resyncing) and the underlying components of the RAID (these are
      exposed in fusion on the virtual channel 1).
      
      As you can see, this type of information can be exported by almost
      anything, including software raid.
      
      The more difficult trick, of course, is going to be getting it to
      perform configuration type actions with writable attributes.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      61a7afa2
    • J
      [SCSI] attribute container final klist fixes · 2b7d6a8c
      James Bottomley 提交于
      Since the attribute container deletes from a klist while it's walking
      it, it is vulnerable to the problem (and fix) here:
      
      http://marc.theaimsgroup.com/?l=linux-scsi&m=112485448830217
      
      The attached fixes this (but won't compile without the above).
      
      It also fixes the logical reversal in the traversal loop which meant
      that we were never actually traversing the loop to hit this bug in the
      first place.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      2b7d6a8c
    • J
      [SCSI] correct attribute_container list usage · 53c165e0
      James Bottomley 提交于
      One of the changes in the attribute_container code in the scsi-misc tree
      was to add a lock to protect the list of devices per container.  This,
      unfortunately, leads to potential scheduling while atomic problems if
      there's a sleep in the function called by a trigger.
      
      The correct solution is to use the kernel klist infrastructure instead
      which allows lockless traversal of a list.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      53c165e0
  3. 29 8月, 2005 7 次提交
  4. 15 8月, 2005 5 次提交
  5. 13 8月, 2005 12 次提交
  6. 10 8月, 2005 1 次提交
  7. 09 8月, 2005 2 次提交
  8. 08 8月, 2005 3 次提交
    • J
      [SCSI] add global timeout to the scsi mid-layer · b21a4138
      James Bottomley 提交于
      There are certain rogue devices (and the aic7xxx driver) that return
      BUSY or QUEUE_FULL forever.  This code will apply a global timeout (of
      the total number of retries times the per command timer) to a given
      command.  If it is exceeded, the command is completed regardless of its
      state.
      
      The patch also removes the unused field in the command: timeout and
      timeout_total.
      
      This solves the problem of detecting an endless loop in the mid-layer
      because of BUSY/QUEUE_FULL bouncing, but will not recover the device.
      In the aic7xxx case, the driver can be recovered by sending a bus reset,
      so possibly this should be tied into the error handler?
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b21a4138
    • K
      [SCSI] drivers/scsi/st.c: add reference count and related fixes · f03a5670
      Kai Makisara 提交于
      I have rediffed the patch against 2.6.13-rc5, done a couple of cosmetic
      cleanups, and run some tests.  Brian King has acknowledged that it fixes the
      problems he has seen. Seems mature enough for inclusion into 2.6.14 (or
      later)?
      
      Nate's explanation of the changes:
      
      I've attached patches against 2.6.13rc2. These are basically identical
      to my earlier patches, as I found that all issues I'd seen in earlier
      kernels still existed in this kernel.
      
      To summarize, the changes are: (more details in my original email)
      
      - add a kref to the scsi_tape structure, and associate reference
      counting stuff
      
      - set sr_request->end_io = blk_end_sync_rq so we get notified when an IO
      is rejected when the device goes away
      
      - check rq_status when IOs complete, else we don't know that IOs
      rejected for a dead device in fact did not complete
      
      - change last_SRpnt so it's set before an async IO is issued (in case
      st_sleep_done is bypassed)
      
      - fix a bogus use of last_SRpnt in st_chk_result
      Signed-off-by: NNate Dailey <nate.dailey@stratus.com>
      Signed-off-by: NKai Makisara <kai.makisara@kolumbus.fi>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      f03a5670
    • J
      [SCSI] aacraid: correct use of cmd->timeout field · 5262d085
      James Bottomley 提交于
      The cmd->timeout field has been obsolete for a while now.  While looking
      to remove it, I came across this use in the aacraid driver.  It looks
      like you want to initialise the firmware with the current timeout of the
      command (in seconds), so the value I think you should be using is
      cmd->timeout_per_command.
      
      Acked by: Mark Haverkamp <markh@osdl.org>
      Acked by: Mark Salyzyn <mark_salyzyn@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      5262d085
  9. 07 8月, 2005 1 次提交
    • A
      [SCSI] aic79xx: needs to select SPI_TRANSPORT_ATTRS · a2ae85df
      akpm@osdl.org 提交于
      without it you get this failure:
      
      drivers/built-in.o(.text+0xdcccd): In function `ahd_linux_slave_configure':
      drivers/scsi/aic7xxx/aic79xx_osm.c:636: undefined reference to `spi_dv_device'
      drivers/built-in.o(.text+0xdd7b1): In function `ahd_send_async':
      drivers/scsi/aic7xxx/aic79xx_osm.c:1652: undefined reference to `spi_display_xfer_agreement'
      drivers/built-in.o(.init.text+0x7b4d): In function `ahd_linux_init':
      drivers/scsi/aic7xxx/aic79xx_osm.c:2765: undefined reference to `spi_attach_transport'
      drivers/built-in.o(.init.text+0x7c94):drivers/scsi/aic7xxx/aic79xx_osm.c:2774: undefined reference to `spi_release_transport'
      drivers/built-in.o(.exit.text+0x72c): In function `ahd_linux_exit':
      drivers/scsi/aic7xxx/aic79xx_osm.c:2783: undefined reference to `spi_release_transport'
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a2ae85df
  10. 06 8月, 2005 2 次提交
    • M
      [SCSI] aacraid: sgraw command support · 0e68c003
      Mark Haverkamp 提交于
      Received from Mark Salyzyn from Adaptec:
      
      This patch adds support for the new raw io command. This new command
      offers much larger io commands, is more friendly to the internal firmware
      structure requiring less translation efforts by the firmware and offers
      support for targets greater than 2TB (patch to support >2TB will
      be sent in the future).
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      0e68c003
    • M
      [SCSI] aacraid: aif registration timeout fix · 12a26d08
      Mark Haverkamp 提交于
      Received from Mark Salyzyn from Adaptec:
      
      If the Adapter is quiet and does not produce an AIF event packets to be
      picked up by the management applications for longer than the timeout
      interval of two minutes, the cleanup code that deals with aging out
      registrants could erroneously drop the registration. The timeout is
      there to clean up should the management application die and fail to poll
      for updated AIF event packets.
      
      Moving the timer update from the ioctl code that delivers an AIF to the
      polling registrant to the bottom of the ioctl means the timeout is reset
      with any management application polling activity regardless if an AIF is
      delivered or not removing the erroneous timeout cleanups.
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      12a26d08