Re: [PATCH 1/1] libfc: don't have fc_exch_find log errors on a new exchange

On 10/25/2016 07:51 PM, Chris Leech wrote: > On Mon, Oct 24, 2016 at 04:37:59PM +0200, Hannes Reinecke wrote: >> On 10/21/2016 11:10 PM, Chris Leech wrote: >>> With the error message I added in "libfc: sanity check cpu number >>> extracted from xid" I didn't account for the fact that fc_exch_find

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

On 10/25/2016 1:28 AM, TomK wrote: On 10/24/2016 2:36 AM, Nicholas A. Bellinger wrote: Hi TomK, Thanks for reporting this bug. Comments inline below. On Mon, 2016-10-24 at 00:45 -0400, TomK wrote: On 10/24/2016 12:32 AM, TomK wrote: On 10/23/2016 10:03 PM, TomK wrote: Hey, Has anyone

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On Tue, 2016-10-25 at 23:18 +, Bart Van Assche wrote: > On Tue, 2016-10-25 at 15:23 -0700, James Bottomley wrote: > > Because scsi_execute uses REQ_BLOCK_PC which is completed before > > you get to that code. > > Hello James, > > Do you perhaps mean that scsi_io_completion() returns early

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On Tue, 2016-10-25 at 15:23 -0700, James Bottomley wrote: > Because scsi_execute uses REQ_BLOCK_PC which is completed before you > get to that code. Hello James, Do you perhaps mean that scsi_io_completion() returns early for REQ_TYPE_BLOCK_PC requests? Can you clarify this further? Anyway,

[Bug 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once

https://bugzilla.kernel.org/show_bug.cgi?id=121531 --- Comment #19 from Chloé Desoutter --- Said parameter has been introduced by this commit. 99c72ebceb4dda445b4b74c6f46035feec95a2b3 The rationale is OK but the flaw is that sometimes the controller will crash

[Bug 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once

https://bugzilla.kernel.org/show_bug.cgi?id=121531 --- Comment #18 from Chloé Desoutter --- Actually further MicroSemi driver analysis lets me think that the proper, recommended value is 256. $ egrep '#define\s+MAX_[IO]B_QUEUE_ELEMENTS' *.h pm8001_sas.h:#define

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On Tue, 2016-10-25 at 15:16 -0700, Bart Van Assche wrote: > On 10/23/2016 08:20 PM, Gabriel Krisman Bertazi wrote: > > + > > /** > > * scsi_execute - insert request and wait for the result > > * @sdev: scsi device > > @@ -187,7 +197,14 @@ int scsi_execute(struct scsi_device *sdev, > > const

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On 10/23/2016 08:20 PM, Gabriel Krisman Bertazi wrote: + /** * scsi_execute - insert request and wait for the result * @sdev: scsi device @@ -187,7 +197,14 @@ int scsi_execute(struct scsi_device *sdev, const unsigned char *cmd, struct request *req; int write =

Re: [PATCH 1/1] libfc: don't have fc_exch_find log errors on a new exchange

On Mon, Oct 24, 2016 at 04:37:59PM +0200, Hannes Reinecke wrote: > On 10/21/2016 11:10 PM, Chris Leech wrote: > >With the error message I added in "libfc: sanity check cpu number > >extracted from xid" I didn't account for the fact that fc_exch_find is > >called with FC_XID_UNKNOWN at the start of

[Bug 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once

https://bugzilla.kernel.org/show_bug.cgi?id=121531 Chloé Desoutter changed: What|Removed |Added CC|

[Bug 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once

https://bugzilla.kernel.org/show_bug.cgi?id=121531 --- Comment #17 from Chloé Desoutter --- Created attachment 242701 --> https://bugzilla.kernel.org/attachment.cgi?id=242701=edit pm8001_defs.h patch PM8001_MPI_QUEUE: 1024 → 512 (more stable) -- You are receiving

Re: [PATCH 02/10] mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first.

On 20.10.2016 14:20, Suganath Prabu S wrote: > No. of MSIX vectors supported = min (Total no. of CPU cores, > MSIX vectors supported by card) > > when RDPQ is disabled "max_msix_vectors" module parameter which was > declared as global was set to '8' and hence if there are more than one card > in

Re: [PATCH 10/10] mpt3sas: Fix for Endianness issue.

On 20.10.2016 14:20, Suganath Prabu S wrote: > Use le16_to_cpu only for accessing two byte data provided by controller. > > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S

Re: [PATCH 09/10] mpt3sas: Use the new MPI 2.6 32-bit Atomic Request Descriptors for SAS35 devices.

On 20.10.2016 14:20, Suganath Prabu S wrote: > Support Atomic Request Descriptors for Ventura/SAS35 devices. > > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S

Re: [PATCH 01/10] mpt3sas: Fix for improper info displayed in var log, while blocking or unblocking the device.

On 20.10.2016 14:20, Suganath Prabu S wrote: > Return value and Device_handle Arguments passed in correct order > to match with its format string. > > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath

Re: [PATCH 04/10] mpt3sas: Removing unused macro "MPT_DEVICE_TLR_ON"

On 20.10.2016 14:20, Suganath Prabu S wrote: > Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused > > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S

Re: [PATCH 07/10] mpt3sas: Increased/Additional MSIX support for SAS35 devices.

On 20.10.2016 14:20, Suganath Prabu S wrote: > For SAS35 devices MSIX vectors are inceased to 128 from 96. To support this > Reply post host index register count is increased to 16. Also variable > msix96_vector is replaced with combined_reply_queue and variable > combined_reply_index_count is

Re: [PATCH 08/10] mpt3sas: set EEDP-escape-flags for SAS35 devices.

On 20.10.2016 14:20, Suganath Prabu S wrote: > An UNMAP command on a PI formatted device will leave the Logical Block > Application Tag and Logical Block Reference Tag as all F's (for those LBAs > that are unmapped). To avoid IO errors if those LBAs are subsequently read > before they are written

Re: [PATCH 06/10] mpt3sas: Added Device ID's for SAS35 devices and updated MPI header.

On 20.10.2016 14:20, Suganath Prabu S wrote: > Added Device ID's for SAS35 devices (Ventura, Crusader, Harpoon & > Tomcat) and updated mpi header file for the same. Also added > "is_gen35_ioc" to MPT3SAS_ADAPTER structure for identifying SAS35 adapters. > > Signed-off-by: Chaitra P B

Re: [PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

On 01:20 Mon 24 Oct , Gabriel Krisman Bertazi wrote: > James, > > I fixed the things you pointed out on the previous review. As > discussed, I didn't change the code to reuse the request yet. We can > follow up on that later. > > Thanks, > > >8 > > Usually, re-sending the SCSI command is

[PATCH v2] block: Fix kernel panic occurs while creating second raid disk

From: Sreekanth Reddy Observing below kernel panic while creating second raid disk on LSI SAS3008 HBA card. [ +0.55] [ cut here ] [ +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 [ +0.02] sysfs:

Re: [PATCH 03/10] mpt3sas: Implement device_remove_in_progress check in IOCTL path

Hi Hannes, Thanks, >From facts.MaxDevHandle value from firmware, driver will get to know the max device handle or devices that it can support. Based on that value only driver will allocate memory for bit mapping. And driver will not receive any events from controller, if it exceeds the max

Re: [PATCH 03/10] mpt3sas: Implement device_remove_in_progress check in IOCTL path

On 10/25/2016 11:19 AM, Suganath Prabu Subramani wrote: > Hi Hannes, > > Please give us little more info on the third comment. It ll help us to > understand better and > incorporate required changes. > > Comment is "Why don't you need to check for the size of the bitmap here?" > > i have taken

Re: [PATCH 03/10] mpt3sas: Implement device_remove_in_progress check in IOCTL path

Hi Hannes, Please give us little more info on the third comment. It ll help us to understand better and incorporate required changes. Comment is "Why don't you need to check for the size of the bitmap here?" i have taken care of other two comments in this patch. > /* check if device is

RE: Crash in TCM-LIO

Hello Nicholas, -Original Message- From: Gurumurthy, Anil Sent: 24 October 2016 14:50 To: 'Nicholas A. Bellinger' ; Anil Gurumurthy Cc: linux-scsi ; Malavali, Giridhar ; Tran,

Re: [PATCH v3 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote: > On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote: > > Hm, still behaves for me like I reported for v2: > > http://marc.info/?l=linux-scsi=147637177902937=2 > > Hi Steffen, > > Can you please try the following on

Re: [patch] zfcp: spin_lock_irqsave() is not nestable

On 10/24/2016 10:18 AM, Christian Borntraeger wrote: > On 10/14/2016 10:21 PM, Martin K. Petersen wrote: >>> "Steffen" == Steffen Maier writes: >> >> Steffen> could you please queue this as fix for one of my patches that >> Steffen> went into the 4.9 merge window, so

RE: [Bug 179341] mpt3sas: LSISAS3008 don't see Intel 540s SSD

Hi, Please share driver logs with logging_level set to "0x3f8". If driver cannot be unloaded and loaded,then the module parameter has to be passed as kernel command line in the boot loader as “mpt3sas.logging_level=0x3F8” else if driver module can be unloaded and loaded then simply give

Re: [PATCH v2 00/10] ufs-qcom: phy/hcd: Clean up qcom-ufs phy and ufs-qcom hcd

Hi Martin, On Tue, Oct 25, 2016 at 6:10 AM, Martin K. Petersen wrote: >> "Vivek" == Vivek Gautam writes: > > Vivek, > > Vivek> These patches cleanup the ufs phy driver to an extent. > Vivek> Subsequent patches will target to clean