Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 12 4月, 2016 3 次提交
  3. 18 8月, 2015 1 次提交
  5. 30 12月, 2014 1 次提交
  7. 20 11月, 2014 5 次提交
  9. 17 9月, 2014 1 次提交
  11. 19 5月, 2014 2 次提交
    • H
      fnic: fnic Control Path Trace Utility · abb14148
      由 Hiral Shah 提交于 
      Fnic Ctlr Path Trace utility is a tracing functionality built directly into fnic
driver to trace the control path frames like discovery, FLOGI request/reply,
PLOGI request/reply, link event etc.  It will be one trace file for all fnics.
It will help us to debug and resolve the discovery and initialization related
issues in more convenient way. This trace information includes time stamp,
Host Number, Frame type, Frame Length and Frame. By default,64 pages are
allocated but we can change the number of allocated pages by module parameter
fnic_fc_trace_max_page. Each entry is of 256 byte and available entries are
depends on allocated number of pages. We can turn on or off the fnic control
path trace functionality by module paramter fc_trace_enable and/or reset the
trace contain by module paramter fc_trace_clear.
Signed-off-by: NHiral Shah <hishah@cisco.com>
Signed-off-by: NSesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      abb14148
    • H
      fnic: NoFIP solicitation frame in NONFIP mode and changed IO Throttle count · c8ff03c6
      由 Hiral Shah 提交于 
      This patch contains following three minor fixes.

1) During Probe, fnic was sending FIP solicitation in Non FIP mode which is not
   expected, setting the internal fip state to Non FIP mode explicitly, avoids
   sending FIP frame.

2) When target goes offline, all outstanding IOs belong to the target will be
   terminated by driver, If the termination count is high, then it influences
   firmware responsiveness. To improve the responsiveness, default IO throttle
   count is reduced to 256.

3) Accessing Virtual Fabric Id (vfid) and fc_map of Fibre-Channel Forwarder(FCF)
   is invalid in fnic driver when Clear Virtual Link(CVL) is received prior to
   receiving flogi reject from switch. As CVL clears all FCFs.
Signed-off-by: NHiral Shah <hishah@cisco.com>
Signed-off-by: NSesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: NNarsimhulu Musini <nmusini@cisco.com>
Signed-off-by: NAnantha Tungarakodi <atungara@cisco.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      c8ff03c6
  13. 25 10月, 2013 2 次提交
  15. 12 9月, 2013 2 次提交
  17. 03 8月, 2013 1 次提交
    • C
      [SCSI] fnic: BUG: sleeping function called from invalid context during probe · e09056b2
      由 Chris Leech 提交于 
      I hit this during driver probe with the latest fnic updates (this trace
is from a backport into a distro kernel, but the issue is the same).

> BUG: sleeping function called from invalid context at mm/slab.c:3113
> in_atomic(): 0, irqs_disabled(): 1, pid: 610, name: work_for_cpu
> INFO: lockdep is turned off.
> irq event stamp: 0
> hardirqs last  enabled at (0): [<(null)>] (null)
> hardirqs last disabled at (0): [<ffffffff81070aa5>]
> copy_process+0x5e5/0x1670
> softirqs last  enabled at (0): [<ffffffff81070aa5>]
> copy_process+0x5e5/0x1670
> softirqs last disabled at (0): [<(null)>] (null)
> Pid: 610, comm: work_for_cpu Not tainted
> Call Trace:
>  [<ffffffff810b2d10>] ? print_irqtrace_events+0xd0/0xe0
>  [<ffffffff8105c1a7>] ? __might_sleep+0xf7/0x130
>  [<ffffffff81184efb>] ? kmem_cache_alloc_trace+0x20b/0x2d0
>  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
>  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
>  [<ffffffffa00c101c>] ? fnic_probe+0x977/0x11aa [fnic]
>  [<ffffffffa00c1048>] ? fnic_probe+0x9a3/0x11aa [fnic]
>  [<ffffffff81096f00>] ? do_work_for_cpu+0x0/0x30
>  [<ffffffff812c6da7>] ? local_pci_probe+0x17/0x20
>  [<ffffffff81096f18>] ? do_work_for_cpu+0x18/0x30
>  [<ffffffff8109cdc6>] ? kthread+0x96/0xa0
>  [<ffffffff8100c1ca>] ? child_rip+0xa/0x20
>  [<ffffffff81550f80>] ? _spin_unlock_irq+0x30/0x40
>  [<ffffffff8100bb10>] ? restore_args+0x0/0x30
>  [<ffffffff8109cd30>] ? kthread+0x0/0xa0
>  [<ffffffff8100c1c0>] ? child_rip+0x0/0x20

The problem is in this hunk of "FIP VLAN Discovery Feature Support"
(d3c995f1)

create_singlethreaded_workqueue cannot be called with irqs disabled

@@ -620,7 +634,29 @@ static int __devinit fnic_probe(struct pci_dev
*pdev,
        vnic_dev_packet_filter(fnic->vdev, 1, 1, 0, 0, 0);
        vnic_dev_add_addr(fnic->vdev, FIP_ALL_ENODE_MACS);
        vnic_dev_add_addr(fnic->vdev, fnic->ctlr.ctl_src_addr);
+       fnic->set_vlan = fnic_set_vlan;
        fcoe_ctlr_init(&fnic->ctlr, FIP_MODE_AUTO);
+       setup_timer(&fnic->fip_timer, fnic_fip_notify_timer,
+                           (unsigned long)fnic);
+       spin_lock_init(&fnic->vlans_lock);
+       INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame);
+       INIT_WORK(&fnic->event_work, fnic_handle_event);
+       skb_queue_head_init(&fnic->fip_frame_queue);
+       spin_lock_irqsave(&fnic_list_lock, flags);
+       if (!fnic_fip_queue) {
+           fnic_fip_queue =
+               create_singlethread_workqueue("fnic_fip_q");
+           if (!fnic_fip_queue) {
+               spin_unlock_irqrestore(&fnic_list_lock, flags);
+               printk(KERN_ERR PFX "fnic FIP work queue "
+                        "create failed\n");
+               err = -ENOMEM;
+               goto err_out_free_max_pool;
+           }
+       }
+       spin_unlock_irqrestore(&fnic_list_lock, flags);
+       INIT_LIST_HEAD(&fnic->evlist);
+       INIT_LIST_HEAD(&fnic->vlans);
    } else {
        shost_printk(KERN_INFO, fnic->lport->host,
                 "firmware uses non-FIP mode\n");

The attempts to make fnic_fip_queue a single instance for the driver
while it's being created in probe look awkward anyway, why is this not
created in fnic_init_module like the event workqueue?
Signed-off-by: NChris Leech <cleech@redhat.com>
Tested-by: NAnantha Tungarakodi <atungara@cisco.com>
Acked-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e09056b2
  19. 02 5月, 2013 2 次提交
    • H
      [SCSI] fnic: Incremented driver version · 62271dbd
      由 Hiral Patel 提交于 
      Signed-off-by: NBrian Uchino <buchino@cisco.com>
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      62271dbd
    • H
      [SCSI] fnic: FIP VLAN Discovery Feature Support · d3c995f1
      由 Hiral Patel 提交于 
      FIP VLAN discovery discovers the FCoE VLAN that will be used by all other FIP
protocols as well as by the FCoE encapsulation for Fibre Channel payloads on
the established virtual link. One of the goals of FC-BB-5 was to be as
nonintrusive as possible on initiators and targets, and therefore FIP VLAN
discovery occurs in the native VLAN used by the initiator or target to
exchange Ethernet traffic. The FIP VLAN discovery protocol is the only FIP
protocol running on the native VLAN; all other FIP protocols run on the
discovered FCoE VLANs.

If an administrator has manually configured FCoE VLANs on ENodes and FCFs,
there is no need to use this protocol. FIP and FCoE will run over the
configured VLANs.

An ENode without FCoE VLANs configuration would use this automated discovery
protocol to discover over which VLANs FCoE is running.

The ENode sends a FIP VLAN discovery request to a multicast MAC address called
All-FCF-MACs, which is a multicast MAC address to which all FCFs listen.

All FCFs that can be reached in the native VLAN of the ENode are expected to
respond on the same VLAN with a response that lists one or more FCoE VLANs
that are available for the ENode's VN_Port login. This protocol has the sole
purpose of allowing the ENode to discover all the available FCoE VLANs.

Now the ENode may enable a subset of these VLANs for FCoE Running the FIP
protocol in these VLANs on a per VLAN basis. And FCoE data transactions also
would occur on this VLAN. Hence, Except for FIP VLAN discovery, all other FIP
and FCoE traffic runs on the selected FCoE VLAN.  Its only the FIP VLAN
Discovery protocol that is permitted to run on the Default native VLAN of the
system.

[**** NOTE ****]
We are working on moving this feature definitions and functionality to libfcoe
module. We need this patch to be approved, as Suse is looking forward to merge
this feature in SLES 11 SP3 release.  Once this patch is approved, we will
submit patch which should move vlan discovery feature to libfoce.

[Fengguang Wu <fengguang.wu@intel.com>: kmalloc cast removal]
Signed-off-by: NAnantha Prakash T <atungara@cisco.com>
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      d3c995f1
  21. 23 2月, 2013 4 次提交
    • H
      [SCSI] fnic: Fnic Trace Utility · 4d7007b4
      由 Hiral Patel 提交于 
      Fnic Trace utility is a tracing functionality built directly into fnic driver
to trace events. The benefit that trace buffer brings to fnic driver is the
ability to see what it happening inside the fnic driver. It also provides the
capability to trace every IO event inside fnic driver to debug panics, hangs
and potentially IO corruption issues. This feature makes it easy to find
problems in fnic driver and it also helps in tracking down strange bugs in a
more manageable way. Trace buffer is shared across all fnic instances for
this implementation.
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      4d7007b4
    • H
      [SCSI] fnic: New debug flags and debug log messages · 14eb5d90
      由 Hiral Patel 提交于 
      Added new fnic debug flags for identifying IO state at every stage of IO while
debugging and also added more log messages for better debugging capability.
Signed-off-by: NSesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      14eb5d90
    • H
      [SCSI] fnic: fnic driver may hit BUG_ON on device reset · a0bf1ca2
      由 Hiral Patel 提交于 
      The issue was observed when LUN Reset is issued through IOCTL or sg_reset
utility.

fnic driver issues LUN RESET to firmware. On successful completion of device
reset, driver cleans up all the pending IOs that were issued prior to device
reset. These pending IOs are expected to be in ABTS_PENDING state. This works
fine, when the device reset operation resulted from midlayer, but not when
device reset was triggered from IOCTL path as the pending IOs were not in
ABTS_PENDING state. execution path hits panic if the pending IO is not in
ABTS_PENDING state.

Changes:
The fix replaces BUG_ON check in fnic_clean_pending_aborts() with marking
pending IOs as ABTS_PENDING if they were not in ABTS_PENDING state and skips
if they were already in ABTS_PENDING state. An extra check is added to validate
the abort status of the commands after a delay of 2 * E_D_TOV using a
helper function. The helper function returns 1 if it finds any pending IO in
ABTS_PENDING state, belong to the LUN on which device reset was issued else 0.
With this, device reset operation returns success only if the helper funciton
returns 0, otherwise it returns failure.

Other changes:
- Removed code in fnic_clean_pending_aborts() that returns failure if it finds
  io_req NULL, instead of returning failure added code to continue with next io
- Added device reset flags for debugging in fnic_terminate_rport_io,
  fnic_rport_exch_reset, and fnic_clean_pending_aborts
Signed-off-by: NNarsimhulu Musini <nmusini@cisco.com>
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      a0bf1ca2
    • H
      [SCSI] fnic: fixing issues in device and firmware reset code · 03298552
      由 Hiral Patel 提交于 
      1. Handling overlapped firmware resets
     This fix serialize multiple firmware resets to avoid situation where fnic
     device fails to come up for link up event, when firmware resets are issued
     back to back. If there are overlapped firmware resets are issued,
     the firmware reset operation checks whether there is any firmware reset in
     progress, if so it polls for its completion in a loop with 100ms delay.

2. Handling device reset timeout
     fnic_device_reset code has been modified to handle Device reset timeout:
     - Issue terminate on device reset timeout.
     - Introduced flags field (one of the scratch fields in scsi_cmnd).
     With this, device reset request would have DEVICE_RESET flag set for other
     routines to determine the type of the request.
     Also modified fnic_terminate_rport_io, fnic_rport_exch_rset, completion
     routines to handle SCSI commands with DEVICE_RESET flag.

3. LUN/Device Reset hangs when issued through IOCTL using utilities like
   sg_reset.
     Each SCSI command is associated with a valid tag, fnic uses this tag to
     retrieve associated scsi command on completion. the LUN/Device Reset issued
     through IOCTL resulting into a SCSI command that is not associated with a
     valid tag. So fnic fails to retrieve associated scsi command on completion,
     which causes hang. This fix allocates tag, associates it with the
     scsi command and frees the tag, when the operation completed.

4. Preventing IOs during firmware reset.
     Current fnic implementation allows IO submissions during firmware reset.
     This fix synchronizes IO submissions and firmware reset operations.
     It ensures that IOs issued to fnic prior to reset will be issued to the
     firmware before firmware reset.
Signed-off-by: NNarsimhulu Musini <nmusini@cisco.com>
Signed-off-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      03298552
  23. 30 6月, 2011 1 次提交
  25. 13 2月, 2011 1 次提交
  27. 17 11月, 2010 1 次提交
    • J
      SCSI host lock push-down · f281233d
      由 Jeff Garzik 提交于 
      Move the mid-layer's ->queuecommand() invocation from being locked
with the host lock to being unlocked to facilitate speeding up the
critical path for drivers who don't need this lock taken anyway.

The patch below presents a simple SCSI host lock push-down as an
equivalent transformation.  No locking or other behavior should change
with this patch.  All existing bugs and locking orders are preserved.

Additionally, add one parameter to queuecommand,
	struct Scsi_Host *
and remove one parameter from queuecommand,
	void (*done)(struct scsi_cmnd *)

Scsi_Host* is a convenient pointer that most host drivers need anyway,
and 'done' is redundant to struct scsi_cmnd->scsi_done.

Minimal code disturbance was attempted with this change.  Most drivers
needed only two one-line modifications for their host lock push-down.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Acked-by: NJames Bottomley <James.Bottomley@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f281233d
  29. 11 8月, 2010 1 次提交
  31. 12 4月, 2010 2 次提交
  33. 18 2月, 2010 1 次提交
  35. 05 12月, 2009 2 次提交
  37. 14 5月, 2009 1 次提交