Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche wrote: > On 10/01/16 15:56, Ming Lei wrote: >> >> If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(), >> the >> above code needn't to be duplicated any more. > > > Hello Ming, > > Can you have a look

Re: How to increase RAID/HBA controller's timeout?

> Well, this looks more like the ATA error recovery not working properly; > libata-eh is trying to reset the link (that's the 'hard resetting link' > message), but after that the device doesn't respond (that's the 'failed > to IDENTIFY' message). > So it's not so much a wrong timeout, it's a wrong

Re: [PATCH] fnic: Use time64_t to represent trace timestamps

On Sat, Oct 01, 2016 at 04:48:14PM -0700, 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 not shared with the fnic. > Replace then with y2038 safe struct timespec64

Re: How to increase RAID/HBA controller's timeout?

On 10/02/2016 07:51 PM, Dāvis Mosāns wrote: > I've HighPoint RocketRAID 2760A which uses mvsas driver. > > And I need to increase it's timeout because it timeouts too early and > doesn't allow HDD to finish it's recovery routine for unreadable > sector (that HDD doesn't support TLER) > > I've

Re: [PATCH] scsi_dh_alua: Fix a reference counting bug

On 09/29/2016 07:01 PM, Bart Van Assche wrote: > On 09/28/2016 10:46 PM, Hannes Reinecke wrote: >> On 09/29/2016 01:45 AM, Bart Van Assche wrote: >>> The code at the end of alua_rtpg_work() is as follows: >>> >>> scsi_device_put(sdev); >>> kref_put(>kref, release_port_group); >>> >>> Make

Re: iscsi_trx going into D state

On Fri, Sep 30, 2016 at 11:14:57AM -0600, Robert LeBlanc wrote: > We are having a reoccurring problem where iscsi_trx is going into D > state. It seems like it is waiting for a session tear down to happen > or something, but keeps waiting. We have to reboot these targets on > occasion. This is

Re: [PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

On 10/04/2016 07:40 AM, Finn Thain wrote: > This patch series has fixes for compatibility, reliability and > performance issues and some cleanup. It also includes a new version > of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380. > > I've tested this patch series on a Powerbook

Re: iscsi_trx going into D state

On 10/04/2016 09:55 AM, Johannes Thumshirn wrote: > On Fri, Sep 30, 2016 at 11:14:57AM -0600, Robert LeBlanc wrote: >> We are having a reoccurring problem where iscsi_trx is going into D >> state. It seems like it is waiting for a session tear down to happen >> or something, but keeps waiting. We

[Bug 153171] scsi host6: runtime PM trying to activate child device host6 but parent (2-2:1.0) is not active

https://bugzilla.kernel.org/show_bug.cgi?id=153171 --- Comment #9 from Christian Stadelmann --- (In reply to Christian Stadelmann from comment #6) > It seems like this bug is preventing me on these machines to use any USB > thumb drives at all. In case anyone can confirm

[PATCH v2 0/3] hisi_sas add hip07 support

This patchset introduces support for hip07 SoC. The hip07 SoC has the same v2 hw as in hip06. Support for different reference clock is required as some SAS registers need be programmed differently, depending on the refclock rate. Related patchset: - https://patchwork.ozlabs.org/patch/665172/

[PATCH v2 1/3] devicetree: bindings: scsi: hisi_sas add hip07 support

Add support for hip07 chipset to hisi_sas controller. Chipset hip07 has v2 hw. Signed-off-by: John Garry Signed-off-by: Xiang Chen --- Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 3/3] hisi_sas: add v2 hw support for different refclk

The hip06 D03 and hip07 D05 boards have different reference clock frequencies for the SAS controller. Register PHY_CTRL needs to be programmed differently according to this frequency, so add support for this. The default register setting in PHY_CTRL is for 50MHz, so only update this register

RE: [PATCH] scsi: ufs: add support for BLKSECDISCARD

Hi, Adding Szymon, who took over Pawel's work. Tomek -Original Message- From: subha...@codeaurora.org [mailto:subha...@codeaurora.org] Sent: Tuesday, September 27, 2016 10:18 PM To: Wodkowski, PawelX Cc: linux-scsi@vger.kernel.org; hun...@vger.kernel.org; Hunter, Adrian;

Re: iscsi_trx going into D state

On Tue, Oct 04, 2016 at 11:11:18AM +0200, Hannes Reinecke wrote: > Hmm. Looking at the code it looks as we might miss some calls to > 'complete'. Can you try with the attached patch? That only looks slightly better than the original. What this really needs is a waitqueue and and waitevent on

[PATCH v2 2/3] hisi_sas: add device tree support for hip07

Chipset hip07 incorporates v2 hw. Signed-off-by: John Garry Signed-off-by: Xiang Chen --- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c

Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()

On 10/01/16 15:56, Ming Lei wrote: If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(), the above code needn't to be duplicated any more. Hello Ming, Can you have a look at the attached patch? That patch uses an srcu read lock for all queue types, whether or not the

Re: iscsi_trx going into D state

Do you want me to try this patch or wait for some of the suggestions Christoph brought up to be Incorporated? Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Tue, Oct 4, 2016 at 5:46 AM, Christoph Hellwig wrote: > On Tue,

Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md

On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: > While trying to do a discard inside an ESXi 6 VM to an LVM device atop > an md RAID1 device composed of two SATA SSDs passed up as a raw disk > mappings through a PVSCSI controller, this BUG followed by an Oops was > hit: > >

BUG and Oops while trying to issue a discard to LVM on RAID1 md

While trying to do a discard inside an ESXi 6 VM to an LVM device atop an md RAID1 device composed of two SATA SSDs passed up as a raw disk mappings through a PVSCSI controller, this BUG followed by an Oops was hit: [ 86.902888] [ cut here ] [ 86.904600] kernel BUG at