Re: [PATCH] ufs: qcom: Properly clear hba priv on failure

On 2016-11-19 22:15, Bjorn Andersson wrote: On Sat 19 Nov 12:30 PST 2016, Subhash Jadavani wrote: On 2016-11-18 12:55, Bjorn Andersson wrote: >In the case where we fail to acquire the phy the hba priv will be set >already, so during cleanup ufs_qcom_setup_clocks() will dereference the >now

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote: > @Maintainers, would you be willing to accept this patch as an interim > fix > for the dastardly WARN while we try to fix the flutter issue? To me this adds a bug to quiet a benign, albeit

[Bug 188061] On quad port QLE2564 can't add in target only 2 ports

https://bugzilla.kernel.org/show_bug.cgi?id=188061 --- Comment #4 from Anthony --- >From rtslib (naa wwn must start with 1 or 2 or 5): def normalize_wwn(wwn_types, wwn): ''' Take a WWN as given by the user and convert it to a standard text representation.

Re: SG does not ignore dxferp (direct io + mmap)

On 2016-11-21 09:24 AM, Ewan D. Milne wrote: On Mon, 2016-11-21 at 11:23 +0200, Eyal Ben David wrote: Hi, The utility I mentioned is just a small program that I wrote to learn more about the problem. It is a very simple read16 with options for mmap and dxferp as null or other. Here is the

Re: [PATCH v3] ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk

On 2016-11-18 23:30, Kiwoong Kim wrote: Some UFS host controllers may think granularities of PRDT length and offset as bytes, not double words. Signed-off-by: Kiwoong Kim --- V2: change the name of the quirk (UFSHCD_QUIRK_BROKEN_DWORD_UTRD -> UFSHCD_QUIRK_PRDT_BYTE_GRAN)

Re: [PATCH v2] ufs: qcom: Properly clear hba priv on failure

On 2016-11-19 22:34, Bjorn Andersson wrote: ufs_qcom_init() sets the hba priv data before attempting to acquire the phy handle, so make sure to clear this in the case of an error. Failing to do this will make ufs_qcom_setup_clocks() operate on the uninitalized host object. Signed-off-by:

Re: SG does not ignore dxferp (direct io + mmap)

On Mon, 2016-11-21 at 12:34 -0500, Douglas Gilbert wrote: > There was also this change which seems closer to the problem area: > > commit 461c7fa126794157484dca48e88effa4963e3af3 > Author: Kirill A. Shutemov > Date: Tue Feb 2 16:57:35 2016 -0800 > >

Re: [PATCH RESEND v4 02/15] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On 11/17/2016 07:09 AM, Johannes Thumshirn wrote: > Don't use fc_bsg_job::request and fc_bsg_job::reply directly, but use > helper variables bsg_request and bsg_reply. This will be helpfull when > transitioning to bsg-lib. > > Signed-off-by: Johannes Thumshirn > Reviewed-by:

[Bug 188061] On quad port QLE2564 can't add in target only 2 ports

https://bugzilla.kernel.org/show_bug.cgi?id=188061 --- Comment #3 from himanshu.madh...@cavium.com --- I would not know that part but from drive point of view any valid WWN should be fine. -- You are receiving this mail because: You are watching the assignee of

[GIT PULL] SCSI fixes for 4.9-rc6

Two small fixes. One prevents timeouts on mpt3sas when trying to use the secure erase protocol which causes the erase protocol to be aborted. The second is a regression in a prior fix which causes all commands to abort during PCI extended error recovery, which is incorrect because PCI EEH is

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

https://bugzilla.kernel.org/show_bug.cgi?id=179341 --- Comment #5 from Badalyan Vyacheslav --- 13.434720] mpt3sas_cm0: device status change: (internal device reset) handle(0x0009), sas address(0x44332211), tag(65535) [ 13.464810] scsi 0:0:1:0: tag#0

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

https://bugzilla.kernel.org/show_bug.cgi?id=179341 Badalyan Vyacheslav changed: What|Removed |Added Kernel Version|4.8.2-1.el7.elrepo.x86_64

Re: [PATCH] xen-scsifront: Add a missing call to kfree

On 22/11/16 04:40, Martin K. Petersen wrote: >> "Juergen" == Juergen Gross writes: > > Juergen, > > Juergen> On 19/11/16 19:22, Quentin Lambert wrote: >>> Most error branches following the call to kmalloc contain a call to >>> kfree. This patch add these calls where they

Re: [PATCH] bfa: turn bfa_mem_{kva,dma}_setup into inline functions

> "Arnd" == Arnd Bergmann writes: Arnd> These two macros cause lots of warnings with gcc-7: Arnd> drivers/scsi/bfa/bfa_svc.c: In function 'bfa_fcxp_meminfo': Arnd> drivers/scsi/bfa/bfa_svc.c:521:103: error: '*' in boolean context, Arnd> suggest '&&' instead

Re: [PATCH v3] ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk

> "Kiwoong" == Kiwoong Kim writes: Hi Kiwoong, Kiwoong> Some UFS host controllers may think granularities of PRDT Kiwoong> length and offset as bytes, not double words. This patch does not apply to 4.10/scsi-queue. Please rebase and resubmit. Thanks! -- Martin K.

Re: [patch] scsi: be2iscsi: allocate enough memory in beiscsi_boot_get_sinfo()

> "Dan" == Dan Carpenter writes: Dan> We accidentally allocate sizeof(u32) instead of sizeof(struct Dan> be_cmd_get_session_resp). Applied to 4.9/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line

Re: [PATCH] xen-scsifront: Add a missing call to kfree

> "Juergen" == Juergen Gross writes: Juergen, Juergen> On 19/11/16 19:22, Quentin Lambert wrote: >> Most error branches following the call to kmalloc contain a call to >> kfree. This patch add these calls where they are missing. >> >> This issue was found with Hector. >>

Re: [PATCH v2] ufs: qcom: Properly clear hba priv on failure

> "Bjorn" == Bjorn Andersson writes: Bjorn> ufs_qcom_init() sets the hba priv data before attempting to Bjorn> acquire the phy handle, so make sure to clear this in the case of Bjorn> an error. Failing to do this will make ufs_qcom_setup_clocks() Bjorn> operate on

Re: [PATCH 1/2] hpsa: cleanup sas_phy structures in sysfs when unloading

> "Johannes" == Johannes Thumshirn writes: Johannes> I don't think the SUSE bugzilla tag is of relevance upstream. Nope. I'd rather have really comprehensive patch descriptions. Johannes> But for sake of completeness we could add a Link: Johannes>

Re: [PATCH] mpt2sas: Fix secure erase premature termination.

On Mon, Nov 21, 2016 at 10:41:38AM +0100, Greg KH wrote: > On Mon, Nov 21, 2016 at 03:05:38PM +0530, Suganath Prabu Subramani wrote: > > Commit id and other details are given below: > > > > commit 18f6084a989ba1b38702f9af37a2e4049a924be6 > > Author: Andrey Grodzovsky > >

Re: SG does not ignore dxferp (direct io + mmap)

Hi, The utility I mentioned is just a small program that I wrote to learn more about the problem. It is a very simple read16 with options for mmap and dxferp as null or other. Here is the source code: == cut here == #include #include #include #include #include #include #include

Re: [PATCH] mpt2sas: Fix secure erase premature termination.

On Mon, Nov 21, 2016 at 03:05:38PM +0530, Suganath Prabu Subramani wrote: > Commit id and other details are given below: > > commit 18f6084a989ba1b38702f9af37a2e4049a924be6 > Author: Andrey Grodzovsky > Date:   Thu Nov 10 09:35:27 2016 -0500 > >     scsi: mpt3sas: Fix

Re: [PATCH] scsi: hisi_sas: Add a missing call to kfree

On 19/11/2016 17:42, Quentin Lambert wrote: Most error branches following the call to hisi_sas_shost_alloc contain a call to kfree. This patch add these calls where they are missing. This issue was found with Hector. I think that this patch is fine. However I have noticed that we should do a

[PATCH 2/2] hpsa: destroy sas transport properties before scsi_host

Unloading the hpsa driver causes warnings [ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 device_del+0x54/0x240() [ 1063.793659] sysfs group 81cf21a0 not found for kobject 'port-2:0' with two different stacks: 1) [ 1063.793774] [] device_del+0x54/0x240 [

[PATCH 0/2] hpsa: fix rmmod issues

This patch set fixes two issues I encountered when removing the hpsa modules with rmmod. Comments and reviews are welcome. Martin Wilck (2): hpsa: cleanup sas_phy structures in sysfs when unloading hpsa: destroy sas transport properties before scsi_host drivers/scsi/hpsa.c | 4 ++-- 1 file

[PATCH 1/2] hpsa: cleanup sas_phy structures in sysfs when unloading

When the hpsa module is unloaded using rmmod, dangling symlinks remain under /sys/class/sas_phy. Fix this by calling sas_phy_delete() rather than sas_phy_free (which, according to comments, should not be called for PHYs that have been set up successfully, anyway). References: bsc#1010946.

Re: [PATCH] scsi: hisi_sas: Add a missing call to kfree

On 11/21/2016 01:53 PM, John Garry wrote: However I have noticed that we should do a call to hisi_sas_free() for this failure, and later failures in the probe. I don't understand why, and would welcome the opportunity to learn something. Quentin -- To unsubscribe from this list: send the

Re: [PATCH 2/2] hpsa: destroy sas transport properties before scsi_host

On Mon, Nov 21, 2016 at 03:04:29PM +0100, Martin Wilck wrote: > Unloading the hpsa driver causes warnings > > [ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 > device_del+0x54/0x240() > [ 1063.793659] sysfs group 81cf21a0 not found for kobject 'port-2:0' > > with two

Re: [PATCH] scsi: hisi_sas: Add a missing call to kfree

On 21/11/2016 13:20, Quentin Lambert wrote: On 11/21/2016 01:53 PM, John Garry wrote: However I have noticed that we should do a call to hisi_sas_free() for this failure, and later failures in the probe. I don't understand why, and would welcome the opportunity to learn something. We call

Re: SG does not ignore dxferp (direct io + mmap)

On Mon, 2016-11-21 at 11:23 +0200, Eyal Ben David wrote: > Hi, > > The utility I mentioned is just a small program that I wrote to learn > more about the problem. > > It is a very simple read16 with options for mmap and dxferp as null or other. > > Here is the source code: > > == cut here == >

Re: [PATCH 1/2] hpsa: cleanup sas_phy structures in sysfs when unloading

On Mon, Nov 21, 2016 at 03:04:28PM +0100, Martin Wilck wrote: > When the hpsa module is unloaded using rmmod, dangling > symlinks remain under /sys/class/sas_phy. Fix this by > calling sas_phy_delete() rather than sas_phy_free (which, > according to comments, should not be called for PHYs that >

Re: use PCI layer IRQ affinity in lpfc

On Fri, Nov 18, 2016 at 08:21:35AM -0800, James Smart wrote: > Hi Christoph, > > We had already done this work in the larger lpfc patch that had been posted > for nvme work. Which one is that? > > I'll look at separating out just the irq part and post a reply. Thanks. -- To unsubscribe from

Re: [PATCH] scsi: hisi_sas: Add a missing call to kfree

On 11/21/2016 03:16 PM, John Garry wrote: On 21/11/2016 13:20, Quentin Lambert wrote: On 11/21/2016 01:53 PM, John Garry wrote: However I have noticed that we should do a call to hisi_sas_free() for this failure, and later failures in the probe. I don't understand why, and would welcome

Re: [PATCH] scsi: hisi_sas: Add a missing call to kfree

On 21/11/2016 14:25, Quentin Lambert wrote: On 11/21/2016 03:16 PM, John Garry wrote: On 21/11/2016 13:20, Quentin Lambert wrote: On 11/21/2016 01:53 PM, John Garry wrote: However I have noticed that we should do a call to hisi_sas_free() for this failure, and later failures in the probe.

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Ewan D. Milne" > To: "Eyal Ben David" > Cc: "Laurence Oberman" , dgilb...@interlog.com, > linux-scsi@vger.kernel.org > Sent: Monday, November 21, 2016 9:24:35 AM > Subject: Re: SG does not ignore

Re: SG does not ignore dxferp (direct io + mmap)

Thanks for your reply, On RHEL system it does not occur. So far I have seen the problem on Ubuntu 16.04 and Fedora 22 (both with kernel 4.4.x) 2016-11-21 16:24 GMT+02:00 Ewan D. Milne : > On Mon, 2016-11-21 at 11:23 +0200, Eyal Ben David wrote: >> Hi, >> >> The utility I

Re: SG does not ignore dxferp (direct io + mmap)

- Original Message - > From: "Eyal Ben David" > To: emi...@redhat.com > Cc: "Laurence Oberman" , dgilb...@interlog.com, > linux-scsi@vger.kernel.org > Sent: Monday, November 21, 2016 9:55:29 AM > Subject: Re: SG does not ignore dxferp (direct io +

Re: [PATCH 1/2] hpsa: cleanup sas_phy structures in sysfs when unloading

On Mon, 2016-11-21 at 15:13 +0100, Johannes Thumshirn wrote: > On Mon, Nov 21, 2016 at 03:04:28PM +0100, Martin Wilck wrote: > > When the hpsa module is unloaded using rmmod, dangling > > symlinks remain under /sys/class/sas_phy. Fix this by > > calling sas_phy_delete() rather than sas_phy_free

Re: SG does not ignore dxferp (direct io + mmap)

On Mon, Nov 21, 2016 at 04:15:52PM +0100, Johannes Thumshirn wrote: > On Mon, Nov 21, 2016 at 04:55:29PM +0200, Eyal Ben David wrote: > > Thanks for your reply, > > > > On RHEL system it does not occur. > > > > So far I have seen the problem on Ubuntu 16.04 and Fedora 22 (both > > with kernel

Re: SG does not ignore dxferp (direct io + mmap)

On Mon, Nov 21, 2016 at 04:55:29PM +0200, Eyal Ben David wrote: > Thanks for your reply, > > On RHEL system it does not occur. > > So far I have seen the problem on Ubuntu 16.04 and Fedora 22 (both > with kernel 4.4.x) FWIW: jthumshirn@linux-x5ow:~$ sudo ./sg_mmap_read -d /dev/sg0 -l 0 |

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

@Maintainers, would you be willing to accept this patch as an interim fix for the dastardly WARN while we try to fix the flutter issue? To me this adds a bug to quiet a benign, albeit noisy, warning. What is the bug which is being added? The bug where we queue a port teardown, but see a

Re: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes

On 18.11.2016 17:48, Kashyap Desai wrote: >> -Original Message- >> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- >> ow...@vger.kernel.org] On Behalf Of Tomas Henzl >> Sent: Friday, November 18, 2016 9:23 PM >> To: Hannes Reinecke; Martin K. Petersen >> Cc: Christoph Hellwig;

Re: SG does not ignore dxferp (direct io + mmap)

On Mon, 2016-11-21 at 16:15 +0100, Johannes Thumshirn wrote: > > FWIW: > jthumshirn@linux-x5ow:~$ sudo ./sg_mmap_read -d /dev/sg0 -l 0 | hexdump > 000 c033 d08e 00bc 8e7c 8ec0 bed8 7c00 00bf > 010 b906 0200 f3fc 50a4 1c68 cb06 b9fb 0004 > 020 bebd 8007 007e 7c00 0f0b 0e85 8301 10c5 >

Re: SG does not ignore dxferp (direct io + mmap)

I am using the disro kernels, don't know if they have the patch. Our IO testing utility use the same pattern (mmap + non-null dxferp) for a long time, on RHEL 6.x, 7.x and Ubuntu 12.04, 14.04 without a problem, long before the patch was applied. Thanks, Eyal 2016-11-21 17:44 GMT+02:00 Johannes

[Bug 188061] On quad port QLE2564 can't add in target only 2 ports

https://bugzilla.kernel.org/show_bug.cgi?id=188061 --- Comment #2 from Anthony --- targetcli-2.1.fb43-2.fc25.noarch python3-rtslib-2.1.fb60-2.fc25.noarch I found possible reason and ugly workaround: in package RTSLib file utils.py change REGEXP to validate WWN