1. 03 4月, 2009 1 次提交
  2. 30 12月, 2008 1 次提交
  3. 09 10月, 2008 1 次提交
  4. 03 5月, 2008 1 次提交
  5. 20 4月, 2008 1 次提交
  6. 19 4月, 2008 1 次提交
  7. 16 4月, 2008 1 次提交
  8. 08 4月, 2008 2 次提交
  9. 12 2月, 2008 2 次提交
  10. 08 2月, 2008 1 次提交
    • S
      [SCSI] aacraid: do not set valid bit in sense information · 8e31e607
      Salyzyn, Mark 提交于
      Luben Tuikov [mailto:ltuikov@yahoo.com] sez:
      > Just as in your case and Tony's case, which I presume
      > uses the same RAID firmware vendor, it would've
      > probably been better if the RAID firmware vendor
      > fixed the firmware to not set the VALID bit if the
      > INFORMATION field is not valid.
      
      Point taken regarding the aacraid driver. Dropped the VALID bit, and
      then did some cleanup/simplification of the set_sense procedure and
      the associated parameters. Mike did some preliminary tests when the
      VALID bit was dropped before the 'Re: [PATCH] [SCSI] sd: make error
      handling more robust' patches came on the scene. The change in the
      SCSI subsystem does make this enclosed aacraid patch unnecessary, so
      this aacraid patch is merely post battle ground cleanup. If the
      simplification is an issue, repugnant, too much for a back-port to the
      stable trees or clouds the point, this patch could be happily
      distilled down to:
      
      diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
      --- a/drivers/scsi/aacraid/aachba.c     2008-02-06 16:26:45.834938955 -0500
      +++ b/drivers/scsi/aacraid/aachba.c     2008-02-06 16:32:01.109035329 -0500
      @@ -865,7 +865,7 @@
                               u32 residue)
       {
      -        sense_buf[0] = 0xF0;    /* Sense data valid, err code 70h (current error) */
      +        sense_buf[0] = 0x70;    /* Sense data invalid, err code 70h (current error) */
               sense_buf[1] = 0;       /* Segment number, always zero */
      
               if (incorrect_length) {
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      8e31e607
  11. 24 1月, 2008 10 次提交
  12. 12 1月, 2008 3 次提交
    • S
      [SCSI] aacraid: fix driver failure with Dell PowerEdge Expandable RAID Controller 3/Di · 94cf6ba1
      Salyzyn, Mark 提交于
      As reported in http://bugzilla.kernel.org/show_bug.cgi?id=3D9133 it was
      discovered that the PERC line of controllers lacked a key 64 bit
      ScatterGather capable SCSI pass-through function. The adapters are still
      capable of 64 bit ScatterGather I/O commands, but these two can not be
      mixed. This problem was exacerbated by the introduction of the SCSI
      Generic access to the DASD physical devices.
      
      The fix for users before this patch is applied is aacraid.dacmode=3D0 on
      the kernel command line to disable 64 bit I/O.
      
      The enclosed patch introduces a new adapter quirk and tries to limp
      along by enabling pass-through in situations where memory is 32 bit
      addressable on 64 bit machines, or disable the pass-through functions
      altogether. I expect that the check for 32 bit addressable memory to be
      controversial in that it can be incorrect in non-Dell non-Intel systems
      that PERC would never be installed under, the alternative is to disable
      pass-through in all cases which could be reported as another regression.
      
      Pass-through is used for SCSI Generic access to the physical devices, or
      for the management applications to properly function.
      
      In systems where this patch has disabled pass-through because it is
      unsupportable in combination with I/O performance, the user can choose
      to enable pass-through by turning off dacmode (aacraid.dacmode=3D0) or
      limiting the discovered kernel memory (mem=3D4G) with an associated loss
      in runtime performance. If we chose instead to turn off 64 bit dacmode
      for the adapters with this quirk, then this would be reported as another
      regression.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      94cf6ba1
    • C
      [SCSI] aacraid: don't assign cpu_to_le32(int) to u8 · f3307f72
      Christoph Hellwig 提交于
      On Wed, Nov 07, 2007 at 01:51:44PM -0500, Salyzyn, Mark wrote:
      > Christoph Hellwig [mailto:hch@infradead.org] sez:
      > > Did anyone run the driver through sparse to see if we have
      > > more issues like this?
      >
      > There are some warnings from sparse, none like this one. I will deal
      > with the warnings ...
      
      Actually there are a lot of endianess warnings, fortunately most of them
      harmless.  The patch below fixes all of them up (including the ones in
      the patch I replied to), except for aac_init_adapter which is really odd
      and I don't know what to do.
      
      [jejb fixed up rejections and checkpatch issues]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NMark Salyzyn <mark_salyzyn@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f3307f72
    • S
      [SCSI] aacraid: forced reset override · f858317d
      Salyzyn, Mark 提交于
      Some of our vendors have requested that our adapters ignore the hardware
      reset attempts during recovery and have enforced this with changes in
      Adapter Firmware. Some of our customers have requested the option to be
      able to reset the adapter under adverse adapter failure, we even had a
      few defects reported here considering it a regression that the Adapter
      could not be reset. This patch addresses this dichotomy. The user can
      force the adapter to be reset if it supports the IOP_RESET_ALWAYS
      command, in cases where the adapter has been programmed to ignore the
      reset, by setting the aacraid.check_reset parameter to a value of -1.
      
      The driver will not reset an Adapter that does not support the reset
      command(s).
      
      This patch also fixes and cleans up some of the logic associated with
      resetting the adapter.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f858317d
  13. 23 10月, 2007 1 次提交
  14. 13 10月, 2007 1 次提交
  15. 28 7月, 2007 1 次提交
    • S
      [SCSI] aacraid: add SCSI SYNCHONIZE_CACHE range checking · b90f90d2
      Salyzyn, Mark 提交于
      Customer running an application that issues SYNCHRONIZE_CACHE calls
      directly noticed the broad stroke of the current implementation in the
      aacraid driver resulting in multiple applications feeding I/O to the
      storage causing the issuing application to stall for long periods of
      time. By only waiting for the current WRITE commands, rather than all
      commands, to complete; and those that are in range of the
      SYNCHRONIZE_CACHE call that would associate more tightly with the
      issuing application before telling the Firmware to flush it's dirty
      cache, we managed to reduce the stalling. The Firmware itself still
      flushes all the dirty cache associated with the array ignoring the
      range, it just does so in a more timely manner.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      b90f90d2
  16. 27 7月, 2007 1 次提交
  17. 19 7月, 2007 2 次提交
    • S
      [SCSI] aacraid: add vpd to inquiry · 88e2f98e
      Salyzyn, Mark 提交于
      Report VPD inquiry page 0x80 with an unique array creation serial
      number (CUID). When an array is created, the metadata stored on the
      physical drives gets an unique serial number. This serial number
      remains constant through array morphing or migration to other
      controllers.  This patch is a forward port and modification to survive
      morphing and migration operations, of a similar piece of
      (un-attributed author) code added to the SLES10 SP1 aacraid driver.
      
      To test the results of the patch, observe that /dev/disk/by-id/
      entries will show up for the arrays resulting from the udev rules.
      Also, as per the udev rules, 'scsi_id -g -x -a -s /block/sd? -d
      /dev/sd?'  will report the ID_SERIAL as constructed from the inquiry
      data.
      
      It was reported to me that the 'ADPT' leading the serial number was bad
      form, that the inquiry vendor field was enough to differentiate the
      storage uniquely. Subsequent search found that another Adaptec AAC based
      driver reported the 8 hex serial number only without such adornments, so
      dropped ADPT to match. Resubmitting the patch with this alteration.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      88e2f98e
    • S
      [SCSI] aacraid: correct valid container response in management ioctl · fd622b1b
      Salyzyn, Mark 提交于
      During an Adapter Initiated scan request, the query disk ioctl reports a
      value of 2 rather than 1 for the valid field. This presents a problem
      for some legacy management applications.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      fd622b1b
  18. 20 6月, 2007 2 次提交
  19. 18 6月, 2007 3 次提交
  20. 23 5月, 2007 1 次提交
    • S
      [SCSI] aacraid: apply commit config for reset_devices flag · 1208bab5
      Salyzyn, Mark 提交于
      Under some conditions associated with the unclean transition to kdump,
      the aacraid adapters will view the array as foreign and not export it to
      prevent access and data manipulation. The solution is to submit a commit
      configuration to export the devices since this is a expected behavior
      when transitioning to a kdump kernel.
      
      This patch adds the aacraid.reset_devices flag and when either this or
      the global reset_devices flag is set, ensures that a commit config is
      issued and extends the startup_timeout if it is set less than 5 minutes.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      1208bab5
  21. 22 5月, 2007 1 次提交
    • S
      [SCSI] aacraid: add support for FUA · 9d399cc7
      Salyzyn, Mark 提交于
      Back in the beginning of last year we disabled mode page 8 and mode page
      3f requests through device quirk bits instead of enhancing the driver to
      respond to these mode pages because there was no apparent added value.
      
      The Firmware that supports the new communication commands supports the
      ability to force a write around of the adapter cache on a command by
      command basis. In the attached patch we enable mode page 8 and 3f and
      spoof the results as needed in order to *convince* the layers above to
      submit writes with the FUA (Force Unit Attention) bit set if the file
      system or application requires it, if the Firmware supports the write
      through, or instead to submit a SYNCHRONIZE_CACHE if the Firmware does
      not. The added value here is for file systems that benefit from this
      functionality and for clustering or redundancy scenarios.
      
      Caveats: By convince, we are responding with a minimal short 3 byte
      content mode page 8, with only the data the SCSI layer needs and that we
      can fill confidently. Applications that require the customarily larger
      mode page 8 results may be confused by this(?). The FUA, or the
      SYNCHRONIZE_CACHE only affect the cache on the controller. Our firmware
      by default ensure that the underlying physical drives of the array have
      their cache turned off so normally this is not a problem.
      
      This attached patch is against current scsi-misc-2.6 and was unit tested
      on RHEL5. Since this is a feature enhancement, it should not be
      considered for any current stabilization efforts.
      Signed-off-by: NMark Salyzyn <aacraid@adaptec.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      9d399cc7
  22. 17 5月, 2007 1 次提交
    • J
      [SCSI] aacraid: fix panic on short Inquiry · cab537d6
      James Bottomley 提交于
      Unable to handle kernel paging request at ffff8101c0000000 RIP:
       [<ffffffff880b22a1>] :aacraid:aac_internal_transfer+0xd6/0xe3
      PGD 8063 PUD 0
      Oops: 0000 [1] SMP
      last sysfs file: /block/sdb/removable
      CPU 2
      Modules linked in: autofs4(U) hidp(U) nfs(U) lockd(U)
      fscache(U) nfs_acl(U) rfcomm(U) l2cap(U) bluetooth(U)
      sunrpc(U) ipv6(U) cpufreq_ondemand(U) dm_mirror(U) dm_mod(U)
      video(U) sbs(U) i2c_ec(U) button(U) battery(U) asus_acpi(U)
      acpi_memhotplug(U) ac(U) parport_pc(U) lp(U) parport(U)
      joydev(U) ide_cd(U) i2c_i801(U) i2c_core(U) shpchp(U)
      cdrom(U) bnx2(U) sg(U) pcspkr(U) ata_piix(U) libata(U)
      aacraid(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U) ehci_hcd(U)
      ohci_hcd(U) uhci_hcd(U)
      Pid: 2352, comm: syslogd Not tainted 2.6.18-prep #1
      RIP: 0010:[<ffffffff880b22a1>]  [<ffffffff880b22a1>] :aacraid:aac_internal_transfer+0xd6/0xe3
      RSP: 0000:ffff8101bfd1fe68  EFLAGS: 00010083
      RAX: 0000000000000063 RBX: 0000000000000008 RCX: 00000000ffd1fea0
      RDX: ffffffff802da628 RSI: ffff8101c0000000 RDI: ffff8101b2a08168
      RBP: ffff8101b2728010 R08: ffffffff802da628 R09: 0000000000000046
      R10: 0000000000000000 R11: 0000000000000080 R12: 0000000000000010
      R13: ffff8101bfd1fea8 R14: ffff8101bc74df58 R15: ffff8101bc74df58
      FS:  00002aaaab0146f0(0000) GS:ffff8101bfcd2e40(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: ffff8101c0000000 CR3: 00000001bdecd000 CR4: 00000000000006e0
      Process syslogd (pid: 2352, threadinfo ffff8101bc74c000, task ffff8101bd979040)
      Stack:  0000000000000012 0000000000000036 0000000000000000 ffff8101bee9a800
       ffff8101be9d3a00 ffff8101be9d3a00 ffff8101be8014f8 ffffffff880b26cc
       40212227607e3141 2029282a26252423 0000000000000003 ffff810037e3a000
      Call Trace:
       <IRQ [<ffffffff880b26cc>] :aacraid:get_container_name_callback+0x8b/0xb5
       [<ffffffff880b6f67>] :aacraid:aac_intr_normal+0x1b3/0x1f9
       [<ffffffff880b8007>] :aacraid:aac_rkt_intr+0x37/0x115
       [<ffffffff80099749>] __rcu_process_callbacks+0xf8/0x1a8
       [<ffffffff80010705>] handle_IRQ_event+0x29/0x58
       [<ffffffff800b2fe0>] __do_IRQ+0xa4/0x105
       [<ffffffff80011c19>] __do_softirq+0x5e/0xd5
       [<ffffffff8006a193>] do_IRQ+0xe7/0xf5
       [<ffffffff8005b649>] ret_from_intr+0x0/0xa
      
      On digging into it, it turned out that the customer was probing an
      aacraid device with an INQUIRY of 8 bytes.  The way aacraid works, it
      was blindly trying to use aac_internal_transfer to copy the container
      name to byte 16 of the inquiry data, resulting in a negative transfer
      length.  It then copies over the whole of kernel memory before
      dropping off the end.
      
      Fix updated and corrected by Mark Salyzyn
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      cab537d6
  23. 18 4月, 2007 1 次提交