Skip to content
  1. Feb 24, 2013
  3. Feb 23, 2013
    • Hiral Patel's avatar
      [SCSI] fnic: Fnic Trace Utility · 4d7007b4
      Hiral Patel authored 
      

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: default avatarHiral Patel <hiralpat@cisco.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      4d7007b4
    • Hiral Patel's avatar
      [SCSI] fnic: New debug flags and debug log messages · 14eb5d90
      Hiral Patel authored 
      

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: default avatarSesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: default avatarHiral Patel <hiralpat@cisco.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      14eb5d90
    • Hiral Patel's avatar
      [SCSI] fnic: fnic driver may hit BUG_ON on device reset · a0bf1ca2
      Hiral Patel authored 
      

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: default avatarNarsimhulu Musini <nmusini@cisco.com>
Signed-off-by: default avatarHiral Patel <hiralpat@cisco.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      a0bf1ca2
    • Hiral Patel's avatar
      [SCSI] fnic: Fix SGEs limit · cfe16d5d
      Hiral Patel authored 
      

Driver allows IOs with more SGEs than max SGEs supported by Palo. The current
max SGEs supported by the fnic driver is 1024. The current register settings
on Palo supports a max of 256 only. Palo would return any IO with more than
256 SGEs with an error indicating INVALID_SGLS. Fnic driver should limit the
max supported SGLs in the driver to 256 to avoid this error.

Signed-off-by: default avatarSesidhar Baddela <sebaddel@cisco.com>
Signed-off-by: default avatarHiral Patel <hiralpat@cisco.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      cfe16d5d
    • Hiral Patel's avatar
      [SCSI] fnic: fixing issues in device and firmware reset code · 03298552
      Hiral Patel authored 
      

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: default avatarNarsimhulu Musini <nmusini@cisco.com>
Signed-off-by: default avatarHiral Patel <hiralpat@cisco.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      03298552
  5. Feb 22, 2013