1. 06 May, 2015 1 commit
  2. 10 May, 2013 1 commit
    • James Bottomley's avatar
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley authored
      These enums have been separate since the dawn of SAS, mainly because the
      latter is a procotol only enum and the former includes additional state
      for libsas.  The dichotomy causes endless confusion about which one you
      should use where and leads to pointless warnings like this:
      
      drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
      drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]
      
      Fix by eliminating one of them.  The one kept is effectively the sas.h
      one, but call it sas_device_type and make sure the enums are all
      properly namespaced with the SAS_ prefix.
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  3. 15 Apr, 2013 1 commit
  4. 22 Feb, 2013 1 commit
  5. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      Drivers: scsi: remove __dev* attributes. · 6f039790
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Adam Radford <linuxraid@lsi.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f039790
  6. 30 Nov, 2012 1 commit
  7. 14 Sep, 2012 1 commit
    • Jianpeng Ma's avatar
      [SCSI] mvsas: Fix oops when ata commond timeout. · 95ab0003
      Jianpeng Ma authored
      Kernel message follows:
      
      [  511.712011] sd 11:0:0:0: [sdf] command ffff8800a4e81400 timed out
      [  511.712022] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
      [  511.712024] sas: trying to find task 0xffff8800a4d24c80
      [  511.712026] sas: sas_scsi_find_task: aborting task 0xffff8800a4d24c80
      [  511.712029] drivers/scsi/mvsas/mv_sas.c 1631:mvs_abort_task()
      mvi=ffff8800b5300000 task=ffff8800a4d24c80 slot=ffff8800b5325038
      slot_idx=x0
      [  511.712035] BUG: unable to handle kernel NULL pointer dereference at
      0000000000000058
      [  511.712040] IP: [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30
      [  511.712047] PGD 0
      [  511.712049] Oops: 0002 [#1] SMP
      [  511.712052] Modules linked in: mvsas libsas scsi_transport_sas
      raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq
      async_tx [last unloaded: mvsas]
      [  511.712062] CPU 3
      [  511.712066] Pid: 7322, comm: scsi_eh_11 Not tainted 3.5.0+ #106 To Be
      Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
      [  511.712068] RIP: 0010:[<ffffffff815f8c0c>]  [<ffffffff815f8c0c>]
      _raw_spin_lock_irqsave+0xc/0x30
      [  511.712073] RSP: 0018:ffff880098d3bcb0  EFLAGS: 00010086
      [  511.712074] RAX: 0000000000000286 RBX: 0000000000000058 RCX:
      00000000000000c3
      [  511.712076] RDX: 0000000000000100 RSI: 0000000000000046 RDI:
      0000000000000058
      [  511.712078] RBP: ffff880098d3bcb0 R08: 000000000000000a R09:
      0000000000000000
      [  511.712080] R10: 00000000000004e8 R11: 00000000000004e7 R12:
      ffff8800a4d24c80
      [  511.712082] R13: 0000000000000050 R14: ffff8800b5325038 R15:
      ffff8800a4eafe00
      [  511.712084] FS:  0000000000000000(0000) GS:ffff8800bdb80000(0000)
      knlGS:0000000000000000
      [  511.712086] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  511.712088] CR2: 0000000000000058 CR3: 00000000a4ce6000 CR4:
      00000000000407e0
      [  511.712090] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
      0000000000000000
      [  511.712091] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
      0000000000000400
      [  511.712093] Process scsi_eh_11 (pid: 7322, threadinfo
      ffff880098d3a000, task ffff8800a61dde40)
      [  511.712095] Stack:
      [  511.712096]  ffff880098d3bce0 ffffffff81060683 ffff880000000000
      0000000000000000
      [  511.712099]  ffff8800a4d24c80 ffff8800b5300000 ffff880098d3bcf0
      ffffffffa0076a88
      [  511.712102]  ffff880098d3bd50 ffffffffa0079bb5 ffff880000000000
      ffff880000000018
      [  511.712106] Call Trace:
      [  511.712110]  [<ffffffff81060683>] complete+0x23/0x60
      [  511.712115]  [<ffffffffa0076a88>] mvs_tmf_timedout+0x18/0x20 [mvsas]
      [  511.712119]  [<ffffffffa0079bb5>] mvs_slot_complete+0x765/0x7d0
      [mvsas]
      [  511.712125]  [<ffffffffa005a17d>] sas_scsi_recover_host+0x55d/0xdb0
      [libsas]
      [  511.712128]  [<ffffffff8106d600>] ? idle_balance+0xe0/0x130
      [  511.712133]  [<ffffffff813b150c>] scsi_error_handler+0xcc/0x470
      [  511.712136]  [<ffffffff815f7ad0>] ? __schedule+0x370/0x730
      [  511.712139]  [<ffffffff8105f728>] ? __wake_up_common+0x58/0x90
      [  511.712142]  [<ffffffff813b1440>] ? scsi_eh_get_sense+0x110/0x110
      [  511.712146]  [<ffffffff810571be>] kthread+0x8e/0xa0
      [  511.712150]  [<ffffffff816015f4>] kernel_thread_helper+0x4/0x10
      [  511.712153]  [<ffffffff81057130>] ? flush_kthread_work+0x120/0x120
      [  511.712156]  [<ffffffff816015f0>] ? gs_change+0xb/0xb
      [  511.712157] Code: 8a 00 01 00 00 89 d0 f0 66 0f b1 0f 66 39 d0 0f 94
      c0 0f b6 c0 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 fa ba 00 01
      00 00 <f0> 66 0f c1 17 0f b6 ce 38 d1 74 11 0f 1f 84 00 00 00 00 00 f3
      [  511.712191] RIP  [<ffffffff815f8c0c>] _raw_spin_lock_irqsave+0xc/0x30
      [  511.712194]  RSP <ffff880098d3bcb0>
      [  511.712196] CR2: 0000000000000058
      [  511.712198] ---[ end trace a781c7b1e65db92c ]---
      Signed-off-by: default avatarJianpeng Ma <majianpeng@gmail.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      95ab0003
  8. 20 Jul, 2012 2 commits
  9. 20 Mar, 2012 1 commit
  10. 29 Feb, 2012 2 commits
    • Dan Williams's avatar
      [SCSI] libsas: async ata scanning · 9508a66f
      Dan Williams authored
      libsas ata error handling is already async but this does not help the
      scan case.  Move initial link recovery out from under host->scan_mutex,
      and delay synchronization with eh until after all port probe/recovery
      work has been queued.
      
      Device ordering is maintained with scan order by still calling
      sas_rphy_add() in order of domain discovery.
      
      Since we now scan the domain list when invoking libata-eh we need to be
      careful to check for fully initialized ata ports.
      Acked-by: default avatarJack Wang <jack_wang@usish.com>
      Acked-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      9508a66f
    • Dan Williams's avatar
      [SCSI] libsas: fix sas_find_local_phy(), take phy references · f41a0c44
      Dan Williams authored
      In the direct-attached case this routine returns the phy on which this
      device was first discovered.  Which is broken if we want to support
      wide-targets, as this phy reference can become stale even though the
      port is still active.
      
      In the expander-attached case this routine tries to lookup the phy by
      scanning the attached sas addresses of the parent expander, and BUG_ONs
      if it can't find it.  However since eh and the libsas workqueue run
      independently we can still be attempting device recovery via eh after
      libsas has recorded the device as detached.  This is even easier to hit
      now that eh is blocked while device domain rediscovery takes place, and
      that libata is fed more timed out commands increasing the chances that
      it will try to recover the ata device.
      
      Arrange for dev->phy to always point to a last known good phy, it may be
      stale after the port is torn down, but it will catch up for wide port
      reconfigurations, and never be NULL.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      f41a0c44
  11. 19 Feb, 2012 3 commits
    • Dan Williams's avatar
      [SCSI] libsas: remove ata_port.lock management duties from lldds · 312d3e56
      Dan Williams authored
      Each libsas driver (mvsas, pm8001, and isci) has invented a different
      method for managing the ap->lock.  The lock is held by the ata
      ->queuecommand() path.  mvsas drops it prior to acquiring any internal
      locks which allows it to hold its internal lock across calls to
      task->task_done().  This capability is important as it is the only way
      the driver can flush task->task_done() instances to guarantee that it no
      longer has any in-flight references to a domain_device at
      ->lldd_dev_gone() time.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      312d3e56
    • Dan Williams's avatar
      [SCSI] libsas: introduce sas_drain_work() · b1124cd3
      Dan Williams authored
      When an lldd invokes ->notify_port_event() it can trigger a chain of libsas
      events to:
      
        1/ form the port and find the direct attached device
      
        2/ if the attached device is an expander perform domain discovery
      
      A call to flush_workqueue() will only flush the initial port formation work.
      Currently libsas users need to call scsi_flush_work() up to the max depth of
      chain (which will grow from 2 to 3 when ata discovery is moved to its own
      discovery event).  Instead of open coding multiple calls switch to use
      drain_workqueue() to flush sas work.
      
      drain_workqueue() does not handle new work submitted during the drain so
      libsas needs a bit of infrastructure to hold off unchained work submissions
      while a drain is in flight.  A lldd ->notify() event is considered 'unchained'
      while a sas_discover_event() is 'chained'.  As Tejun notes:
      
        "For now, I think it would be best to add private wrapper in libsas to
         support deferring unchained work items while draining."
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      b1124cd3
    • Dan Williams's avatar
      [SCSI] libsas: kill sas_slave_destroy · 6f4e75a4
      Dan Williams authored
      Per commit 3e4ec344 "libata: kill ATA_FLAG_DISABLED" needing to set
      ATA_DEV_NONE is a holdover from before libsas converted to the
      "new-style" ata-eh.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      6f4e75a4
  12. 31 Oct, 2011 1 commit
    • Robin H. Johnson's avatar
      [SCSI] mv_sas: OCZ RevoDrive3 & zDrive R4 support · 99a700bc
      Robin H. Johnson authored
      In the OCZ RevoDrive3/zDrive R4 series, the "OCZ SuperScale Storage
      Controller" with "Virtualized Controller Architecture 2.0" really seems
      to be a Marvell 88SE9485 part, with OCZ firmware/BIOS.
      
      Developed and tested on OCZ RevoDrive3 120GB [PCI 1b85:1021]
      
      Should work on:
      - OCZ RevoDrive3 (2x SandForce 2281)
      - OCZ RevoDrive3 X2 (4x SandForce 2281)
      - OCZ zDrive R4 CM84 (4x SandForce 2281)
      - OCZ zDrive R4 CM88 (8x SandForce 2281)
      - OCZ zDrive R4 RM84 (4x SandForce 2582)
      - OCZ zDrive R4 RM88 (8x SandForce 2582)
      
      All of this because a friend recently bought a OCZ RevoDrive3 and was
      bitten by the lack of Linux support.
      
      Notes from testing:
      -------------------
      - SMART works.
      - VPD Device Identification is "OCZ-REVODRIVE3"
      - Thin provisioning/TRIM seems to be implemented as WRITE SAME UNMAP,
        with deterministic (non-zero) read after TRIM, but I'm not sure if it
        works 100% in my testing.
      - Some of the tuning in the firmware seems to ensure much better
        performance when in a RAID0 setup than using the two devices
        seperately.
      
      I have not tested booting from the SSD, because all of this was
      developed and tested remotely from the actual hardware.
      Signed-off-by: default avatarRobin H. Johnson <robbat2@gentoo.org>
      Thanks-To: Gordon Pritchard <gordp@sfu.ca>
      Acked-by: default avatarXiangliang Yu <yuxiangl@marvell.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      99a700bc
  13. 02 Oct, 2011 10 commits
  14. 15 Sep, 2011 1 commit
  15. 27 Aug, 2011 1 commit
  16. 26 Jul, 2011 9 commits
  17. 01 May, 2011 2 commits
  18. 23 Mar, 2011 1 commit