Re: [PATCH v2 19/24] fnic: Use time64_t to represent trace timestamps

On Wed, Jun 22, 2016 at 7:09 AM, Arnd Bergmann wrote: > On Sunday, June 19, 2016 5:27:18 PM CEST Deepa Dinamani wrote: >> trace timestamps use struct timespec and CURRENT_TIME which >> are not y2038 safe. >> These timestamps are only part of the trace log on the machine >> and are

Re: parisc late boot crash in 4.4-rc, scsi-related

Hi, On Wed, Jun 22, 2016 at 02:52:40PM +0300, Meelis Roos wrote: > > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot. > > > > > > > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel > > > > >4.3.3: > > > This is still present in 4.6, just tested. All

Compensation Fund

View the attached message and contact the paying bank for your payment asap, From Fraud Intelligence Unit United Kingdom Office.docx Description: MS-Word 2007 document

[PATCH] target: fix spelling mistake: "limitiation" -> "limitation"

From: Colin Ian King trivial fix to spelling mistake Signed-off-by: Colin Ian King --- drivers/target/target_core_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_file.c

Re: parisc late boot crash in 4.4-rc, scsi-related

Am Mittwoch, 22. Juni 2016, 14:52:40 schrieb Meelis Roos: > > > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot. > > > > > > > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel > > > > > > > >4.3.3: > > > This is still present in 4.6, just tested. All

Re: Connect-IB not performing as well as ConnectX-3 with iSER

Sagi, Yes you are understanding the data correctly and what I'm seeing. I think you are also seeing the confusion that I've been running into trying to figure this out as well. As far as your questions about SRP, the performance data is from the initiator and the CPU info is from the target (all

Re: Connect-IB not performing as well as ConnectX-3 with iSER

Let me see if I get this correct: 4.5.0_rc3_1aaa57f5_00399 sdc;10.218.128.17;4627942;1156985;18126 sdf;10.218.202.17;4590963;1147740;18272 sdk;10.218.203.17;4564980;1141245;18376 sdn;10.218.204.17;4571946;1142986;18348 sdd;10.219.128.17;4591717;1147929;18269

Re: Connect-IB not performing as well as ConnectX-3 with iSER

There is no need to be concerned about srpt crashing in the latest kernel. Srpt only crashed when I was testing kernels in that change set (7861728..5e47f19) that I identified the 10-15% performance drop in iSER between the 4.5 and 4.6 kernel. My tests from the 4.6 to 4.7rc3 didn't have a problem

Re: [PATCH] target/iblock: use ilog2 to compute block size

This doesn't compute the block size, it computes the number of block in a block device. I think it would be useful to add a generic helper (e.g. in blkdev.h) as this calculation seems to be open coded in various places. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in

Re: [PATCH 5/5] scsi: Do not escalate failed EH command

On Mon, Jun 20, 2016 at 11:35:40AM +0200, Hannes Reinecke wrote: > If an EH command fails there is no need to escalate; we are already > in EH and the escalation will start anyway. I agree with this in principle, but is this really the case for all callers? E.g. the call to scsi_request_sense in

Re: [PATCH 3/5] scsi: make eh_eflags persistent

On Mon, Jun 20, 2016 at 11:35:38AM +0200, Hannes Reinecke wrote: > To detect if a failed command has been retried we must not > clear scmd->eh_eflags when EH finishes. > The flag should be persistent throughout the lifetime > of the command. Please explain what issue this solves - the behavior

Re: [PATCH 4/5] scsi: make asynchronous aborts mandatory

Looks fine and probably should move toward the beginning of the series: Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 1/3] scsi: Move 'scsi_attach_vpd()' prototype to scsi_priv.h

Looks fine, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] scsi: make scsi_eh_scmd_add() always succeed

Agreed, I think trying to handle these sorts of errors isn't going to be helpful, while the WARN_ON at least gives us a chance to diagnose the issue if it ever happened. > + WARN_ON(!shost->ehandler); > > spin_lock_irqsave(shost->host_lock, flags); > + WARN_ON(shost->shost_state

Re: [PATCH 3/3] scsi: consolidate checking for VPD pages

Looks fine, although I wonder if simple calling scsi_device_supports_vpd in scsi_get_vpd_page wouldn't be even better. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 2/3] scsi: disable VPD page check on error

On Mon, Jun 20, 2016 at 08:57:47AM +0200, Hannes Reinecke wrote: > If we encounter an error during initial VPD page scan we should be > setting the 'skip_vpd_pages' bit to avoid further accesses. > Any errors during rescan should be ignored, as we might encounter > temporary I/O errors during

Re: Connect-IB not performing as well as ConnectX-3 with iSER

- Original Message - > From: "Bart Van Assche" > To: "Robert LeBlanc" , "Sagi Grimberg" > > Cc: linux-r...@vger.kernel.org, linux-scsi@vger.kernel.org, "Max Gurtovoy" > > Sent: Wednesday, June

[PATCH] target/iblock: use ilog2 to compute block size

Enabling CONFIG_UBSAN_SANITIZE_ALL on ARM caused a link error: drivers/target/built-in.o: In function `iblock_emulate_read_cap_with_block_size.constprop.1': target_core_iblock.c:(.text+0xc2774): undefined reference to `ilog2_NaN' target_core_iblock.c:(.text+0xc27f8): undefined reference to

Re: [PATCH 1/2] lpfc: support for CPU phys_id and core_id on PowerPC64

Hi Martin, On 06/21/2016 11:16 PM, Martin K. Petersen wrote: Distros are free to carry a patch such as yours. That puts the burden on them and not on upstream which is going in a different direction as outlined by Christoph. This is ultimately Broadcom's decision. It is their driver.

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

On Wednesday, June 22, 2016 2:44:21 PM CEST Tomas Winkler wrote: > > > > There are more than 20 files that have the statement: case cpu_to_... > > Sparse complains about: case __builtin_bswap, not about > > __builtin_constant_p. > > There is even much more in the header files used in

Re: parisc late boot crash in 4.4-rc, scsi-related

On 2016-06-22, at 7:52 AM, Meelis Roos wrote: > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot. > > I've not seen it with 4.4-rc yet, but I've seen it on debian kernel > 4.3.3: >>> This is still present in 4.6, just tested. All my pariscs are broken >>> - A500,

Re: parisc late boot crash in 4.4-rc, scsi-related

> > > > I noticed on RP3440 and A500 that recent 4.4-rc* crashes on boot. > > > > > > > >I've not seen it with 4.4-rc yet, but I've seen it on debian kernel > > > >4.3.3: > > This is still present in 4.6, just tested. All my pariscs are broken > > - A500, RP3410, RP3440. 4.3 is the latest working

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

On Wed, Jun 22, 2016 at 1:25 PM, Levy, Amir (Jer) wrote: > On 2016-06-22 Arnd Bergmann wrote: >> On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote: >> > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler >> wrote: >> > > On Tue, May 3, 2016

RE: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

On 2016-06-22 Arnd Bergmann wrote: > On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote: > > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler > wrote: > > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann > wrote: > > >> On Monday 02 May 2016 16:32:25

Re: [PATCH v2] byteswap: try to avoid __builtin_constant_p gcc bug

On Wednesday, June 22, 2016 11:24:50 AM CEST Tomas Winkler wrote: > On Tue, Jun 21, 2016 at 12:02 PM, Tomas Winkler wrote: > > On Tue, May 3, 2016 at 9:36 AM, Arnd Bergmann wrote: > >> On Monday 02 May 2016 16:32:25 Andrew Morton wrote: > >> #ifdef

Re: Connect-IB not performing as well as ConnectX-3 with iSER

Sagi & Max, Here is the results of SRP using the same ramdisk backstore that I was using from iSER (as same as can be between reboots and restoring targetcli config). I also tested the commit before 9679cc51eb13 (5adabdd122e471fe978d49471624bab08b5373a7) which is included here. I'm not seeing a

Re: Connect-IB not performing as well as ConnectX-3 with iSER

On 06/21/2016 10:26 PM, Robert LeBlanc wrote: Srpt keeps crashing couldn't test If this is reproducible with the latest rc kernel or with any of the stable kernels please report this in a separate e-mail, together with the crash call stack and information about how to reproduce this.

Re: [PATCH V2 resend] libata:fix kernel panic when hotplug

Hi,All Hello, On Mon, Jun 20, 2016 at 06:46:55PM -0700, Dan Williams wrote: On Mon, Jun 20, 2016 at 6:22 PM, Martin K. Petersen wrote: "Tejun" == Tejun Heo writes: In fact,we don't need libata to deal with hotplug in sas environment. So we

Re: 4.8/scsi-queue sligthly outdated

On Tue, Jun 21, 2016 at 10:33:08AM +0200, Hannes Reinecke wrote: > Hi Martin, > > your 4.8/scsi-queue branch sadly is missing the libata zac fixes which > got pulled into upstream with commit > e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697. > > At the same time, upstream hasn't yet pulled in the