Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

Great news, that it works for you! Thanks a lot! Pavel On 11/22/2017 03:49 AM, Stuart Hayes wrote: My apologies... yes, your patch also fixes my issue. I was looking at the two new places from which you were calling scsi_eh_wakeup(), and didn't notice that you moved the spinlock in

Re: scsi fixes for non cache-coherent architectures (for 4.15 and stable)

Christoph, > this series fixes scsi and libsas operations on platforms with cache > incoherent dma operations. Patch 2 and 3 are originally from Huacai Chen, > but I've modified patch two so that it doesn't require his > dma_get_cache_alignment() rework, which I'd rather get into the next >

Re: [PATCH] scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg

Gustavo A., > _vreg_ is being dereferenced before it is null checked, hence there is a > potential null pointer dereference. > > Fix this by moving the pointer dereference after _vreg_ has been null > checked. Applied to 4.15/scsi-fixes, thank you! -- Martin K. Petersen Oracle Linux

Re: [PATCH] scsi: hpsa: remove an unecessary NULL check

Dan, > device->scsi3addr[] is an array, not a pointer, so it can't be NULL. > I've removed the check. Applied to 4.16/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v3 00/17] lpfc updates for 11.4.0.5

James, > This patch set provides a number of bug fixes and additions to > the driver. > > The patches were cut against the Martin's 4.15/scsi-queue tree. > There are no outside dependencies and are expected to be pulled > via Martins tree. Applied to 4.16/scsi-queue. Thank you! -- Martin K.

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

My apologies... yes, your patch also fixes my issue. I was looking at the two new places from which you were calling scsi_eh_wakeup(), and didn't notice that you moved the spinlock in scsi_device_unbusy()... moving the spinlock in scsi_device_unbusy() also should the issue I'm seeing, given

[PATCH] [SCSI] fnic: Fix coccinelle warnings

Remove the duplicate copies of this simple function and use an open-coded version. drivers/scsi/fnic/fnic_debugfs.c:122:11-31: WARNING opportunity for simple_open, see also structure on line 223 Generated by: coccinelle/api/simple_open.cocci Signed-off-by: Vasyl Gomonovych

Re: [PATCH] scsi: ufs: Fix Runtime PM

On 2017-11-13 01:14, Michal Potomski wrote: From: Michał Potomski Recent testing of Runtime PM for UFS has shown it's not working as intended. To acheive fully working Runtime PM, first we have to put back scsi_device autopm reference counter. Existing

Re: [PATCH] scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg

On 2017-11-20 06:12, Gustavo A. R. Silva wrote: _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle.

Re: [REPOST PATCH] scsi: ses: don't ask for diagnostic pages repeatedly during probe

Supporting info for the use case this patch addresses: On 14/11/2017 10:48, Li Dongyang wrote: > We are testing if there is a match with the ses device in a loop > by calling ses_match_to_enclosure(), which will issue scsi receive > diagnostics commands to the ses device for every device on the >

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

On Tue, 2017-09-05 at 15:54 +0300, Pavel Tikhomirov wrote: > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index f6097b89d5d3..6c99221d60aa 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -320,12 +320,11 @@ void scsi_device_unbusy(struct scsi_device

Re: [PATCH] scsi_debug: add cdb_len parameter

On Wed, 2017-11-15 at 23:36 -0500, Douglas Gilbert wrote: > -#define SDEBUG_VERSION "1.86" > -static const char *sdebug_version_date = "20160430"; > +#define SDEBUG_VERSION "1.87" > +static const char *sdebug_version_date = "20171105"; Is this kind of version information really useful for an

[PATCH 1/3] dma-mapping: always provide dma_get_cache_alignment

Provide the dummy version of dma_get_cache_alignment that always returns 1 even if CONFIG_HAS_DMA is not set, so that drivers and subsystems can use it without ifdefs. Cc: sta...@vger.kernel.org Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file

[PATCH 2/3] scsi: use dma_get_cache_alignment() as minimum DMA alignment

From: Huacai Chen In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so scsi's block queue should be aligned to the value returned by dma_get_cache_alignment(). Otherwise, If a DMA buffer and a kernel structure share a same cache line,

[PATCH 3/3] libsas: align sata_device's rps_resp on a cacheline

From: Huacai Chen The rps_resp buffer in ata_device is a DMA target, but it isn't explicitly cacheline aligned. Due to this, adjacent fields can be overwritten with stale data from memory on non-coherent architectures. As a result, the kernel is sometimes unable to communicate

scsi fixes for non cache-coherent architectures (for 4.15 and stable)

Hi Martin, this series fixes scsi and libsas operations on platforms with cache incoherent dma operations. Patch 2 and 3 are originally from Huacai Chen, but I've modified patch two so that it doesn't require his dma_get_cache_alignment() rework, which I'd rather get into the next merge window

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

JFYI these patch is in Virtuozzo7 kernel from September, and we have no issues found with it until now by out testing, and initial problem does not reproduce for 2.5 months.

Re: [PATCH v15 5/5] PCI: Remove PCI pool macro functions

Whoops, my bad. Sorry Thanks, Romain 2017-11-20 21:34 GMT+01:00 Bjorn Helgaas : > On Mon, Nov 20, 2017 at 08:32:47PM +0100, Romain Perier wrote: >> From: Romain Perier >> >> Now that all the drivers use dma pool API, we can remove the macro >>

Re: [PATCH v3 13/17] lpfc: Correct driver deregistrations with host nvme transport

On 11/21/2017 01:00 AM, James Smart wrote: > The driver's interaction with the host nvme transport has been > incorrect for a while. The driver did not wait for the unregister > callbacks (waited only 5 jiffies). Thus the driver may remove > objects that may be referenced by subsequent abort

Re: [PATCH v3 11/17] lpfc: Linux LPFC driver does not process all RSCNs

On 11/21/2017 01:00 AM, James Smart wrote: > During RSCN storms, the driver does not rediscover some targets. > The driver marks some RSCN as to be handled after the ones it's > working on. The driver missed processing some deferred RSCN. > > Move where the driver checks for deferred RSCNs and

Re: [PATCH] scsi/eh: fix hang adding ehandler wakeups after decrementing host_busy

My patch should also fix your issue too, please see explanation in reply to your patch. Do your testing show that it doesn't? Thanks, Pavel. On 11/21/2017 09:10 AM, Stuart Hayes wrote: Pavel, It turns out that the error handler on our systems was not getting woken up for a different

Re: [PATCH] scsi_error: ensure EH wakes up on error to prevent host getting stuck

On 11/20/2017 10:11 PM, Stuart Hayes wrote: When a command is added to the host's error handler command queue, there is a chance that the error handler will not be woken up. This can happen when one CPU is running scsi_eh_scmd_add() at the same time as another CPU is running