Re: [PATCH] mptlan: fix mpt_lan_sdu_send()'s return type

2018-05-14 Thread Martin K. Petersen

Luc,

>> You forgot to update the function prototype accordingly.
>
> Hmmm, the function mpt_lan_sdu_send() has no other declaration
> than the one I modified the return type in this patch.
>
> Must be a misunderstanding somewhere.

My bad, I thought you were updating mpt_lan_send_reply().

Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: clean up generated file scsi_devinfo_tbl.c

2018-05-14 Thread Martin K. Petersen

Randy,

> "make clean" should remove the generated file "scsi_devinfo_tbl.c", so
> list it in the clean-files variable so that the file gets cleaned up.

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [RESEND] tcmu: fix error resetting qfull_time_out to default

2018-05-14 Thread Martin K. Petersen

Prasanna,

> This patch will help reset qfull_time_out to its default
> i.e. qfull_time_out=-1

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] ipr: new IOASC update

2018-05-14 Thread Martin K. Petersen

Wen,

> This patch adds new adapter error log for P9 system with the new AZ
> SAS cable.

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: esas2r: fix spelling mistake: "requestss" -> "requests"

2018-05-14 Thread Martin K. Petersen

Colin,

> Trivial fix to spelling mistake in esas2r_debug message

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: libosd: Remove VLA usage

2018-05-14 Thread Martin K. Petersen

Kees,

> On the quest to remove all VLAs from the kernel[1] this rearranges the
> code to avoid a VLA warning under -Wvla (gcc doesn't recognize "const"
> variables as not triggering VLA creation). Additionally cleans up variable
> naming to avoid 80 character column limit.

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v3] target: transport should allow st FM/EOM/ILI reads

2018-05-14 Thread Bodo Stroesser
> When a tape drive is exported via LIO using the pscsi module, a read that
> requests more bytes per block than the tape can supply returns an empty
> buffer. This is because the pscsi pass-through target module sees the
> "ILI" illegal length bit set and thinks there is no reason to return
> the data.
> 
> This is a long-standing transport issue, since it assumes that no data
> need be returned under a check condition, which isn't always the case
> for tape.
> 
> Add in a check for tape reads with the ILI, EOM, or FM bits set,
> with a sense code of NO_SENSE, treating such cases as if the read
> succeeded. The layered tape driver then "does the right thing" when
> it gets such a response.

I tested the patch. Using the st driver to handle the exported tape drive on
the initiator side, everything works fine.
But the st driver masks a problem that still persists. A real tape drive, if
the READ is longer than the data block to read, will transfer only the amount
of data from the tape block.
The exported tape drive with this patch transfers the full amount of data
as requested by the READ. The over scoring part of the transmitted data is
padded with NUL bytes.

Sending READ commands via sg with sg_raw I was able to test this behavior.
I also verified it using a FibreChannel analyzer.

I'd suggest to call target_complete_cmd_with_length() instead of
target_complete_cmd() in the descibed situation. That should fix the length
of the transmitted data, I think.

BR, Bodo

> 
> Changes from v2:
>  - Cleaned up subject line and bug text formatting
>  - Removed unneeded inner braces
>  - Removed ugly goto
>  - Also updated the "queue full" path to handle this case
> 
> Changes from RFC:
>  - Moved ugly code from transport to pscsi module
>  - Added checking EOM and FM bits, as well as ILI
>  - fixed malformed patch
>  - Clarified description a bit
> 
> Signed-off-by: Lee Duncan 
> ---
>  drivers/target/target_core_pscsi.c | 23 +++-
>  drivers/target/target_core_transport.c | 39 
> +-
>  include/target/target_core_base.h  |  1 +
>  3 files changed, 57 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/target/target_core_pscsi.c 
> b/drivers/target/target_core_pscsi.c
> index 0d99b242e82e..a9656368a96d 100644
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -689,8 +689,29 @@ static void pscsi_complete_cmd(struct se_cmd *cmd, u8 
> scsi_status,
>   }
>  after_mode_select:
>  
> - if (scsi_status == SAM_STAT_CHECK_CONDITION)
> + if (scsi_status == SAM_STAT_CHECK_CONDITION) {
>   transport_copy_sense_to_cmd(cmd, req_sense);
> +
> + /*
> +  * hack to check for TAPE device reads with
> +  * FM/EOM/ILI set, so that we can get data
> +  * back despite framework assumption that a
> +  * check condition means there is no data
> +  */
> + if (sd->type == TYPE_TAPE &&
> + cmd->data_direction == DMA_FROM_DEVICE) {
> + /*
> +  * is sense data valid, fixed format,
> +  * and have FM, EOM, or ILI set?
> +  */
> + if (req_sense[0] == 0xf0 && /* valid, fixed format 
> */
> + req_sense[2] & 0xe0 &&  /* FM, EOM, or ILI */
> + (req_sense[2] & 0xf) == 0) { /* key==NO_SENSE */
> + pr_debug("Tape FM/EOM/ILI status detected. 
> Treat as normal read.\n");
> + cmd->se_cmd_flags |= SCF_TREAT_READ_AS_NORMAL;
> + }
> + }
> + }
>  }
>  
>  enum {
> diff --git a/drivers/target/target_core_transport.c 
> b/drivers/target/target_core_transport.c
> index 74b646f165d4..a15a9e3dce11 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -2084,12 +2084,24 @@ static void transport_complete_qf(struct se_cmd *cmd)
>   goto queue_status;
>   }
>  
> - if (cmd->se_cmd_flags & SCF_TRANSPORT_TASK_SENSE)
> + /*
> +  * Check if we need to send a sense buffer from
> +  * the struct se_cmd in question. We do NOT want
> +  * to take this path of the IO has been marked as
> +  * needing to be treated like a "normal read". This
> +  * is the case if it's a tape read, and either the
> +  * FM, EOM, or ILI bits are set, but there is no
> +  * sense data.
> +  */
> + if (!(cmd->se_cmd_flags & SCF_TREAT_READ_AS_NORMAL) &&
> + cmd->se_cmd_flags & SCF_TRANSPORT_TASK_SENSE)
>   goto queue_status;
>  
>   switch (cmd->data_direction) {
>   case DMA_FROM_DEVICE:
> - if (cmd->scsi_status)
> + /* queue status if not treating this as a normal read */
> + if (cmd->scsi_status &&
> + !(cmd->se_cmd_flags & SCF_TREAT_READ_AS_NORMA

[Bug 199703] HPSA blocking boot on HP smart Array P400

2018-05-14 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199703

--- Comment #4 from Roberto M. (roby_program...@fastwebnet.it) ---
(In reply to Lei Ming from comment #3)

> I mean 'mainline' kernel in page of www.kernel.org

OK, my kernel 4.16.8 is downloaded and build from kernel.org, I will try before
next Monday last 4.13 kernel from kernel.org, and first 4.14 kernel from
kernel.org, build and install.

I think the "bug" was introduced in 4.14 mainstream kernel, but I only tested
Ubuntu kernel from Ubuntu PPA archive, I will check from kernel.org and report
here.

-- 
You are receiving this mail because:
You are the assignee for the bug.