Re: Need some pointers to debug a target hang

Hello Johannes, Apologies for the extended delayed follow-up on this bug report. On Fri, 2016-09-02 at 16:14 +0200, Johannes Thumshirn wrote: > Hi Nick et al, > > I'm having a "interesting" problem with the kernel's iSCSI target and > could use a debug hint. > > My target uses an iblock

[PATCH] Revert "target: Fix residual overflow handling in target_complete_cmd_with_length"

From: Nicholas Bellinger This reverts commit c1ccbfe0311e2380a6d2dcb0714b36904f5d586f. Reverting this patch, as it incorrectly assumes the additional length for INQUIRY in target_complete_cmd_with_length() is SCSI allocation length, which breaks existing user-space code

[PATCH 7/7] ufs-qcom: phy/hcd: Refactoring phy clock handling

Add phy clock enable code to phy_power_on/off callbacks, and remove explicit calls to enable these phy clocks from the ufs-qcom hcd driver. Signed-off-by: Vivek Gautam Reviewed-by: Subhash Jadavani --- drivers/phy/phy-qcom-ufs.c | 12

[PATCH 3/7] phy: qcom-ufs: Use devm sibling of kstrdup for regulator names

This helps us in avoiding any requirement for kfree() operation to be called exclusively over the allocated string pointer. Signed-off-by: Vivek Gautam Reviewed-by: Subhash Jadavani --- drivers/phy/phy-qcom-ufs.c | 5 + 1 file changed,

[PATCH 1/7] phy: qcom-ufs: remove failure when rx/tx_iface_clk are absent

From: Yaniv Gardi Since in future UFS Phy's the tx_iface_clk and rx_iface_clk are no longer exist, we should not fail when their initialization fail, but rather just report with debug message. Signed-off-by: Yaniv Gardi Signed-off-by: Vivek Gautam

[PATCH 5/7] phy: qcom-ufs: Cleanup clock and regulator initialization

Different methods pass around generic phy pointer to extract device pointer. Instead, pass the device pointer directly between function calls. Signed-off-by: Vivek Gautam Reviewed-by: Subhash Jadavani --- drivers/phy/phy-qcom-ufs-i.h

[PATCH 6/7] phy: qcom-ufs-qmp-xx: Move clock and regulator init out of phy init

The phy init is meant to do phy initialization rather than just getting the clock and regulator. Move these clock and regulator get to probe(), to make room for actual phy initialization sequence. Signed-off-by: Vivek Gautam Reviewed-by: Subhash Jadavani

[PATCH 2/7] phy: qcom-ufs: Remove unnecessary BUG_ON

BUG_ON() are not preferred in the driver, plus the variable on which BUG_ON is asserted is already checked in the code before passing. Signed-off-by: Vivek Gautam Reviewed-by: Subhash Jadavani --- drivers/phy/phy-qcom-ufs.c | 2 -- 1 file

[PATCH 4/7] phy: qcom-ufs-qmp-xx: Discard remove callback for drivers.

remove() callback does a phy_exit() only and nothing else now. The phy_exit() over the generic phy is called from the phy consumer, and phy provider driver should not explicitly need to call any phy_exit(). So discard the remove callback for qcom-ufs phy platform drivers. Signed-off-by: Vivek

[PATCH 0/7] ufs-qcom: phy/hcd: Clean up qcom-ufs phy and ufs-qcom hcd

These patches cleanup the ufs phy driver to an extent. Subsequent patches will target to clean the phy_init() of these qcom-ufs phy drivers in order to get rid of a number of exported APIs that phy drivers expose for ufs-qcom hcd driver to use. These patches are based on linux-phy next branch,

Re: iscsi_trx going into D state

Hi Robert, I think the reason why you can not logout the targets is that iscsi_np in D status. I think the patches fixed something, but it seems to be more than one code path can trigger these similar issues. as you can see, there are several call stacks, I am still working on it. Actually

Re: [RESEND PATCH] scsi: ufs: fix race between clock gating and devfreq scaling work

On 2016-10-14 13:47, Martin K. Petersen wrote: "Subhash" == Subhash Jadavani writes: Subhash> UFS devfreq clock scaling work may require clocks to be ON if Subhash> it need to execute some UFS commands hence it may request for Subhash> clock hold before issuing the

[PATCH v1 09/11] scsi: ufs: change device rails hpm mode ramp up sequence

When we are resuming the UFS device rails in HPM mode, we are first powering on the VCC rail while VCCQ and VCCQ2 rails still being in LPM mode. Some UFS devices may take VCC on event as hint that host wants UFS device to be resumed and may start drawing more power from the VCCQ/VCCQ2 rails (while

[PATCH v1 10/11] scsi: ufshcd: Fix race between clk scaling and ungate work

From: Venkat Gopalakrishnan The ungate work turns on the clock before it exits hibern8, if the link was put in hibern8 during clock gating work. There occurs a race condition when clock scaling work calls ufshcd_hold() to make sure low power states cannot be entered, but

[PATCH v1 11/11] scsi: ufs: optimize clock gate work

From: Venkat Gopalakrishnan In a case where gate work is called as part of cancel work from ungate path the clk state would be marked as REQ_CLKS_ON. There is no point gating the clocks and then end up turning them ON immediately in ungate work, save time by skipping the

[PATCH v1 03/11] scsi: ufs: fix bugs related to null pointer access and array size

From: Yaniv Gardi In this change there are a few fixes of possible NULL pointer access and possible access to index that exceeds array boundaries. Signed-off-by: Yaniv Gardi Signed-off-by: Subhash Jadavani ---

[PATCH v1 04/11] scsi: ufs: commit descriptors before setting the doorbell

From: Gilad Broner Add a write memory barrier to make sure descriptors prepared are actually written to memory before ringing the doorbell. We have also added the write memory barrier after ringing the doorbell register so that controller sees the new request immediately.

[PATCH v1 08/11] scsi: ufs: suspend clock scaling at the start of suspend

Currently clock scaling is suspended only after the host and device are put in low power mode but we should avoid clock scaling running after UFS link is put in low power mode (hibern8). This change suspends clock scaling before putting host/device in low power mode. Signed-off-by: Subhash

[PATCH v1 07/11] scsi: ufs: fail ufshcd_probe_hba() if power configuration fails

From: Dov Levenglick In case the power configuration fails, skip further processing of the probing function and return immediately. This has 2 reasons: 1. Don't allow the UFS to continue running in PWM 2. Avoid multiple calls to pm_runtime_put_sync() when not in error

[PATCH v1 05/11] scsi: ufs: fix sense buffer size to 18 bytes

From: Gilad Broner According to UFS device specification, sense data can be only 18 bytes long, this change makes the changes accordingly. Signed-off-by: Gilad Broner Signed-off-by: Subhash Jadavani ---

[PATCH v1 06/11] scsi: ufs: suspend clock scaling for failed runtime_resume

From: Gilad Broner During runtime resume operation, clock scaling may get indirectly resumed via call to ufshcd_set_dev_pwr_mode(): Start/Stop Unit command times out and SCSI error handling ultimately calls the host reset handler to recover, during which clock scaling is

Re: iscsi_trx going into D state

Sorry hit send too soon. In addition, on the client we see: # ps -aux | grep D | grep kworker root 5583 0.0 0.0 0 0 ?D11:55 0:03 [kworker/11:0] root 7721 0.1 0.0 0 0 ?D12:00 0:04 [kworker/4:25] root 10877 0.0 0.0 0 0 ?

Re: iscsi_trx going into D state

In addition, on the client we see: Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Mon, Oct 17, 2016 at 10:32 AM, Robert LeBlanc wrote: > Some more info as we hit this this morning. We have volumes mirrored > between

[PATCH v6 2/3] ata: Enabling ATA Command Priorities

This patch checks to see if an ATA device supports NCQ command priorities. If so and the user has specified an iocontext that indicates IO_PRIO_CLASS_RT then we build a tf with a high priority command. This is done to improve the tail latency of commands that are high priority by passing priority

[PATCH v6 3/3] ata: ATA Command Priority Disabled By Default

Add a sysfs entry to turn on priority information being passed to a ATA device. By default this feature is turned off. This patch depends on ata: Enabling ATA Command Priorities Signed-off-by: Adam Manzanares --- drivers/ata/libahci.c | 1 +

[PATCH v6 1/3] block: Add iocontext priority to request

Patch adds an association between iocontext ioprio and the ioprio of a request. This is done to enable request based drivers the ability to act on priority information stored in the request. An example being ATA devices that support command priorities. If the ATA driver discovers that the device

[PATCH v6 0/3] Enabling ATA Command Priorities

This patch builds ATA commands with high priority if the iocontext of a process is set to real time. The goal of the patch is to improve tail latencies of workloads that use higher queue depths. This requires setting the iocontext ioprio on the request when it is initialized This patch has been

Re: [GIT PULL] final round of SCSI updates for the 4.8+ merge window

> "Finn" == Finn Thain writes: >> Ondrej Zary (3): scsi: g_NCR5380: Stop using scsi_module.c Finn> I believe that patch introduces an .init.text section mismatch, Finn> that I failed to notice when I reviewed it. So you may want Arnd Finn> Bergmann's fix which is

Re: [PATCH] lpfc: use %zd format string for size_t

> "Arnd" == Arnd Bergmann writes: Arnd> A recent bugfix introduced a harmless warning in the lpfc driver: Arnd> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware': Arnd> drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects Arnd> argument of type

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On Mon, 2016-10-17 at 23:06 +0530, Kashyap Desai wrote: > > -Original Message- > > From: James Bottomley [mailto:j...@linux.vnet.ibm.com] > > Sent: Monday, October 17, 2016 10:50 PM > > To: Ric Wheeler; Hannes Reinecke; Sumit Saxena; > > linux-scsi@vger.kernel.org > > Cc:

Re: [PATCH 00/24] FCoE VN2VN fixes, part two

> "Hannes" == Hannes Reinecke writes: Hannes> Hi all, here's now the second part of my FCoE VN2VN patchset. Hannes> The key points are: Hannes> - Configurable R_A_TOV/E_D_TOV Hannes> - Rework PRLI handling to fix a longstanding bug Hannes> - Correctly handle timed-out xids

Re: [PATCH 0/2] Locking issue in libiscsi and be2iscsi

> "Jitendra" == Jitendra Bhivare writes: Jitendra> These patches are being resent with required changes as per Jitendra> comments for [PATCH 02/28] be2iscsi: Replace _bh with Jitendra> _irqsave/irqrestore Jitendra> In IO handling path, there is no spin_lock

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

> -Original Message- > From: James Bottomley [mailto:j...@linux.vnet.ibm.com] > Sent: Monday, October 17, 2016 10:50 PM > To: Ric Wheeler; Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org > Cc: martin.peter...@oracle.com; the...@redhat.com; > kashyap.de...@broadcom.com; Christoph

Re: [PATCH] sd: assign appropriate log level

On 10/17/2016 10:19 AM, James Bottomley wrote: On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote: From: Shikhar Dogra Reduce chatter on console for usb hotplug. KERN_ERR is too high severity for these messages, moving them to KERN_WARNING It's an error because we

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 01:19 PM, James Bottomley wrote: That's not what I get from the change log. What it says to me is > >that the caches are currently firmware managed. Barring firmware > >bugs, that means that we currently don't have any integrity issues. > >Your understanding (or the change log)

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

On 10/17/2016 11:17 AM, Gabriel Krisman Bertazi wrote: > James Bottomley writes: > >> On Thu, 2016-10-13 at 15:47 -0300, Gabriel Krisman Bertazi wrote: >>> @@ -210,6 +219,13 @@ int scsi_execute(struct scsi_device *sdev, const >>> unsigned char *cmd, >>> */ >>>

Re: [PATCH] sd: assign appropriate log level

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote: > From: Shikhar Dogra > > Reduce chatter on console for usb hotplug. > KERN_ERR is too high severity for these messages, moving them > to KERN_WARNING Perhaps KERN_NOTICE is more appropriate. That's the level for most

Re: [PATCH] sd: assign appropriate log level

On Mon, 2016-10-17 at 09:51 -0700, David Singleton wrote: > From: Shikhar Dogra > > Reduce chatter on console for usb hotplug. > KERN_ERR is too high severity for these messages, moving them > to KERN_WARNING It's an error because we have several USB to IDE bridges that have

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On Mon, 2016-10-17 at 12:27 -0400, Ric Wheeler wrote: > On 10/17/2016 12:20 PM, James Bottomley wrote: > > On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote: > > > On 10/17/2016 07:34 AM, Hannes Reinecke wrote: > > > > On 10/17/2016 12:24 PM, Sumit Saxena wrote: > > > > > megaraid_sas driver

[PATCH] Fix: scsi: megaraid: reduce the scope of pending-list lock to avoid double lock

From: Iago Abal The EBA code analyzer (https://github.com/models-team/eba) reported the following double lock: 1. In function `megaraid_reset_handler' at 2571; 2. take `>pend_list_lock' for the first time at 2602: // FIRST

[PATCH] sd: assign appropriate log level

From: Shikhar Dogra Reduce chatter on console for usb hotplug. KERN_ERR is too high severity for these messages, moving them to KERN_WARNING USB devices never have a Caching Mode page, it doesn't make sense to make it an error when you have tons of USB devices where the

Geschäftsvorschlag!!!

-- Geschäftsvorschlag!!! Ich vermute das diese E-Mail eine Überraschung für Sie sein wird, aber es ist wahr.Ich bin bei einer routinen Überprüfung in meiner Bank (First National Bank von Süd Afrika) wo ich arbeite, auf einem Konto gestoßen, was nicht in anspruch genommen worden ist, wo

RE: [PATCH 3/3] smartpqi: switch to pci_alloc_irq_vectors

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Monday, October 17, 2016 9:21 AM > To: Don Brace > Cc: Johannes Thumshirn; Christoph Hellwig; martin.peter...@oracle.com; > ax...@kernel.dk; linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org > Subject: Re:

Re: iscsi_trx going into D state

Some more info as we hit this this morning. We have volumes mirrored between two targets and we had one target on the kernel with the three patches mentioned in this thread [0][1][2] and the other was on a kernel without the patches. We decided that after a week and a half we wanted to get both

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 12:20 PM, James Bottomley wrote: We really need to have some ways to validate that our IO stack is >properly and safely configured. > >I would love to see a couple of things: > >* having T10 & T13 report the existence of a volatile write cache - >this is different than WCE set,

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 12:20 PM, James Bottomley wrote: On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote: On 10/17/2016 07:34 AM, Hannes Reinecke wrote: On 10/17/2016 12:24 PM, Sumit Saxena wrote: megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer without sending it to

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

James Bottomley writes: > On Thu, 2016-10-13 at 15:47 -0300, Gabriel Krisman Bertazi wrote: >> @@ -210,6 +219,13 @@ int scsi_execute(struct scsi_device *sdev, const >> unsigned char *cmd, >> */ >> blk_execute_rq(req->q, NULL, req, 1); >> >> +if

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On Mon, 2016-10-17 at 12:08 -0400, Ric Wheeler wrote: > On 10/17/2016 11:55 AM, Christoph Hellwig wrote: > > On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote: > >> This must go in - without this fix, there is no data integrity for any > >> file system. > > megaraid always had odd ideas

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On Mon, 2016-10-17 at 09:01 -0400, Ric Wheeler wrote: > On 10/17/2016 07:34 AM, Hannes Reinecke wrote: > > On 10/17/2016 12:24 PM, Sumit Saxena wrote: > > > megaraid_sas driver returns SYNCHRONIZE_CACHE command back to > > > SCSI layer without sending it to firmware as firmware takes care > > >

Re: [PATCH v2 0/6] Fixes for ibmvscsis driver

On 10/14/2016 03:25 PM, Steven Royer wrote: > On 2016-10-13 11:02, Michael Cyr wrote: >> Various fixes and cleanups for the ibmvscsis driver. >> The first is a sort of prequel to the second, which is the primary >> change (and the biggest). The rest are fairly small fixes. >> >> Michael Cyr (6):

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 11:55 AM, Christoph Hellwig wrote: On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote: This must go in - without this fix, there is no data integrity for any file system. megaraid always had odd ideas on cache flushing, and this might be a opportunity to write down all

Re: [PATCH] lpfc: use %zd format string for size_t

Thanks Signed-off-by: James Smart -- james On 10/17/2016 5:35 AM, Arnd Bergmann wrote: A recent bugfix introduced a harmless warning in the lpfc driver: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware': drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error:

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On Mon, Oct 17, 2016 at 09:01:29AM -0400, Ric Wheeler wrote: > This must go in - without this fix, there is no data integrity for any file > system. megaraid always had odd ideas on cache flushing, and this might be a opportunity to write down all the assumptions and document them. > In effect,

Re: [PATCH 2/2] be2iscsi: Replace _bh with _irqsave/irqrestore

On Thu, Oct 13, 2016 at 12:08:49PM +0530, Jitendra Bhivare wrote: > [ 3843.132217] WARNING: CPU: 20 PID: 1227 at kernel/softirq.c:150 > __local_bh_enable_ip+0x6b/0x90 > [ 3843.142815] Modules linked in: > ... > [ 3843.294328] CPU: 20 PID: 1227 Comm: kworker/20:1H Tainted: GE >

Re: [PATCH 1/2] libiscsi: Fix locking in __iscsi_conn_send_pdu

On Thu, Oct 13, 2016 at 12:08:48PM +0530, Jitendra Bhivare wrote: > The code at free_task label in __iscsi_conn_send_pdu can get executed > from blk_timeout_work which takes queue_lock using spin_lock_irq. > back_lock taken with spin_unlock_bh will cause WARN_ON_ONCE. > The code gets executed

Re: `rmmod mpt3sas` leads to backtraces 'fs/sysfs/group.c:237 sysfs_remove_group+0xa0/0xb0'

On Sun, Oct 16, 2016 at 02:33:28PM +, ojab wrote: > Oh hai! > > I have LSI SAS 9217-8i HBA and `rmmod mpt3sas` leads to multiple backtraces > if any disks are connected to the HBA. > Reproducible on vanilla 4.7.5/4.8.1/4.9-rc1 kernels (haven't tested on > another versions). > > Full output

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Monday, October 17, 2016 7:27 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; Kashyap Desai >Subject: Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE

Re: [PATCH 3/3] smartpqi: switch to pci_alloc_irq_vectors

Hi Don, did you also have a chance to test the patch and verify that the queues are properly set up with a smartpqi controller? -- 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 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 17.10.2016 15:28, Sumit Saxena wrote: >> -Original Message- >> From: Tomas Henzl [mailto:the...@redhat.com] >> Sent: Monday, October 17, 2016 6:44 PM >> To: Sumit Saxena; linux-scsi@vger.kernel.org >> Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; >> kashyap.de...@broadcom.com

RE: [PATCH 3/3] smartpqi: switch to pci_alloc_irq_vectors

> -Original Message- > From: Johannes Thumshirn [mailto:jthumsh...@suse.de] > Sent: Monday, October 17, 2016 2:34 AM > To: Christoph Hellwig > Cc: martin.peter...@oracle.com; Don Brace; ax...@kernel.dk; linux- > s...@vger.kernel.org; linux-bl...@vger.kernel.org > Subject: Re: [PATCH 3/3]

Re: [PATCH] lpfc: use %zd format string for size_t

On Mon, Oct 17, 2016 at 02:35:46PM +0200, Arnd Bergmann wrote: > A recent bugfix introduced a harmless warning in the lpfc driver: > > drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware': > drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument > of type 'long

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

>-Original Message- >From: Ric Wheeler [mailto:rwhee...@redhat.com] >Sent: Monday, October 17, 2016 6:31 PM >To: Hannes Reinecke; Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com; Christoph

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

>-Original Message- >From: Tomas Henzl [mailto:the...@redhat.com] >Sent: Monday, October 17, 2016 6:44 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 4/7] megaraid_sas: Send

Re: [PATCH 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

On 17.10.2016 12:24, Sumit Saxena wrote: > Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does > not support JBOD sequence map. > > CC: sta...@vger.kernel.org > Signed-off-by: Sumit Saxena > Signed-off-by: Kashyap Desai

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 17.10.2016 12:24, Sumit Saxena wrote: > megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer > without sending it to firmware as firmware takes care of flushing cache. > This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. > If underlying firmware has

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 07:34 AM, Hannes Reinecke wrote: On 10/17/2016 12:24 PM, Sumit Saxena wrote: megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer without sending it to firmware as firmware takes care of flushing cache. This patch will change the driver behavior wrt

Re: [PATCH 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

On 17.10.2016 12:24, Sumit Saxena wrote: > This patch fixes the issue of wrong PhysArm was sent to firmware for R1 > VD downgrade. > > Signed-off-by: Kiran Kumar Kasturi > Signed-off-by: Sumit Saxena Reviewed-by: Tomas Henzl

Re: [PATCH 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

On 17.10.2016 12:24, Sumit Saxena wrote: > For SRIOV enabled firmware, if there is a OCR(online controller reset) > possibility driver set the convert flag to 1, which is not happening if > there are outstanding commands even after 180 seconds. > As driver does not set convert flag to 1 and still

[PATCH] lpfc: use %zd format string for size_t

A recent bugfix introduced a harmless warning in the lpfc driver: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware': drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument of type 'long int', but argument 9 has type 'size_t {aka const unsigned int}'

RE: [PATCH 5/7] megaraid_sas: driver version upgrade

>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:05 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 5/7]

RE: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:01 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 3/7]

RE: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

>-Original Message- >From: Hannes Reinecke [mailto:h...@suse.de] >Sent: Monday, October 17, 2016 5:04 PM >To: Sumit Saxena; linux-scsi@vger.kernel.org >Cc: martin.peter...@oracle.com; the...@redhat.com; j...@linux.vnet.ibm.com; >kashyap.de...@broadcom.com >Subject: Re: [PATCH 4/7]

Re: [PATCH 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does > not support JBOD sequence map. > > CC: sta...@vger.kernel.org > Signed-off-by: Sumit Saxena > Signed-off-by: Kashyap Desai

Re: [PATCH 6/7] MAINTAINERS: Update megaraid maintainers list

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > Update MEGARAID drivers maintainers list. > > Signed-off-by: Sumit Saxena > --- > MAINTAINERS | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index

Re: [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer > without sending it to firmware as firmware takes care of flushing cache. > This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. > If underlying firmware

Re: [PATCH 5/7] megaraid_sas: driver version upgrade

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > Upgrade driver version. > > Signed-off-by: Sumit Saxena > --- > drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/megaraid/megaraid_sas.h >

Re: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > This patch addresses the issue of driver firing DCMDs in PCI > shutdown/detach path irrespective of firmware state. > Driver will check for whether firmware is operational state or not > before firing DCMDs. If firmware is in unrecoverbale > state or

Re: [PATCH 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > This patch fixes the issue of wrong PhysArm was sent to firmware for R1 > VD downgrade. > > Signed-off-by: Kiran Kumar Kasturi > Signed-off-by: Sumit Saxena > --- >

Re: [PATCH 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

On 10/17/2016 12:24 PM, Sumit Saxena wrote: > For SRIOV enabled firmware, if there is a OCR(online controller reset) > possibility driver set the convert flag to 1, which is not happening if > there are outstanding commands even after 180 seconds. > As driver does not set convert flag to 1 and

[PATCH 5/7] megaraid_sas: driver version upgrade

Upgrade driver version. Signed-off-by: Sumit Saxena --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 43fd14f..1d4de90

[PATCH 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

Do not set MPI2_TYPE_CUDA for JBOD fastpath IOs for firmware which does not support JBOD sequence map. CC: sta...@vger.kernel.org Signed-off-by: Sumit Saxena Signed-off-by: Kashyap Desai --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 8

[PATCH 6/7] MAINTAINERS: Update megaraid maintainers list

Update MEGARAID drivers maintainers list. Signed-off-by: Sumit Saxena --- MAINTAINERS | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f0ee7a6..8b9117f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7612,12

[PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

megaraid_sas driver returns SYNCHRONIZE_CACHE command back to SCSI layer without sending it to firmware as firmware takes care of flushing cache. This patch will change the driver behavior wrt SYNCHRONIZE_CACHE handling. If underlying firmware has support to handle the SYNCHORNIZE_CACHE, driver

[PATCH 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

This patch fixes the issue of wrong PhysArm was sent to firmware for R1 VD downgrade. Signed-off-by: Kiran Kumar Kasturi Signed-off-by: Sumit Saxena --- drivers/scsi/megaraid/megaraid_sas_fp.c | 6 -- 1 file changed, 4

[PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

This patch addresses the issue of driver firing DCMDs in PCI shutdown/detach path irrespective of firmware state. Driver will check for whether firmware is operational state or not before firing DCMDs. If firmware is in unrecoverbale state or does not become operational within specfied time,

[PATCH 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function)

[PATCH 0/7] megaraid_sas: Updates for scsi-next

Sumit Saxena (7): megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade megaraid_sas: Do not fire DCMDs during PCI shutdown/detach megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

Re: [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

On Thu, Oct 13, 2016 at 01:20:20AM +0100, Lorenzo Stoakes wrote: > This patch removes the write parameter from access_process_vm() and replaces > it > with a gup_flags parameter as use of this function previously _implied_ > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.

Re: [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

On Thu, Oct 13, 2016 at 01:20:16AM +0100, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_user_pages() and > replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit > in callers as use of this flag can result in surprising behaviour

Re: `rmmod mpt3sas` leads to backtraces 'fs/sysfs/group.c:237 sysfs_remove_group+0xa0/0xb0'

On 2016/10/16 14:33, ojab wrote: Oh hai! I have LSI SAS 9217-8i HBA and `rmmod mpt3sas` leads to multiple backtraces if any disks are connected to the HBA. Reproducible on vanilla 4.7.5/4.8.1/4.9-rc1 kernels (haven't tested on another versions). Full output (4.9-rc1 kernel, 3*Seagate

Re: [PATCH 2/2] be2iscsi: Replace _bh with _irqsave/irqrestore

On 10/13/2016 08:38 AM, Jitendra Bhivare wrote: > [ 3843.132217] WARNING: CPU: 20 PID: 1227 at kernel/softirq.c:150 > __local_bh_enable_ip+0x6b/0x90 > [ 3843.142815] Modules linked in: > ... > [ 3843.294328] CPU: 20 PID: 1227 Comm: kworker/20:1H Tainted: GE > 4.8.0-rc1+ #3 > [

Re: [PATCH 2/3] scsi: allow LLDDs to expose the queue mapping to blk-mq

On Mon, Oct 17, 2016 at 09:27:03AM +0200, Johannes Thumshirn wrote: > Shouldn't this hunk go into the previous patch? Yes, it should, thanks. -- 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 3/3] smartpqi: switch to pci_alloc_irq_vectors

On Sat, Oct 15, 2016 at 10:47:21AM +0200, Christoph Hellwig wrote: > Which cleans up a lot of the MSI-X handling, and allows us to use the > PCI IRQ layer provided vector mapping, which we can then expose to blk-mq. > > Signed-off-by: Christoph Hellwig > --- Reviewed-by: Johannes

Re: [PATCH 1/3] blk-mq: export blk_mq_map_queues

On Sat, Oct 15, 2016 at 10:47:19AM +0200, Christoph Hellwig wrote: > This will allow SCSI to have a single blk_mq_ops structure that either > lets the LLDD map the queues to PCIe MSIx vectors or use the default. > > Signed-off-by: Christoph Hellwig > --- > block/blk-mq.h |

Re: [PATCH 2/3] scsi: allow LLDDs to expose the queue mapping to blk-mq

On Sat, Oct 15, 2016 at 10:47:20AM +0200, Christoph Hellwig wrote: > Just hand through the blk-mq map_queues method in the host template. > > Signed-off-by: Christoph Hellwig > --- > block/blk-mq-cpumap.c| 1 + > drivers/scsi/scsi_lib.c | 10 ++ >

Re: [PATCH 1/2] libiscsi: Fix locking in __iscsi_conn_send_pdu

On 10/13/2016 08:38 AM, Jitendra Bhivare wrote: > The code at free_task label in __iscsi_conn_send_pdu can get executed > from blk_timeout_work which takes queue_lock using spin_lock_irq. > back_lock taken with spin_unlock_bh will cause WARN_ON_ONCE. > The code gets executed either with bottom