Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 7月, 2012 1 次提交
  3. 19 2月, 2012 2 次提交
  5. 31 3月, 2011 1 次提交
  7. 08 10月, 2010 1 次提交
  9. 06 9月, 2010 1 次提交
  11. 11 4月, 2010 1 次提交
    • C
      [SCSI] Allow FC LLD to fast-fail scsi eh by introducing new eh return · 2f2eb587
      由 Christof Schmitt 提交于 
      If the scsi eh is running and then a FC LLD calls
fc_remote_port_delete, the SCSI commands sent from the eh will fail.
To prevent this, a FC LLD can call fc_block_scsi_eh from the eh
callback, blocking the eh thread until the dev_loss_tmo fires or the
remote port is available again.

If (e.g. for a multipathing setup) the dev_loss_tmo is set to a very
large value, thus preventing the scsi device removal , the scsi eh can
block for a long time. For multipathing, the fast_io_fail_tmo is then
set to a low value to detect path problems sooner.

This patch introduces a new return code FAST_IO_FAIL. The function
fc_block_scsi_eh now returns FAST_IO_FAIL when the fast_io_fail_tmo
fires. This indicates that the LLD terminated all pending I/O requests
and there are no more pending SCSI commands for the scsi eh to wait
for. This return code can be passed back to the scsi eh to stop the
escalation and finish the recovery process for this device.
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      2f2eb587
  13. 05 12月, 2009 1 次提交
  15. 13 6月, 2009 1 次提交
    • J
      [SCSI] FC Pass Thru support · 9e4f5e29
      由 James Smart 提交于 
      Attached is the ELS/CT pass-thru patch for the FC Transport. The patch
creates a generic framework that lays on top of bsg and the SGIO v4 ioctl
in order to pass transaction requests to LLDD's.

The interface supports the following operations:
  On an fc_host basis:
    Request login to the specified N_Port_ID, creating an fc_rport.
    Request logout of the specified N_Port_ID, deleting an fc_rport
    Send ELS request to specified N_Port_ID w/o requiring a login, and
      wait for ELS response.
    Send CT request to specified N_Port_ID and wait for CT response.
      Login is required, but LLDD is allowed to manage login and decide
      whether it stays in place after the request is satisfied.
    Vendor-Unique request. Allows a LLDD-specific request to be passed
      to the LLDD, and the passing of a response back to the application.
  On an fc_rport basis:
    Send ELS request to nport and wait for ELS response.
    Send CT request to nport and wait for CT response.

The patch also exports several headers from include/scsi such that
they can be available to user-space applications:
  include/scsi/scsi.h
  include/scsi/scsi_netlink.h
  include/scsi/scsi_netlink_fc.h
  include/scsi/scsi_bsg_fc.h

For further information, refer to the last RFC:
http://marc.info/?l=linux-scsi&m=123436574018579&w=2

Note: Documentation is still spotty and will be added later.

[bharrosh@panasas.com: update for new block API]
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      9e4f5e29
  17. 16 5月, 2009 1 次提交
    • A
      [SCSI] fc-transport: Close state transition-window during rport deletion. · 9a1a69a1
      由 Andrew Vasquez 提交于 
      Andrew Vasquez wrote:
> fc-transport: Close state transition-window during rport deletion.
>
> After an rport's state has transitioned to FC_PORTSTATE_BLOCKED,
> but, prior to making the upcall to 'block' the scsi-target
> associated with an rport, queued commands can recycle and
> ultimately run out of retries causing failures to propagate to
> upper-level drivers.  Close this transition-window by returning
> the non-'retries' modifying DID_IMM_RETRY status for submitted
> I/Os.

The same can happen for iscsi when transitioning from logged in
to failed and blocking the sdevs.

This patch converts iscsi and fc's transitions back to use DID_IMM_RETRY
instead of DID_TRANSPORT_DISRUPTED which has a limited number of retries
that we do not want to use for handling this race.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
[Addition of iscsi and fc port online devloss case conversion by Mike Christie]
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      9a1a69a1
  19. 06 1月, 2009 1 次提交
  21. 21 11月, 2008 1 次提交
  23. 13 10月, 2008 2 次提交
    • M
      [SCSI] fc class: Add support for new transport errors · f46e307d
      由 Mike Christie 提交于 
      If the target is blocked and fast io fail tmo has not fired
then we requeue with DID_TRANSPORT_DISRUPTED. Once that
tmo fires we fail with DID_TRANSPORT_FAILFAST.

v2
- seperate from
"fc class: unblock target after calling terminate callback"
to make it easier to review.
- Add JamesS's ack from list.
v2
- initial patch
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Acked-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      f46e307d
    • M
      [SCSI] fc class: unblock target after calling terminate callback (take 2) · fff9d40c
      由 Mike Christie 提交于 
      When we block a rport and the driver implements the terminate
callback we will fail IO that was running quickly. However
IO that was in the scsi_device/block queue sits there until
the dev_loss_tmo fires, and this can make it look like IO is
lost because new IO will get executed but that IO stuck in
the blocked queue sits there for some time longer.

With this patch when the fast io fail tmo fires, we will
fail the blocked IO and any new IO. This patch also allows
all drivers to partially support the fast io fail tmo. If the
terminate io callback is not implemented, we will still fail blocked
IO and any new IO, so multipath can handle that.

This patch also allows the fc and iscsi classes to implement the
same behavior. The timers are just unfornately named differently.

This patch also fixes the problem where drivers were unblocking
the target in their terminate callback, which was needed for
rport removal, but for fast io fail timeout it would cause
IO to bounce arround the scsi/block layer and the LLD queuecommand.
And it for drivers that could have IO stuck but did not have
a terminate callback the unblock calls in the class will fix
them.

v2.
- fix up bit setting style to meet JamesS's pref.
- Broke out new host byte error changes to make it easier to read.
- added JamesS's ack from list.
v1
- initial patch
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Acked-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      fff9d40c
  25. 04 10月, 2008 1 次提交
  27. 22 7月, 2008 1 次提交
  29. 20 4月, 2008 1 次提交
  31. 03 2月, 2008 1 次提交
  33. 13 10月, 2007 2 次提交
  35. 27 5月, 2007 1 次提交
  37. 16 5月, 2007 1 次提交
    • J
      [SCSI] FC Transport support for vports based on NPIV · a53eb5e0
      由 James Smart 提交于 
      This patch provides support for FC virtual ports based on NPIV.
For information on the interfaces and design, please read the
Documentation/scsi/scsi_fc_transport.txt file enclosed within
the patch.

The RFC was originally posted here:
http://marc.info/?l=linux-scsi&m=117226959918393&w=2

Changes from the initial RFC:
- Bug fix: needed a transport_class_unregister() for the vport class
- Create a symlink to the vport in the shost device if it is not the
    parent of the vport.
- Made symbolic name writable so it can be set after creation
- Made the temporary fc_vport_identifiers struct private to the
transport.
- Deleted the vport_id field from the vport. I couldn't find any good
  use for it (and symname is a good replacement).
- Made the vport_state and vport_last_state "private" attributes.
  Added the fc_vport_set_state() helper function to manage state
  transitions
- Updated vport_create() to allow a vport to be created in a disabled
  state.
- Added INITIALIZING and FAILED vport states
- Added VPCERR_xxx defines for errors to be returned from vport_create()
- Created a Documentation/scsi/scsi_fc_transport.txt file that describes
  the interfaces and expected LLDD behaviors.
Signed-off-by: NJames Smart <James.Smart@emulex.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a53eb5e0
  39. 20 3月, 2007 1 次提交
  41. 22 11月, 2006 1 次提交
  43. 05 9月, 2006 1 次提交
  45. 03 9月, 2006 2 次提交
  47. 20 8月, 2006 2 次提交
  49. 26 4月, 2006 1 次提交
  51. 14 4月, 2006 1 次提交
    • J
      [SCSI] FC transport: fixes for workq deadlocks · aedf3497
      由 James Smart 提交于 
      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: NJames Bottomley <James.Bottomley@SteelEye.com>
      aedf3497
  53. 15 1月, 2006 1 次提交
  55. 16 12月, 2005 1 次提交
    • J
      [SCSI] fix for fc transport recursion problem. · 42e33148
      由 James.Smart@Emulex.Com 提交于 
      In the scenario that a link was broken, the devloss timer for each
rport was expire at roughly the same time, causing lots of "delete"
workqueue items being queued. Depth is dependent upon the number of
rports that were on the link.

The rport target remove calls were calling flush_scheduled_work(),
which would interrupt the stream, and start the next workqueue item,
which did the same thing, and so on until recursion depth was large.

This fix stops the recursion in the initial delete path, and pushes it
off to a host-level work item that reaps the dead rports.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      42e33148
  57. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      由 Tim Schmielau 提交于 
      I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.

In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch.  This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other.  So if any
hunk rejects or gets in the way of other patches, just drop it.  My scripts
will pick it up again in the next round.
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  59. 29 10月, 2005 2 次提交
    • J
      [SCSI] update fc_transport for removal of block/unblock functions · 19a7b4ae
      由 James.Smart@Emulex.Com 提交于 
      We recently went back to implement a board reset. When we perform the
reset, we wanted to tear down the internal data structures and rebuild
them. Unfortunately, when it came to the rport structure, things were
odd. If we deleted them, the scsi targets and sdevs would be
torn down. Not a good thing for a temporary reset. We could block the
rports, but we either maintain the internal structures to keep the
rport reference (perhaps even replicating what's in the transport),
or we have to fatten the fc transport with new search routines to find
the rport (and deal with a case of a dangling rport that the driver
forgets).

It dawned on me that we had actually reached this state incorrectly.
When the fc transport first started, we did the block/unblock first, then
added the rport interface. The purpose of block/unblock is to hide the
temporary disappearance of the rport (e.g. being deleted, then readded).
Why are we making the driver do the block/unblock ? We should be making
the transport have only an rport add/delete, and the let the transport
handle the block/unblock.

So... This patch removes the existing fc_remote_port_block/unblock
functions. It moves the block/unblock functionality into the
fc_remote_port_add/delete functions.  Updates for the lpfc driver are
included. Qlogic driver updates are also enclosed, thanks to the
contributions of Andrew Vasquez. [Note: the qla2xxx changes are
relative to the scsi-misc-2.6 tree as of this morning - which does
not include the recent patches sent by Andrew]. The zfcp driver does
not use the block/unblock functions.

One last comment: The resulting behavior feels very clean. The LLDD is
concerned only with add/delete, which corresponds to the physical
disappearance.  However, the fact that the scsi target and sdevs are
not immediately torn down after the LLDD calls delete causes an
interesting scenario... the midlayer can call the xxx_slave_alloc and
xxx_queuecommand functions with a sdev that is at the location the
rport used to be. The driver must validate the device exists when it
first enters these functions. In thinking about it, this has always
been the case for the LLDD and these routines. The existing drivers
already check for existence. However, this highlights that simple
validation via data structure dereferencing needs to be watched.
To deal with this, a new transport function, fc_remote_port_chkready()
was created that LLDDs should call when they first enter these two
routines. It validates the rport state, and returns a scsi result
which could be returned. In addition to solving the above, it also
creates consistent behavior from the LLDD's when the block and deletes
are occuring.

Rejections fixed up and
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      19a7b4ae
    • A
      [SCSI] Add an 'Issue LIP' device attribute in fc_transport class · 91ca7b01
      由 Andrew Vasquez 提交于 
      Ok, here's a patch to add such a common API for fc transport users.
Relevant LLD changes (lpfc and qla2xxx) also present.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      91ca7b01
  61. 16 9月, 2005 1 次提交
    • A
      [SCSI] change port speed definitions for scsi_transport_fc · 1832a586
      由 Andreas Herrmann 提交于 
      obviously FC Port Speeds in scsi_transport_fc.h are defined according
to FC-HBA:

#define FC_PORTSPEED_1GBIT              1
#define FC_PORTSPEED_2GBIT              2
#define FC_PORTSPEED_10GBIT             4
#define FC_PORTSPEED_4GBIT              8

Problem is, whoever invented FC-HBA did not care about FC-FS or
FC-GS-x. Following FC-FS/FC-GS-x defintions of port speeds would look
like:

1 GBit: 0x0001
2 GBit: 0x0002
4 GBit: 0x0004
10GBit: 0x0008

(and new in FC-LS:
8 Gbit: 0x0010
16GBit: 0x0020)

I really appreciate if scsi_transport_fc.h would define port speeds
according to FC-GS-x/FC-FS. Thus mapping of port speed capabilities to
values defined in scsi_transport_fc.h can be avoided in the LLDD.

Attached is a patch to change the definitions.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      1832a586
  63. 11 9月, 2005 1 次提交
  65. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4