[Bug 151631] "Synchronizing SCSI cache" fails during(and delays) reboot/shutdown

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=151631

Daniele Viganò  changed:

   What|Removed |Added

 CC||dennyvatw...@gmail.com

--- Comment #6 from Daniele Viganò  ---
I can confirm exactly the same bug on my Dell Latitude E5450 with an SSD
(Samsung 840) running Fedora 24 and kernel 4.8.6 (4.7.9 was fine).

The patch provided by Gianpaolo solved the issue on my machine.

-- 
You are receiving this mail because:
You are the assignee for the bug.--
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] hpsa: use pci_alloc_irq_vectors and automatic irq affinity

[Hannes Reinecke]

On 11/09/2016 07:42 PM, Christoph Hellwig wrote:
> This patch converts over hpsa to use the pci_alloc_irq_vectors including
> the PCI_IRQ_AFFINITY flag that automatically assigns spread out
> irq affinity to the I/O queues.
> 
> It also cleans up the per-ctrl interrupt state due to the use of the
> pci_irq_vector and pci_free_irq_vectors helpers that don't need to know
> the exact irq type.  Additionally it changes a little oddity in the
> existing code that was using different array indixes into the per-vector
> arrays depending on wether a controller is using a single INTx or single
> MSI irq.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/scsi/hpsa.c | 143 
> ++--
>  drivers/scsi/hpsa.h |   6 +--
>  2 files changed, 52 insertions(+), 97 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 v1] ufs: add a variety of definitions decribed in UFS spec

[Kiwoong Kim]

Hi, Subhash

I'll update this patch referring what you said below except for creating of
"mphy.h".

> >> > These things are defined to be used by some UFS Host controllers.
> >> >
> >> > Signed-off-by: Kiwoong Kim 
> >> > ---
> >> >  drivers/scsi/ufs/mphy.h   | 38
++
> >> >  drivers/scsi/ufs/ufshci.h | 14 +++---
> >> > drivers/scsi/ufs/unipro.h | 24 
> >> >  3 files changed, 73 insertions(+), 3 deletions(-)  create mode
> >> > 100644 drivers/scsi/ufs/mphy.h
> >> >
> >> > diff --git a/drivers/scsi/ufs/mphy.h b/drivers/scsi/ufs/mphy.h new
> >> > file mode 100644 index 000..c431f49
> >> > --- /dev/null
> >> > +++ b/drivers/scsi/ufs/mphy.h
> >> > @@ -0,0 +1,38 @@
> >> > +/*
> >> > + * drivers/scsi/ufs/mphy.h
> >> > + *
> >> > + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
> >> > + *
> >> > + * This program is free software; you can redistribute it and/or
> >> > modify
> >> > + * it under the terms of the GNU General Public License as
> >> > + published
> >> > by
> >> > + * the Free Software Foundation; either version 2 of the License,
> >> > + or
> >> > + * (at your option) any later version.
> >> > + */
> >> > +
> >> > +#ifndef _MPHY_H_
> >> > +#define _MPHY_H_
> >>
> >> Do we really need separate file for MPHY? May be we can have these
> >> accomodated in unipro.h itself?
> >
> > I think it's needed. MPHY spec isn't related with Unipro spec directly.
> 
> Yes but for UFS host controller, Unipro is the communication channel
> between host and device, includes M-PHY as well.
> 
> > Is there any reason why we say that this file is deprecated?
> > Please let me know if you have.
> 
> These are only few declarations and i guess it would be appopriate to put
> them under UniPro header file. Anyways it is your choice.

As you said, for now, there are not many declarations of mphy.
But I expect adding more in the future.
I think that all other UFS driver including coming new ones, if any,
aren't separated from mphy like "ufs-qcom.c", especially Exynos driver.

Anyway, thank you for your opinion.

> 
> >
> >>
> >> > +
> >> > +#define TX_HIBERN8TIME_CAP  0x0f
> >> > +#define TX_MIN_ACTIVATE_TIME0x33
> >> > +
> >> > +#define RX_HS_G1_SYNC_LEN_CAP   0x8b
> >> > +#define RX_HS_G1_PREP_LEN_CAP   0x8c
> >> > +#define RX_HS_G2_SYNC_LEN_CAP   0x94
> >> > +#define RX_HS_G3_SYNC_LEN_CAP   0x95
> >> > +#define RX_HS_G2_PREP_LEN_CAP   0x96
> >> > +#define RX_HS_G3_PREP_LEN_CAP   0x97
> >> > + #define SYNC_RANGE_FINE(0 << 6)
> >> > + #define SYNC_RANGE_COARSE  (1 << 6)
> >> > + #define SYNC_LEN(x)((x) & 0x3f)
> >> > + #define PREP_LEN(x)((x) & 0xf)
> >> > +#define RX_ADV_GRANULARITY_CAP  0x98
> >> > + #define RX_ADV_GRAN_STEP(x)x) & 0x3) << 1) | 0x1)
> >> > +#define TX_ADV_GRANULARITY_CAP  0x10
> >> > + #define TX_ADV_GRAN_STEP(x)x) & 0x3) << 1) | 0x1)
> >> > +#define RX_MIN_ACTIVATETIME_CAP 0x8f
> >> > +#define RX_HIBERN8TIME_CAP  0x92
> >> > +#define RX_ADV_HIBERN8TIME_CAP  0x99
> >> > +#define RX_ADV_MIN_ACTIVATETIME_CAP 0x9a
> >> > +
> >> > +#endif /* _MPHY_H_ */
> >> > +
> >> > diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h
> >> > index 9599741..26dc340 100644
> >> > --- a/drivers/scsi/ufs/ufshci.h
> >> > +++ b/drivers/scsi/ufs/ufshci.h
> >> > @@ -170,17 +170,25 @@ enum {
> >> >  /* UECDL - Host UIC Error Code Data Link Layer 3Ch */
> >> >  #define UIC_DATA_LINK_LAYER_ERROR   UFS_BIT(31)
> >> >  #define UIC_DATA_LINK_LAYER_ERROR_CODE_MASK 0x7FFF
> >> > -#define UIC_DATA_LINK_LAYER_ERROR_PA_INIT   0x2000
> >> > -#define UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVED  0x0001
> >> > -#define UIC_DATA_LINK_LAYER_ERROR_TCx_REPLAY_TIMEOUT 0x0002
> >> > +#define UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVED  UFS_BIT(0)
> >> > +#define UIC_DATA_LINK_LAYER_ERROR_TCx_REPLAY_TIMEOUTUFS_BIT(1)
> >> > +#define UIC_DATA_LINK_LAYER_ERROR_RX_BUF_OF UFS_BIT(5)
> >>
> >> why don't we just add macros for all the bits in UECDL ? This makes
> >> it easy in future.
> >
> > Okay. I'll think about it and apply new macros on new version of this
> > patch.
> >
> >>
> >> > +#define UIC_DATA_LINK_LAYER_ERROR_PA_INIT   UFS_BIT(13)
> >> >
> >> >  /* UECN - Host UIC Error Code Network Layer 40h */
> >> >  #define UIC_NETWORK_LAYER_ERROR UFS_BIT(31)
> >> >  #define UIC_NETWORK_LAYER_ERROR_CODE_MASK   0x7
> >> > +#define UIC_NETWORK_UNSUPPORTED_HEADER_TYPE BIT(0)
> >> > +#define UIC_NETWORK_BAD_DEVICEID_ENCBIT(1)
> >> > +#define UIC_NETWORK_LHDR_TRAP_PACKET_DROPPING   BIT(2)
> >> >
> >> >  /* UECT - Host UIC Error Code Transport Layer 44h */
> >> >  #define UIC_TRANSPORT_LAYER_ERROR   UFS_BIT(31)
> >> >  #define UIC_TRANSPORT_LAYER_ERROR_CODE_MASK 0x7F
> >> > +#define UIC_TRANSPORT_UNSUPPORTED_HEADER_TYPE   BIT(0)
> >> > 

RE: [PATCH v1] ufs: introduce UFSHCI_QUIRK_SKIP_INTR_AGGR quirk

[Kiwoong Kim]

Hi, Subhash

I'll update this patch referring what you said (including adding comments of
other quirks)

> > If UFS driver resets interrupt aggregation timer and counter when
> > there is a pending doorbell, an interrupt of IO completion of a
> > corresponding task may be missed.
> > That would cause a command timeout.
> >
> > If UFS driver resets interrupt aggregation timer and counter when
> > there is a pending doorbell, a competion interrupt of a corresponing
> > task may be issued.
> > That would casue a command timeout.
> >
> > Signed-off-by: Kiwoong Kim 
> > ---
> >  drivers/scsi/ufs/ufshcd.c | 4 +++-
> >  drivers/scsi/ufs/ufshcd.h | 1 +
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index c904854..65bbf59 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -3730,7 +3730,9 @@ static void ufshcd_transfer_req_compl(struct
> > ufs_hba *hba)
> >  * false interrupt if device completes another request after
> > resetting
> >  * aggregation and before reading the DB.
> >  */
> > -   if (ufshcd_is_intr_aggr_allowed(hba))
> > +   if ((ufshcd_is_intr_aggr_allowed(hba))
> > +   && !(hba->quirks & UFSHCI_QUIRK_SKIP_INTR_AGGR))
> 
> Why do we need this new quirk? If controller has the issue with interrupt
> aggregation, you can remove this UFSHCD_CAP_INTR_AGGR to disable the
> aggregation altogether.
> 
> > +   ufshcd_reset_intr_aggr(hba);
> > ufshcd_reset_intr_aggr(hba);
> >
> > tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
> > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> > index 6a96f24..6a9c6e9 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -497,6 +497,7 @@ struct ufs_hba {
> > #define UFSHCD_QUIRK_BROKEN_DWORD_UTRD  UFS_BIT(7)
> > #define UFSHCD_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(8)
> > #define UFSHCD_QUIRK_USE_OF_HCE UFS_BIT(9)
> > +   #define UFSHCI_QUIRK_SKIP_INTR_AGGR UFS_BIT(10)
> >
> >
> > unsigned int quirks;/* Deviations from standard UFSHCI spec.
> */
> 
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> --
> 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


--
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 v1] ufs: introduce UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR quirk

[Kiwoong Kim]

> > Some UFS host controllers may clear a transfer request slot by setting
> > an associated bit in UTLRCLR/UTMLRCLR to 1, not 0.
> 
> s/UTLRCLR/UTRLCLR
> s/UTMLRCLR/UTMRLCLR
> 

Okay

> 
> > That's opposite to what UFS spec decribes.
> >
> > Signed-off-by: Kiwoong Kim 
> > ---
> >  drivers/scsi/ufs/ufshcd.c | 32 
> > drivers/scsi/ufs/ufshcd.h |  1 +
> >  2 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 549e3e8..24d6ea7 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -392,7 +392,31 @@ static inline void ufshcd_put_tm_slot(struct
> > ufs_hba *hba, int slot)
> >   */
> >  static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)  {
> > -   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
> > +   u32 clear;
> > +
> > +   if (hba->quirks & UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR)
> > +   clear = (1 << pos);
> > +   else
> > +   clear = ~(1 << pos);
> > +
> > +   ufshcd_writel(hba, clear, REG_UTP_TRANSFER_REQ_LIST_CLEAR); }
> > +
> > +/**
> > + * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
> > + * @hba: per adapter instance
> > + * @pos: position of the bit to be cleared  */ static inline void
> > +ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos) {
> > +   u32 clear;
> > +
> > +   if (hba->quirks & UFSHCD_QUIRK_BROKEN_REQ_LIST_CLR)
> > +   clear = (1 << pos);
> > +   else
> > +   clear = ~(1 << pos);
> > +
> > +   ufshcd_writel(hba, clear, REG_UTP_TASK_REQ_LIST_CLEAR);
> >  }
> >
> >  /**
> > @@ -1147,7 +1171,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
> > uic_command *uic_cmd)
> >   *
> >   * Returns 0 in case of success, non-zero value in case of failure
> >   */
> > -static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
> > +static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb
> > +*lrbp)
> 
> unrelated change. Please remove it.
> 

Okay

> >  {
> > struct ufshcd_sg_entry *prd_table;
> > struct scatterlist *sg;
> > @@ -1529,7 +1553,7 @@ static int ufshcd_queuecommand(struct Scsi_Host
> > *host, struct scsi_cmnd *cmd)
> >
> > ufshcd_comp_scsi_upiu(hba, lrbp);
> >
> > -   err = ufshcd_map_sg(lrbp);
> > +   err = ufshcd_map_sg(hba, lrbp);
> 
> unrelated change.  Please remove it.

Okay

> 
> 
> > if (err) {
> > lrbp->cmd = NULL;
> > clear_bit_unlock(tag, >lrb_in_use); @@ -4329,7 +4353,7
> @@
> > static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int tag)
> > goto out;
> >
> > spin_lock_irqsave(hba->host->host_lock, flags);
> > -   ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
> > +   ufshcd_utmrl_clear(hba, tag);
> > spin_unlock_irqrestore(hba->host->host_lock, flags);
> >
> > /* poll for max. 1 sec to clear door bell register by h/w */ diff
> > --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
> > 565f005..c4abd76 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -495,6 +495,7 @@ struct ufs_hba {
> >
> > #define UFSHCD_QUIRK_GET_VS_RESULT  UFS_BIT(6)
> > #define UFSHCD_QUIRK_BROKEN_DWORD_UTRD  UFS_BIT(7)
> > +   #define UFSHCD_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(8)
> >
> >
> > unsigned int quirks;/* Deviations from standard UFSHCI spec.
> */
> 
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> --
> 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


--
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

[Bug 187381] 4.9.-rc4 produces hundreds of unusable scsi devices.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=187381

--- Comment #3 from Samuel Flory Silbory  ---
Seems sane now.
root@pcsnode:~# uname -a
Linux pcsnode 4.9.0-rc4-1-default #1 SMP Wed Nov 9 13:59:28 PST 2016 x86_64
GNU/Linux
root@pcsnode:~# ls /dev/sd*
/dev/sda  /dev/sdc  /dev/sde  /dev/sdg/dev/sdi  /dev/sdk   /dev/sdk2   
/dev/sdk4  /dev/sdk6  /dev/sdl
/dev/sdb  /dev/sdd  /dev/sdf  /dev/sdh/dev/sdj  /dev/sdk1  /dev/sdk3   
/dev/sdk5  /dev/sdk7  /dev/sdm
root@pcsnode:~# 

The only difference compared to 4.8/4/4 is the boot drive on the SATA
controller ended up sdk instead of sdm (the last drive).  It's not an issue for
me as I mount things by UUID


From: Samuel Silbory
Sent: Wednesday, November 09, 2016 1:19 PM
To: James Bottomley; bugzilla-dae...@bugzilla.kernel.org;
linux-scsi@vger.kernel.org
Subject: RE: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi
devices.

Certainly I'll give it a try.

From: James Bottomley [james.bottom...@hansenpartnership.com]
Sent: Wednesday, November 09, 2016 12:49 PM
To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Cc: Samuel Silbory
Subject: Re: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi
devices.

On Wed, 2016-11-09 at 20:20 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D187381=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=67orQXH1IekXCew60eHDOmksAqiZIU69q0eGzoqiWMM=
>
> Bug ID: 187381
>Summary: 4.9.-rc4 produces hundreds of unusable scsi
> devices.
>Product: SCSI Drivers
>Version: 2.5
> Kernel Version: 4.9-rc4
>   Hardware: All
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
>   Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
>   Reporter: samuel.silb...@hds.com
> Regression: No
>
> Created attachment 244091
>   -->
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_attachment.cgi-3Fid-3D244091-26action-3Dedit=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=ypXf8FCNK77zZPf1gXuZlzQpRkGQWJ_WEGmWjqnXTOI=
> Debian's kernel log file.  Note that this contains functional boots
> with older
> kernels as well earlier in the file.
>
> With both my hand compiled 4.9-rc4 from kernel.org sources and
> Ubuntu's
> 4.9.0-040900rc4-generic the kernel creates hundred of useless
> /dev/sd??
> devices.  This system is fine with various 4.4, and 4.8 kernels.
>
> The logs are spammed with messages like these
> 2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev
> sdjm:
> unable to read RDB block 1
> 2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188]
>  sdjm: unable
> to read partition table
> 2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm:
> partition
> table beyond EOD, enabling native capacity
> 2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd
> 1:3:126:0:

This was reported to the mailing list and should be fixed by this:

https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Fl-3Dlinux-2Dscsi-26m-3D147868920429684=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=KCePcDLsNpEqob1iEoGGCb5Qf-smnMYk4XsK62Sp0h4=

We'll fast track this, but can you verify it fixes your issue.

Thanks,

James

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi devices.

[Samuel Silbory]

Seems sane now.
root@pcsnode:~# uname -a
Linux pcsnode 4.9.0-rc4-1-default #1 SMP Wed Nov 9 13:59:28 PST 2016 x86_64 
GNU/Linux
root@pcsnode:~# ls /dev/sd*
/dev/sda  /dev/sdc  /dev/sde  /dev/sdg  /dev/sdi  /dev/sdk   /dev/sdk2  
/dev/sdk4  /dev/sdk6  /dev/sdl
/dev/sdb  /dev/sdd  /dev/sdf  /dev/sdh  /dev/sdj  /dev/sdk1  /dev/sdk3  
/dev/sdk5  /dev/sdk7  /dev/sdm
root@pcsnode:~# 

The only difference compared to 4.8/4/4 is the boot drive on the SATA 
controller ended up sdk instead of sdm (the last drive).  It's not an issue for 
me as I mount things by UUID


From: Samuel Silbory
Sent: Wednesday, November 09, 2016 1:19 PM
To: James Bottomley; bugzilla-dae...@bugzilla.kernel.org; 
linux-scsi@vger.kernel.org
Subject: RE: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi 
devices.

Certainly I'll give it a try.

From: James Bottomley [james.bottom...@hansenpartnership.com]
Sent: Wednesday, November 09, 2016 12:49 PM
To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Cc: Samuel Silbory
Subject: Re: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi 
devices.

On Wed, 2016-11-09 at 20:20 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D187381=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=67orQXH1IekXCew60eHDOmksAqiZIU69q0eGzoqiWMM=
>
> Bug ID: 187381
>Summary: 4.9.-rc4 produces hundreds of unusable scsi
> devices.
>Product: SCSI Drivers
>Version: 2.5
> Kernel Version: 4.9-rc4
>   Hardware: All
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
>   Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
>   Reporter: samuel.silb...@hds.com
> Regression: No
>
> Created attachment 244091
>   -->
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_attachment.cgi-3Fid-3D244091-26action-3Dedit=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=ypXf8FCNK77zZPf1gXuZlzQpRkGQWJ_WEGmWjqnXTOI=
> Debian's kernel log file.  Note that this contains functional boots
> with older
> kernels as well earlier in the file.
>
> With both my hand compiled 4.9-rc4 from kernel.org sources and
> Ubuntu's
> 4.9.0-040900rc4-generic the kernel creates hundred of useless
> /dev/sd??
> devices.  This system is fine with various 4.4, and 4.8 kernels.
>
> The logs are spammed with messages like these
> 2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev
> sdjm:
> unable to read RDB block 1
> 2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188]
>  sdjm: unable
> to read partition table
> 2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm:
> partition
> table beyond EOD, enabling native capacity
> 2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd
> 1:3:126:0:

This was reported to the mailing list and should be fixed by this:

https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Fl-3Dlinux-2Dscsi-26m-3D147868920429684=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=KCePcDLsNpEqob1iEoGGCb5Qf-smnMYk4XsK62Sp0h4=

We'll fast track this, but can you verify it fixes your issue.

Thanks,

James


--
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

[Bug 187381] 4.9.-rc4 produces hundreds of unusable scsi devices.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=187381

--- Comment #2 from Samuel Flory Silbory  ---
Certainly I'll give it a try.

From: James Bottomley [james.bottom...@hansenpartnership.com]
Sent: Wednesday, November 09, 2016 12:49 PM
To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Cc: Samuel Silbory
Subject: Re: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi
devices.

On Wed, 2016-11-09 at 20:20 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D187381=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=67orQXH1IekXCew60eHDOmksAqiZIU69q0eGzoqiWMM=
>
> Bug ID: 187381
>Summary: 4.9.-rc4 produces hundreds of unusable scsi
> devices.
>Product: SCSI Drivers
>Version: 2.5
> Kernel Version: 4.9-rc4
>   Hardware: All
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
>   Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
>   Reporter: samuel.silb...@hds.com
> Regression: No
>
> Created attachment 244091
>   -->
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_attachment.cgi-3Fid-3D244091-26action-3Dedit=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=ypXf8FCNK77zZPf1gXuZlzQpRkGQWJ_WEGmWjqnXTOI=
> Debian's kernel log file.  Note that this contains functional boots
> with older
> kernels as well earlier in the file.
>
> With both my hand compiled 4.9-rc4 from kernel.org sources and
> Ubuntu's
> 4.9.0-040900rc4-generic the kernel creates hundred of useless
> /dev/sd??
> devices.  This system is fine with various 4.4, and 4.8 kernels.
>
> The logs are spammed with messages like these
> 2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev
> sdjm:
> unable to read RDB block 1
> 2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188]
>  sdjm: unable
> to read partition table
> 2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm:
> partition
> table beyond EOD, enabling native capacity
> 2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd
> 1:3:126:0:

This was reported to the mailing list and should be fixed by this:

https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Fl-3Dlinux-2Dscsi-26m-3D147868920429684=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=KCePcDLsNpEqob1iEoGGCb5Qf-smnMYk4XsK62Sp0h4=

We'll fast track this, but can you verify it fixes your issue.

Thanks,

James

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi devices.

[Samuel Silbory]

Certainly I'll give it a try.

From: James Bottomley [james.bottom...@hansenpartnership.com]
Sent: Wednesday, November 09, 2016 12:49 PM
To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Cc: Samuel Silbory
Subject: Re: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi 
devices.

On Wed, 2016-11-09 at 20:20 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D187381=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=67orQXH1IekXCew60eHDOmksAqiZIU69q0eGzoqiWMM=
>
> Bug ID: 187381
>Summary: 4.9.-rc4 produces hundreds of unusable scsi
> devices.
>Product: SCSI Drivers
>Version: 2.5
> Kernel Version: 4.9-rc4
>   Hardware: All
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
>   Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
>   Reporter: samuel.silb...@hds.com
> Regression: No
>
> Created attachment 244091
>   -->
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_attachment.cgi-3Fid-3D244091-26action-3Dedit=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=ypXf8FCNK77zZPf1gXuZlzQpRkGQWJ_WEGmWjqnXTOI=
> Debian's kernel log file.  Note that this contains functional boots
> with older
> kernels as well earlier in the file.
>
> With both my hand compiled 4.9-rc4 from kernel.org sources and
> Ubuntu's
> 4.9.0-040900rc4-generic the kernel creates hundred of useless
> /dev/sd??
> devices.  This system is fine with various 4.4, and 4.8 kernels.
>
> The logs are spammed with messages like these
> 2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev
> sdjm:
> unable to read RDB block 1
> 2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188]
>  sdjm: unable
> to read partition table
> 2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm:
> partition
> table beyond EOD, enabling native capacity
> 2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd
> 1:3:126:0:

This was reported to the mailing list and should be fixed by this:

https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Fl-3Dlinux-2Dscsi-26m-3D147868920429684=CwICaQ=DZ-EF4pZfxGSU6MfABwx0g=4FOU_7YnNtQNKWSdicj67DITRyD0V0NPxX2P7qBxsr8=qqYheGXoM4mBPxyZZ7HM1rugSFukVAVfEjl1ifhaoqU=KCePcDLsNpEqob1iEoGGCb5Qf-smnMYk4XsK62Sp0h4=

We'll fast track this, but can you verify it fixes your issue.

Thanks,

James


--
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] hpsa: switch to pci_alloc_irq_vectors

[Christoph Hellwig]

On Tue, Nov 08, 2016 at 04:02:54PM +0100, Hannes Reinecke wrote:
>> I've looked at the them but haven't started work, so feel free to go
>> ahead.  The MSI-X handling in mpt3sas is pretty nasty, so be careful.
>>
>> I've also started playing with lpfc, something I'll need to send to
>> you and James for testing and feedback soon.
>>
> Bah. Another duplicate then.
> Let's see who is faster :-)

Here are the lpfc patches - note that it's in a branch that merges
the recent irq affinity changes from the tip tree into the scsi tree
first, as we need updates from both of them:

http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/lpfc-msix
--
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] hpsa: use pci_alloc_irq_vectors and automatic irq affinity

[Don Brace]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Wednesday, November 09, 2016 12:42 PM
> To: Don Brace
> Cc: h...@suse.de; linux-scsi@vger.kernel.org
> Subject: [PATCH] hpsa: use pci_alloc_irq_vectors and automatic irq affinity
> 
> EXTERNAL EMAIL
> 
> 
> This patch converts over hpsa to use the pci_alloc_irq_vectors including
> the PCI_IRQ_AFFINITY flag that automatically assigns spread out
> irq affinity to the I/O queues.
> 
> It also cleans up the per-ctrl interrupt state due to the use of the
> pci_irq_vector and pci_free_irq_vectors helpers that don't need to know
> the exact irq type.  Additionally it changes a little oddity in the
> existing code that was using different array indixes into the per-vector
> arrays depending on wether a controller is using a single INTx or single
> MSI irq.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: Don Brace 
Tested-by: Don Brace 

> ---
>  drivers/scsi/hpsa.c | 143 
> ++--
>  drivers/scsi/hpsa.h |   6 +--
>  2 files changed, 52 insertions(+), 97 deletions(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index d007ec1..dce8f80 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -1001,7 +1001,7 @@ static void set_performant_mode(struct ctlr_info
> *h, struct CommandList *c,
>  {
> if (likely(h->transMethod & CFGTBL_Trans_Performant)) {
> c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
> -   if (unlikely(!h->msix_vector))
> +   if (unlikely(!h->msix_vectors))
> return;
> if (likely(reply_queue == DEFAULT_REPLY_QUEUE))
> c->Header.ReplyQueue =
> @@ -5618,7 +5618,7 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h)
> sh->sg_tablesize = h->maxsgentries;
> sh->transportt = hpsa_sas_transport_template;
> sh->hostdata[0] = (unsigned long) h;
> -   sh->irq = h->intr[h->intr_mode];
> +   sh->irq = pci_irq_vector(h->pdev, 0);
> sh->unique_id = sh->irq;
> 
> h->scsi_host = sh;
> @@ -7652,67 +7652,41 @@ static int find_PCI_BAR_index(struct pci_dev
> *pdev, unsigned long pci_bar_addr)
> 
>  static void hpsa_disable_interrupt_mode(struct ctlr_info *h)
>  {
> -   if (h->msix_vector) {
> -   if (h->pdev->msix_enabled)
> -   pci_disable_msix(h->pdev);
> -   h->msix_vector = 0;
> -   } else if (h->msi_vector) {
> -   if (h->pdev->msi_enabled)
> -   pci_disable_msi(h->pdev);
> -   h->msi_vector = 0;
> -   }
> +   pci_free_irq_vectors(h->pdev);
> +   h->msix_vectors = 0;
>  }
> 
>  /* If MSI/MSI-X is supported by the kernel we will try to enable it on
>   * controllers that are capable. If not, we use legacy INTx mode.
>   */
> -static void hpsa_interrupt_mode(struct ctlr_info *h)
> +static int hpsa_interrupt_mode(struct ctlr_info *h)
>  {
> -#ifdef CONFIG_PCI_MSI
> -   int err, i;
> -   struct msix_entry hpsa_msix_entries[MAX_REPLY_QUEUES];
> -
> -   for (i = 0; i < MAX_REPLY_QUEUES; i++) {
> -   hpsa_msix_entries[i].vector = 0;
> -   hpsa_msix_entries[i].entry = i;
> -   }
> +   unsigned int flags = PCI_IRQ_LEGACY;
> +   int ret;
> 
> /* Some boards advertise MSI but don't really support it */
> -   if ((h->board_id == 0x40700E11) || (h->board_id == 0x40800E11) ||
> -   (h->board_id == 0x40820E11) || (h->board_id == 0x40830E11))
> -   goto default_int_mode;
> -   if (pci_find_capability(h->pdev, PCI_CAP_ID_MSIX)) {
> -   dev_info(>pdev->dev, "MSI-X capable controller\n");
> -   h->msix_vector = MAX_REPLY_QUEUES;
> -   if (h->msix_vector > num_online_cpus())
> -   h->msix_vector = num_online_cpus();
> -   err = pci_enable_msix_range(h->pdev, hpsa_msix_entries,
> -   1, h->msix_vector);
> -   if (err < 0) {
> -   dev_warn(>pdev->dev, "MSI-X init failed %d\n", 
> err);
> -   h->msix_vector = 0;
> -   goto single_msi_mode;
> -   } else if (err < h->msix_vector) {
> -   dev_warn(>pdev->dev, "only %d MSI-X vectors "
> -  "available\n", err);
> +   switch (h->board_id) {
> +   case 0x40700E11:
> +   case 0x40800E11:
> +   case 0x40820E11:
> +   case 0x40830E11:
> +   break;
> +   default:
> +   ret = pci_alloc_irq_vectors(h->pdev, 1, MAX_REPLY_QUEUES,
> +   PCI_IRQ_MSIX | PCI_IRQ_AFFINITY);
> +   if (ret > 0) {
> +   h->msix_vectors = ret;
> +   return 0;
> }
> - 

RE: [PATCH] hpsa: switch to pci_alloc_irq_vectors

[Don Brace]

> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Wednesday, November 09, 2016 9:45 AM
> To: Christoph Hellwig; Don Brace
> Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; Hannes
> Reinecke
> Subject: Re: [PATCH] hpsa: switch to pci_alloc_irq_vectors
> 
> EXTERNAL EMAIL
> 
> 
> On 11/09/2016 04:36 PM, Christoph Hellwig wrote:
> > On Wed, Nov 09, 2016 at 03:32:48PM +, Don Brace wrote:
> >> Do we need to add an entry for map_queues?
> >
> > The existing driver only supports a single submission queue.
> > If some of the devices support more than one submission queue
> > we could enhance the driver to support it, but we'd need docs
> > and hardware.
> >
> Hardware is not an issue :-)
> 
> However, I'm still curious about the layout of the queues.
> Are all queues (in performant mode) identical and can we use them for
> parallel submission? Or do we have to treat them differently?\

All of the submission queues are identical.

> (There were some rumours that it actually uses the queues for different
> I/O sizes ...)

This is an untrue rumor. :)

Thanks,
Don Brace

ESC - Smart Storage
Microsemi Corporation



> 
> Once that is cleared up it shouldn't be too hard moving to full
> multiqueue support.
> (If we have identical queues, that is :-)
> 
> Cheers,
> 
> Hannes
> --
> Dr. Hannes ReineckeTeamlead Storage & Networking
> h...@suse.de   +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)
--
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: [Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi devices.

[James Bottomley]

On Wed, 2016-11-09 at 20:20 +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=187381
> 
> Bug ID: 187381
>Summary: 4.9.-rc4 produces hundreds of unusable scsi
> devices.
>Product: SCSI Drivers
>Version: 2.5
> Kernel Version: 4.9-rc4
>   Hardware: All
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: normal
>   Priority: P1
>  Component: Other
>   Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
>   Reporter: samuel.silb...@hds.com
> Regression: No
> 
> Created attachment 244091
>   --> 
> https://bugzilla.kernel.org/attachment.cgi?id=244091=edit
> Debian's kernel log file.  Note that this contains functional boots
> with older
> kernels as well earlier in the file.
> 
> With both my hand compiled 4.9-rc4 from kernel.org sources and
> Ubuntu's
> 4.9.0-040900rc4-generic the kernel creates hundred of useless
> /dev/sd??
> devices.  This system is fine with various 4.4, and 4.8 kernels.
> 
> The logs are spammed with messages like these
> 2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev
> sdjm:
> unable to read RDB block 1
> 2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188] 
>  sdjm: unable
> to read partition table
> 2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm:
> partition
> table beyond EOD, enabling native capacity
> 2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd 
> 1:3:126:0:

This was reported to the mailing list and should be fixed by this:

http://marc.info/?l=linux-scsi=147868920429684

We'll fast track this, but can you verify it fixes your issue.

Thanks,

James


--
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: [RFC PATCH] scsi: libsas: fix WARN on device removal

[Dan Williams]

On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams  wrote:
> On Wed, Nov 9, 2016 at 9:36 AM, John Garry  wrote:
>> On 09/11/2016 12:28, John Garry wrote:
>>>
>>> On 03/11/2016 14:58, John Garry wrote:

 The following patch introduces an annoying WARN
 when a device is removed from the SAS topology:
 [SCSI] libsas: prevent domain rediscovery competing with ata error
 handling

>>>
>>> Are there any views on this patch? I would have thought that the parties
>>> who use the drivers based on libsas would be interested in fixing this
>>> bug.
>>>
>>
>> I should have added the before and after logs earlier, so the issue is
>> illustrated. Now attached. When a 24-port expander is unplugged we get >6k
>> lines of WARN on the console, lasting >30 seconds. Not nice.
>>
>
> I might be mistaken, but this patch seems functionally identical to
> this attempt:
>
> http://marc.info/?l=linux-scsi=143459794823595=2
>
> i.e. it moves the port destruction to the workqueue and still suffers
> from the flutter problem:
>
> http://marc.info/?l=linux-scsi=143801026028006=2
> http://marc.info/?l=linux-scsi=143801971131073=2
>
> Perhaps we instead need to quiet this warning?
>
> http://marc.info/?l=linux-scsi=143802229932175=2

Alternatively we need a mechanism to cancel in-flight port shutdown
requests when we start re-attaching devices before queued port
destruction events have run.
--
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

[Bug 187381] 4.9.-rc4 produces hundreds of unusable scsi devices.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=187381

--- Comment #1 from Samuel Flory Silbory  ---
Created attachment 244101
  --> https://bugzilla.kernel.org/attachment.cgi?id=244101=edit
Storcli output from system.

Note that this occurs with really old firmware and the current megaraid
firmware.  The megaraid configuration is 12 one drive RAID zero arrays.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

[Bug 187381] New: 4.9.-rc4 produces hundreds of unusable scsi devices.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=187381

Bug ID: 187381
   Summary: 4.9.-rc4 produces hundreds of unusable scsi devices.
   Product: SCSI Drivers
   Version: 2.5
Kernel Version: 4.9-rc4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Other
  Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
  Reporter: samuel.silb...@hds.com
Regression: No

Created attachment 244091
  --> https://bugzilla.kernel.org/attachment.cgi?id=244091=edit
Debian's kernel log file.  Note that this contains functional boots with older
kernels as well earlier in the file.

With both my hand compiled 4.9-rc4 from kernel.org sources and Ubuntu's
4.9.0-040900rc4-generic the kernel creates hundred of useless /dev/sd??
devices.  This system is fine with various 4.4, and 4.8 kernels.

The logs are spammed with messages like these
2016-11-09T12:17:00.021765-08:00 Node001 kernel: [75590.503155] Dev sdjm:
unable to read RDB block 1
2016-11-09T12:17:00.021767-08:00 Node001 kernel: [75590.503188]  sdjm: unable
to read partition table
2016-11-09T12:17:00.021769-08:00 Node001 kernel: [75590.503191] sdjm: partition
table beyond EOD, enabling native capacity
2016-11-09T12:17:00.021776-08:00 Node001 kernel: [75590.504463] sd 1:3:126:0:
[sdjl] Sector size 0 reported, assuming 512.
2016-11-09T12:17:00.021778-08:00 Node001 kernel: [75590.504486] sd 1:3:127:0:
[sdjm] Sector size 0 reported, assuming 512.
2016-11-09T12:17:00.025711-08:00 Node001 kernel: [75590.504624] Dev sdjl:
unable to read RDB block 1
2016-11-09T12:17:00.025720-08:00 Node001 kernel: [75590.504625] Dev sdjm:
unable to read RDB block 1
2016-11-09T12:17:00.025722-08:00 Node001 kernel: [75590.504635]  sdjm: unable
to read partition table
2016-11-09T12:17:00.025724-08:00 Node001 kernel: [75590.504687] sdjm: partition
table beyond EOD, truncated
2016-11-09T12:17:00.025725-08:00 Node001 kernel: [75590.504697]  sdjl: unable
to read partition table
2016-11-09T12:17:00.025727-08:00 Node001 kernel: [75590.504701] sdjl: partition
table beyond EOD, truncated
2016-11-09T12:17:00.025728-08:00 Node001 kernel: [75590.505084] sd 1:3:127:0:
[sdjm] Sector size 0 reported, assuming 512.
2016-11-09T12:17:00.025730-08:00 Node001 kernel: [75590.505088] sd 1:3:126:0:
[sdjl] Sector size 0 reported, assuming 512.
2016-11-09T12:17:00.025732-08:00 Node001 kernel: [75590.505115] sd 1:3:126:0:
[sdjl] Attached SCSI disk
2016-11-09T12:17:00.025733-08:00 Node001 kernel: [75590.505151] sd 1:3:127:0:
[sdjm] Attached SCSI disk

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

[Bug 66611] Very Slow I/O performance on SAS1064

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=66611

Szőgyényi Gábor  changed:

   What|Removed |Added

 CC||szg0...@freemail.hu

--- Comment #3 from Szőgyényi Gábor  ---
Please try this bug with latest kernel image.

-- 
You are receiving this mail because:
You are the assignee for the bug.--
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: [RFC PATCH] scsi: libsas: fix WARN on device removal

[Dan Williams]

On Wed, Nov 9, 2016 at 9:36 AM, John Garry  wrote:
> On 09/11/2016 12:28, John Garry wrote:
>>
>> On 03/11/2016 14:58, John Garry wrote:
>>>
>>> The following patch introduces an annoying WARN
>>> when a device is removed from the SAS topology:
>>> [SCSI] libsas: prevent domain rediscovery competing with ata error
>>> handling
>>>
>>
>> Are there any views on this patch? I would have thought that the parties
>> who use the drivers based on libsas would be interested in fixing this
>> bug.
>>
>
> I should have added the before and after logs earlier, so the issue is
> illustrated. Now attached. When a 24-port expander is unplugged we get >6k
> lines of WARN on the console, lasting >30 seconds. Not nice.
>

I might be mistaken, but this patch seems functionally identical to
this attempt:

http://marc.info/?l=linux-scsi=143459794823595=2

i.e. it moves the port destruction to the workqueue and still suffers
from the flutter problem:

http://marc.info/?l=linux-scsi=143801026028006=2
http://marc.info/?l=linux-scsi=143801971131073=2

Perhaps we instead need to quiet this warning?

http://marc.info/?l=linux-scsi=143802229932175=2
--
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 v1] ufs: introcude UFSHCD_QUIRK_GET_VS_RESULT quirk

[Subhash Jadavani]

On 2016-11-08 22:46, Kiwoong Kim wrote:

> Some UFS host controllers may not report a result of UIC command
> completion properly.
> In such cases, they should get the result from UIC directly if their
> architectures support that.
>
> Signed-off-by: Kiwoong Kim 
> ---
>  drivers/scsi/ufs/ufshcd.c | 27 +++
> drivers/scsi/ufs/ufshcd.h | 20 
>  2 files changed, 43 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index d4a5a9c..8e19631 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1011,7 +1011,10 @@ static inline bool
> ufshcd_ready_for_uic_cmd(struct ufs_hba *hba)
>   */
>  static inline u8 ufshcd_get_upmcrs(struct ufs_hba *hba)  {
> -  return (ufshcd_readl(hba, REG_CONTROLLER_STATUS) >> 8) & 0x7;
> +  if (hba->quirks & UFSHCD_QUIRK_GET_VS_RESULT)
> +  return (u8)ufshcd_vops_get_vs_info(hba, VS_OP_03);
> +  else
> +  return (ufshcd_readl(hba, REG_CONTROLLER_STATUS) >> 8) &

0x7;

>  }
>
>  /**
> @@ -1038,6 +1041,17 @@ ufshcd_dispatch_uic_cmd(struct ufs_hba *hba,
> struct uic_command *uic_cmd)
>  REG_UIC_COMMAND);
>  }
>
> +static inline enum vs_opcode ufshcd_get_vs_opcode(struct uic_command
> *uic_cmd)
> +{
> +  if (uic_cmd->command == UIC_CMD_DME_LINK_STARTUP)
> +  return VS_OP_00;
> +  else if ((uic_cmd->command == UIC_CMD_DME_HIBER_ENTER))
> +  return VS_OP_01;
> +  else if ((uic_cmd->command == UIC_CMD_DME_HIBER_EXIT))
> +  return VS_OP_02;
> +  else
> +  return VS_OP_INVALID;
> +}
>  /**
>   * ufshcd_wait_for_uic_cmd - Wait complectioin of UIC command
>   * @hba: per adapter instance
> @@ -1051,11 +1065,16 @@ ufshcd_wait_for_uic_cmd(struct ufs_hba *hba,
> struct uic_command *uic_cmd)  {
>int ret;
>unsigned long flags;
> +  enum vs_opcode vs_op = ufshcd_get_vs_opcode(uic_cmd);

Please move this after we check the quirk below.


Okay, I'll apply what you said.



>
>if (wait_for_completion_timeout(_cmd->done,
> -  msecs_to_jiffies(UIC_CMD_TIMEOUT)))
> -  ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> -  else
> +  msecs_to_jiffies(UIC_CMD_TIMEOUT)))

{

> +  if (hba->quirks & UFSHCD_QUIRK_GET_VS_RESULT &&
> +  vs_op != VS_OP_INVALID)
> +  ret = ufshcd_vops_get_vs_info(hba, vs_op);
> +  else
> +  ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> +  } else
>ret = -ETIMEDOUT;
>
>spin_lock_irqsave(hba->host->host_lock, flags);
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 13504b4..8cf3991 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -245,6 +245,14 @@ struct ufs_pwr_mode_info {
>struct ufs_pa_layer_attr info;
>  };
>
> +enum vs_opcode {
> +  VS_OP_00 = 0x00,
> +  VS_OP_01,
> +  VS_OP_02,
> +  VS_OP_03,
> +  VS_OP_INVALID = 0xFF,
> +};
> +

How do we interpret these codes? and how is this useful for non-exynos
UFS host controller? Please make it generic which can be used by other
controllers in future (if required).


As you guessed, this patch is to get some information
by using vendor specific ways directly, which was got from standard
UFSHCI SFRs for some hardware problems.

If other controllers have similar problems, but the problems are 
acutally
another cases, you should add the function call - 
ufshcd_vops_get_vs_info

- wherever you want to use this interface.

This patch is intended to cover all results of link startup, hibern8 
and

power mode change. Because I don't want to add an additional interface
whenever a new controller has a new problem similar with what I 
mentioned

above.

Anyway, could you give me your opinion about it?
Or, if you don't agree applying something just to fix some simple 
problems,

such as reading SFRs, I won't update this patch any more.



VS_OP_XY is not at all readable and not generic enough. If you can 
define some generic names for it, we should be ok with this change.




Thank you.



>  /**
>   * struct ufs_hba_variant_ops - variant specific callbacks
>   * @name: variant name
> @@ -297,6 +305,7 @@ struct ufs_hba_variant_ops {
>int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>void(*dbg_register_dump)(struct ufs_hba *hba);
>int (*phy_initialization)(struct ufs_hba *);
> +  int (*get_vs_info)(struct ufs_hba *hba, enum vs_opcode);
>  };
>
>  /* clock gating state  */
> @@ -484,6 +493,8 @@ struct ufs_hba {
> */
>#define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
>
> +  #define UFSHCD_QUIRK_GET_VS_RESULT  UFS_BIT(6)

Name is weird, can we name it to reflect the actual purpose of this
quirk? something like UFSHCD_QUIRK_BROKEN_UIC_COMPL ?


Okay, I'll change the name with proper one.



> +
>unsigned int quirks;/* 

Re: [PATCH v1] ufs: introduce UFSHCI_QUIRK_SKIP_INTR_AGGR quirk

[Subhash Jadavani]

On 2016-11-08 21:43, Kiwoong Kim wrote:

> If UFS driver resets interrupt aggregation timer and counter
> when there is a pending doorbell, an interrupt of IO completion
> of a corresponding task may be missed.
> That would cause a command timeout.
>
> If UFS driver resets interrupt aggregation timer and counter
> when there is a pending doorbell, a competion interrupt
> of a corresponing task may be issued.
> That would casue a command timeout.


Please add how are you fixing the issue in commit text.


>
> Signed-off-by: Kiwoong Kim 
> ---
>  drivers/scsi/ufs/ufshcd.c | 4 +++-
>  drivers/scsi/ufs/ufshcd.h | 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index c904854..65bbf59 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3730,7 +3730,9 @@ static void ufshcd_transfer_req_compl(struct
> ufs_hba *hba)
> * false interrupt if device completes another request after
> resetting
> * aggregation and before reading the DB.
> */
> -  if (ufshcd_is_intr_aggr_allowed(hba))
> +  if ((ufshcd_is_intr_aggr_allowed(hba))
> +  && !(hba->quirks & UFSHCI_QUIRK_SKIP_INTR_AGGR))

Why do we need this new quirk? If controller has the issue with
interrupt aggregation, you can remove this UFSHCD_CAP_INTR_AGGR to
disable the aggregation altogether.


This fragment doesn't mean disabling interrupt aggregation.
It just means that interrupt aggregation logic would not be reset in 
ISR.


ok.



But I think that the name of the quirk doesn't represent the function 
of it

expectedly.
I'll change the name with another one, such as
UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR.


May be UFSHCD_QUIRK_BROKEN_INTR_AGGR_RESET ?






> +  ufshcd_reset_intr_aggr(hba);
>ufshcd_reset_intr_aggr(hba);
>
>tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 6a96f24..6a9c6e9 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -497,6 +497,7 @@ struct ufs_hba {
>#define UFSHCD_QUIRK_BROKEN_DWORD_UTRD  UFS_BIT(7)
>#define UFSHCD_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(8)
>#define UFSHCD_QUIRK_USE_OF_HCE UFS_BIT(9)
> +  #define UFSHCI_QUIRK_SKIP_INTR_AGGR UFS_BIT(10)


Please also add code comments explaining what this quirk means and when 
should we use it? Please add same for other quirks you introduced in 
different patches.



>
>
>unsigned int quirks;/* Deviations from standard UFSHCI spec.
*/

--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v1] ufs: add a variety of definitions decribed in UFS spec

[Subhash Jadavani]

On 2016-11-08 21:40, Kiwoong Kim wrote:

> These things are defined to be used by some UFS Host controllers.
>
> Signed-off-by: Kiwoong Kim 
> ---
>  drivers/scsi/ufs/mphy.h   | 38 ++
>  drivers/scsi/ufs/ufshci.h | 14 +++---
> drivers/scsi/ufs/unipro.h | 24 
>  3 files changed, 73 insertions(+), 3 deletions(-)  create mode 100644
> drivers/scsi/ufs/mphy.h
>
> diff --git a/drivers/scsi/ufs/mphy.h b/drivers/scsi/ufs/mphy.h new
> file mode 100644 index 000..c431f49
> --- /dev/null
> +++ b/drivers/scsi/ufs/mphy.h
> @@ -0,0 +1,38 @@
> +/*
> + * drivers/scsi/ufs/mphy.h
> + *
> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as published
> by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef _MPHY_H_
> +#define _MPHY_H_

Do we really need separate file for MPHY? May be we can have these
accomodated in unipro.h itself?


I think it's needed. MPHY spec isn't related with Unipro spec directly.


Yes but for UFS host controller, Unipro is the communication channel 
between host and device, includes M-PHY as well.



Is there any reason why we say that this file is deprecated?
Please let me know if you have.


These are only few declarations and i guess it would be appopriate to 
put them under UniPro header file. Anyways it is your choice.






> +
> +#define TX_HIBERN8TIME_CAP0x0f
> +#define TX_MIN_ACTIVATE_TIME  0x33
> +
> +#define RX_HS_G1_SYNC_LEN_CAP 0x8b
> +#define RX_HS_G1_PREP_LEN_CAP 0x8c
> +#define RX_HS_G2_SYNC_LEN_CAP 0x94
> +#define RX_HS_G3_SYNC_LEN_CAP 0x95
> +#define RX_HS_G2_PREP_LEN_CAP 0x96
> +#define RX_HS_G3_PREP_LEN_CAP 0x97
> + #define SYNC_RANGE_FINE  (0 << 6)
> + #define SYNC_RANGE_COARSE(1 << 6)
> + #define SYNC_LEN(x)  ((x) & 0x3f)
> + #define PREP_LEN(x)  ((x) & 0xf)
> +#define RX_ADV_GRANULARITY_CAP0x98
> + #define RX_ADV_GRAN_STEP(x)  x) & 0x3) << 1) | 0x1)
> +#define TX_ADV_GRANULARITY_CAP0x10
> + #define TX_ADV_GRAN_STEP(x)  x) & 0x3) << 1) | 0x1)
> +#define RX_MIN_ACTIVATETIME_CAP   0x8f
> +#define RX_HIBERN8TIME_CAP0x92
> +#define RX_ADV_HIBERN8TIME_CAP0x99
> +#define RX_ADV_MIN_ACTIVATETIME_CAP   0x9a
> +
> +#endif /* _MPHY_H_ */
> +
> diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h
> index 9599741..26dc340 100644
> --- a/drivers/scsi/ufs/ufshci.h
> +++ b/drivers/scsi/ufs/ufshci.h
> @@ -170,17 +170,25 @@ enum {
>  /* UECDL - Host UIC Error Code Data Link Layer 3Ch */
>  #define UIC_DATA_LINK_LAYER_ERROR UFS_BIT(31)
>  #define UIC_DATA_LINK_LAYER_ERROR_CODE_MASK   0x7FFF
> -#define UIC_DATA_LINK_LAYER_ERROR_PA_INIT 0x2000
> -#define UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVED0x0001
> -#define UIC_DATA_LINK_LAYER_ERROR_TCx_REPLAY_TIMEOUT 0x0002
> +#define UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVEDUFS_BIT(0)
> +#define UIC_DATA_LINK_LAYER_ERROR_TCx_REPLAY_TIMEOUT  UFS_BIT(1)
> +#define UIC_DATA_LINK_LAYER_ERROR_RX_BUF_OF   UFS_BIT(5)

why don't we just add macros for all the bits in UECDL ? This makes it
easy in future.


Okay. I'll think about it and apply new macros on new version of this 
patch.




> +#define UIC_DATA_LINK_LAYER_ERROR_PA_INIT UFS_BIT(13)
>
>  /* UECN - Host UIC Error Code Network Layer 40h */
>  #define UIC_NETWORK_LAYER_ERROR   UFS_BIT(31)
>  #define UIC_NETWORK_LAYER_ERROR_CODE_MASK 0x7
> +#define UIC_NETWORK_UNSUPPORTED_HEADER_TYPE   BIT(0)
> +#define UIC_NETWORK_BAD_DEVICEID_ENC  BIT(1)
> +#define UIC_NETWORK_LHDR_TRAP_PACKET_DROPPING BIT(2)
>
>  /* UECT - Host UIC Error Code Transport Layer 44h */
>  #define UIC_TRANSPORT_LAYER_ERROR UFS_BIT(31)
>  #define UIC_TRANSPORT_LAYER_ERROR_CODE_MASK   0x7F
> +#define UIC_TRANSPORT_UNSUPPORTED_HEADER_TYPE BIT(0)
> +#define UIC_TRANSPORT_UNKNOWN_CPORTID BIT(1)
> +#define UIC_TRANSPORT_NO_CONNECTION_RXBIT(2)
> +#define UIC_TRANSPORT_BAD_TC  BIT(4)

May be add definition for bit-5 and 6 as well.


Okay. I'll add those things on new version of this patch.



>
>  /* UECDME - Host UIC Error Code DME 48h */
>  #define UIC_DME_ERROR UFS_BIT(31)
> diff --git a/drivers/scsi/ufs/unipro.h b/drivers/scsi/ufs/unipro.h
> index eff8b56..e47e2c2 100644
> --- a/drivers/scsi/ufs/unipro.h
> +++ b/drivers/scsi/ufs/unipro.h
> @@ -127,6 +127,7 @@
>  #define PA_PACPREQEOBTIMEOUT  0x1591
>  #define PA_HIBERN8TIME0x15A7
>  #define PA_LOCALVERINFO   0x15A9
> +#define PA_GRANULARITY0x15AA
>  #define PA_TACTIVATE  0x15A8
>  #define 

[PATCH] hpsa: use pci_alloc_irq_vectors and automatic irq affinity

[Christoph Hellwig]

This patch converts over hpsa to use the pci_alloc_irq_vectors including
the PCI_IRQ_AFFINITY flag that automatically assigns spread out
irq affinity to the I/O queues.

It also cleans up the per-ctrl interrupt state due to the use of the
pci_irq_vector and pci_free_irq_vectors helpers that don't need to know
the exact irq type.  Additionally it changes a little oddity in the
existing code that was using different array indixes into the per-vector
arrays depending on wether a controller is using a single INTx or single
MSI irq.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/hpsa.c | 143 ++--
 drivers/scsi/hpsa.h |   6 +--
 2 files changed, 52 insertions(+), 97 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index d007ec1..dce8f80 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -1001,7 +1001,7 @@ static void set_performant_mode(struct ctlr_info *h, 
struct CommandList *c,
 {
if (likely(h->transMethod & CFGTBL_Trans_Performant)) {
c->busaddr |= 1 | (h->blockFetchTable[c->Header.SGList] << 1);
-   if (unlikely(!h->msix_vector))
+   if (unlikely(!h->msix_vectors))
return;
if (likely(reply_queue == DEFAULT_REPLY_QUEUE))
c->Header.ReplyQueue =
@@ -5618,7 +5618,7 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h)
sh->sg_tablesize = h->maxsgentries;
sh->transportt = hpsa_sas_transport_template;
sh->hostdata[0] = (unsigned long) h;
-   sh->irq = h->intr[h->intr_mode];
+   sh->irq = pci_irq_vector(h->pdev, 0);
sh->unique_id = sh->irq;
 
h->scsi_host = sh;
@@ -7652,67 +7652,41 @@ static int find_PCI_BAR_index(struct pci_dev *pdev, 
unsigned long pci_bar_addr)
 
 static void hpsa_disable_interrupt_mode(struct ctlr_info *h)
 {
-   if (h->msix_vector) {
-   if (h->pdev->msix_enabled)
-   pci_disable_msix(h->pdev);
-   h->msix_vector = 0;
-   } else if (h->msi_vector) {
-   if (h->pdev->msi_enabled)
-   pci_disable_msi(h->pdev);
-   h->msi_vector = 0;
-   }
+   pci_free_irq_vectors(h->pdev);
+   h->msix_vectors = 0;
 }
 
 /* If MSI/MSI-X is supported by the kernel we will try to enable it on
  * controllers that are capable. If not, we use legacy INTx mode.
  */
-static void hpsa_interrupt_mode(struct ctlr_info *h)
+static int hpsa_interrupt_mode(struct ctlr_info *h)
 {
-#ifdef CONFIG_PCI_MSI
-   int err, i;
-   struct msix_entry hpsa_msix_entries[MAX_REPLY_QUEUES];
-
-   for (i = 0; i < MAX_REPLY_QUEUES; i++) {
-   hpsa_msix_entries[i].vector = 0;
-   hpsa_msix_entries[i].entry = i;
-   }
+   unsigned int flags = PCI_IRQ_LEGACY;
+   int ret;
 
/* Some boards advertise MSI but don't really support it */
-   if ((h->board_id == 0x40700E11) || (h->board_id == 0x40800E11) ||
-   (h->board_id == 0x40820E11) || (h->board_id == 0x40830E11))
-   goto default_int_mode;
-   if (pci_find_capability(h->pdev, PCI_CAP_ID_MSIX)) {
-   dev_info(>pdev->dev, "MSI-X capable controller\n");
-   h->msix_vector = MAX_REPLY_QUEUES;
-   if (h->msix_vector > num_online_cpus())
-   h->msix_vector = num_online_cpus();
-   err = pci_enable_msix_range(h->pdev, hpsa_msix_entries,
-   1, h->msix_vector);
-   if (err < 0) {
-   dev_warn(>pdev->dev, "MSI-X init failed %d\n", err);
-   h->msix_vector = 0;
-   goto single_msi_mode;
-   } else if (err < h->msix_vector) {
-   dev_warn(>pdev->dev, "only %d MSI-X vectors "
-  "available\n", err);
+   switch (h->board_id) {
+   case 0x40700E11:
+   case 0x40800E11:
+   case 0x40820E11:
+   case 0x40830E11:
+   break;
+   default:
+   ret = pci_alloc_irq_vectors(h->pdev, 1, MAX_REPLY_QUEUES,
+   PCI_IRQ_MSIX | PCI_IRQ_AFFINITY);
+   if (ret > 0) {
+   h->msix_vectors = ret;
+   return 0;
}
-   h->msix_vector = err;
-   for (i = 0; i < h->msix_vector; i++)
-   h->intr[i] = hpsa_msix_entries[i].vector;
-   return;
-   }
-single_msi_mode:
-   if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
-   dev_info(>pdev->dev, "MSI capable controller\n");
-   if (!pci_enable_msi(h->pdev))
-   h->msi_vector = 1;
-   else
-   dev_warn(>pdev->dev, "MSI init failed\n");
+
+   flags |= PCI_IRQ_MSI;
+   break;
}
-default_int_mode:

Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1

[Tejun Heo]

Hello,

On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
> > *pdev)
> > dev_warn(>dev, "%s: Error reading
> > device info. Assume version1\n",
> > __func__);
> > version = XGENE_AHCI_V1;
> > -   } else if (info->valid & ACPI_VALID_CID) {
> > -   version = XGENE_AHCI_V2;

Can you please explain this part a bit?  Everything else looks good to
me.

Thanks.

-- 
tejun
--
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] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945

[Martin K. Petersen]

> "Sumit" == Sumit Saxena  writes:

Sumit> This patch will fix regression caused by below commit- 1e793f6
Sumit> scsi: megaraid_sas: Fix data integrity failure for JBOD
Sumit> (passthrough) devices

Sumit> The problem was MEGASAS_IS_LOGICAL macro does not have braces and
Sumit> because of above commit using this macro was exposing lot of
Sumit> non-existing SCSI devices(all SCSI commands to channels-1,2,3 was
Sumit> returned as SUCCESS-DID_OK by driver).

Applied to 4.9/scsi-fixes.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945

[Jens Axboe]

On 11/09/2016 03:59 AM, Sumit Saxena wrote:

This patch will fix regression caused by below commit-
1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices

The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of 
above commit
using this macro was exposing lot of non-existing SCSI devices(all SCSI 
commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).

Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe 
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Tested-by: Sumit Saxena 


Tested-by: Jens Axboe 

--
Jens Axboe

--
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] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945

[Tomas Henzl]

On 9.11.2016 11:59, Sumit Saxena wrote:
> This patch will fix regression caused by below commit-
> 1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
> devices
>
> The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of 
> above commit 
> using this macro was exposing lot of non-existing SCSI devices(all SCSI 
> commands to channels-1,2,3 was
> returned as SUCCESS-DID_OK by driver).
>
> Fixes: 1e793f6fc0db920400574211c48f9157a37e3945 
> Reported-by: Jens Axboe 
> CC: sta...@vger.kernel.org
> Signed-off-by: Kashyap Desai 
> Signed-off-by: Sumit Saxena 
> Tested-by: Sumit Saxena 

Reviewed-by: Tomas Henzl 

Tomas

--
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] hpsa: switch to pci_alloc_irq_vectors

[Hannes Reinecke]

On 11/09/2016 04:36 PM, Christoph Hellwig wrote:

On Wed, Nov 09, 2016 at 03:32:48PM +, Don Brace wrote:

Do we need to add an entry for map_queues?


The existing driver only supports a single submission queue.
If some of the devices support more than one submission queue
we could enhance the driver to support it, but we'd need docs
and hardware.


Hardware is not an issue :-)

However, I'm still curious about the layout of the queues.
Are all queues (in performant mode) identical and can we use them for 
parallel submission? Or do we have to treat them differently?
(There were some rumours that it actually uses the queues for different 
I/O sizes ...)


Once that is cleared up it shouldn't be too hard moving to full 
multiqueue support.

(If we have identical queues, that is :-)

Cheers,

Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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] hpsa: switch to pci_alloc_irq_vectors

[Christoph Hellwig]

On Wed, Nov 09, 2016 at 03:32:48PM +, Don Brace wrote:
> Do we need to add an entry for map_queues?

The existing driver only supports a single submission queue.
If some of the devices support more than one submission queue
we could enhance the driver to support it, but we'd need docs
and hardware.

> Are you and Christoph still working on this patch? :)

I just need to post the version I have here after rebasing it.
Shouldn't take long, but I'm fighting a few fires at the moment,
hopefully later today.
--
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] hpsa: switch to pci_alloc_irq_vectors

[Don Brace]

> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Tuesday, November 08, 2016 1:12 AM
> To: Martin K. Petersen
> Cc: Christoph Hellwig; James Bottomley; linux-scsi@vger.kernel.org; Hannes
> Reinecke; Hannes Reinecke; Don Brace
> Subject: [PATCH] hpsa: switch to pci_alloc_irq_vectors
> 
> EXTERNAL EMAIL
> 
> 
> Use pci_alloc_irq_vectors and drop the hand-crafted
> interrupt affinity routines.
> 
> Signed-off-by: Hannes Reinecke 
> Cc: Don Brace 

Do we need to add an entry for map_queues?

Are you and Christoph still working on this patch? :)

Thanks,
Don Brace

ESC - Smart Storage
Microsemi Corporation




> ---
>  drivers/scsi/hpsa.c | 72 
> +++--
>  drivers/scsi/hpsa.h |  1 -
>  2 files changed, 26 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 4e82b69..104e699 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -5618,7 +5618,7 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h)
> sh->sg_tablesize = h->maxsgentries;
> sh->transportt = hpsa_sas_transport_template;
> sh->hostdata[0] = (unsigned long) h;
> -   sh->irq = h->intr[h->intr_mode];
> +   sh->irq = pci_irq_vector(h->pdev, h->intr_mode);
> sh->unique_id = sh->irq;
> 
> h->scsi_host = sh;
> @@ -7667,14 +7667,9 @@ static void hpsa_disable_interrupt_mode(struct
> ctlr_info *h)
>   */
>  static void hpsa_interrupt_mode(struct ctlr_info *h)
>  {
> +   unsigned int irq_flags = PCI_IRQ_LEGACY;
>  #ifdef CONFIG_PCI_MSI
> -   int err, i;
> -   struct msix_entry hpsa_msix_entries[MAX_REPLY_QUEUES];
> -
> -   for (i = 0; i < MAX_REPLY_QUEUES; i++) {
> -   hpsa_msix_entries[i].vector = 0;
> -   hpsa_msix_entries[i].entry = i;
> -   }
> +   int err;
> 
> /* Some boards advertise MSI but don't really support it */
> if ((h->board_id == 0x40700E11) || (h->board_id == 0x40800E11) ||
> @@ -7685,8 +7680,8 @@ static void hpsa_interrupt_mode(struct ctlr_info
> *h)
> h->msix_vector = MAX_REPLY_QUEUES;
> if (h->msix_vector > num_online_cpus())
> h->msix_vector = num_online_cpus();
> -   err = pci_enable_msix_range(h->pdev, hpsa_msix_entries,
> -   1, h->msix_vector);
> +   err = pci_alloc_irq_vectors(h->pdev, 1, h->msix_vector,
> +   PCI_IRQ_MSIX | PCI_IRQ_AFFINITY);
> if (err < 0) {
> dev_warn(>pdev->dev, "MSI-X init failed %d\n", 
> err);
> h->msix_vector = 0;
> @@ -7696,22 +7691,21 @@ static void hpsa_interrupt_mode(struct ctlr_info
> *h)
>"available\n", err);
> }
> h->msix_vector = err;
> -   for (i = 0; i < h->msix_vector; i++)
> -   h->intr[i] = hpsa_msix_entries[i].vector;
> return;
> }
>  single_msi_mode:
> if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
> dev_info(>pdev->dev, "MSI capable controller\n");
> -   if (!pci_enable_msi(h->pdev))
> +   if (!pci_enable_msi(h->pdev)) {
> h->msi_vector = 1;
> -   else
> +   irq_flags = PCI_IRQ_MSI;
> +   } else
> dev_warn(>pdev->dev, "MSI init failed\n");
> }
>  default_int_mode:
>  #endif /* CONFIG_PCI_MSI */
> /* if we get here we're going to use the default interrupt mode */
> -   h->intr[h->intr_mode] = h->pdev->irq;
> +   pci_alloc_irq_vectors(h->pdev, 1, 1, irq_flags);
>  }
> 
>  static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id)
> @@ -8236,17 +8230,6 @@ static int hpsa_alloc_cmd_pool(struct ctlr_info *h)
> return -ENOMEM;
>  }
> 
> -static void hpsa_irq_affinity_hints(struct ctlr_info *h)
> -{
> -   int i, cpu;
> -
> -   cpu = cpumask_first(cpu_online_mask);
> -   for (i = 0; i < h->msix_vector; i++) {
> -   irq_set_affinity_hint(h->intr[i], get_cpu_mask(cpu));
> -   cpu = cpumask_next(cpu, cpu_online_mask);
> -   }
> -}
> -
>  /* clear affinity hints and free MSI-X, MSI, or legacy INTx vectors */
>  static void hpsa_free_irqs(struct ctlr_info *h)
>  {
> @@ -8255,15 +8238,13 @@ static void hpsa_free_irqs(struct ctlr_info *h)
> if (!h->msix_vector || h->intr_mode != PERF_MODE_INT) {
> /* Single reply queue, only one irq to free */
> i = h->intr_mode;
> -   irq_set_affinity_hint(h->intr[i], NULL);
> -   free_irq(h->intr[i], >q[i]);
> +   free_irq(pci_irq_vector(h->pdev, i), >q[i]);
> h->q[i] = 0;
> return;
> }
> 

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

[John Garry]

On 03/11/2016 14:58, John Garry wrote:

The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling



Are there any views on this patch? I would have thought that the parties 
who use the drivers based on libsas would be interested in fixing this bug.


BTW, We are internally testing, hence the RFC.

Thanks in advance,
John


A sample WARN is as follows:
[  236.842227] WARNING: CPU: 7 PID: 1520 at fs/sysfs/group.c:237 
sysfs_remove_group+0x90/0x98
[  236.850465] Modules linked in:
[  236.853544]
[  236.855045] CPU: 7 PID: 1520 Comm: kworker/u64:4 Tainted: GW   
4.9.0-rc1-15310-g3fbc29e-dirty #676
[  236.865010] Hardware name: Huawei Taishan 2180 /D03, BIOS Estuary v2.3 D03 
UEFI 08/17/2016
[  236.873249] Workqueue: scsi_wq_0 sas_destruct_devices
[  236.878317] task: 8027ba31b200 task.stack: 8027b9d44000
[  236.884225] PC is at sysfs_remove_group+0x90/0x98
[  236.888920] LR is at sysfs_remove_group+0x90/0x98
[  236.893616] pc : [] lr : [] pstate: 
6145
[  236.900989] sp : 8027b9d47bf0

< snip >

[  237.116463] [] sysfs_remove_group+0x90/0x98
[  237.122197] [] dpm_sysfs_remove+0x58/0x68
[  237.127758] [] device_del+0x40/0x218
[  237.132886] [] device_unregister+0x14/0x2c
[  237.138536] [] bsg_unregister_queue+0x5c/0xa0
[  237.12] [] sas_rphy_remove+0x44/0x80
[  237.149915] [] sas_rphy_delete+0x14/0x28
[  237.155388] [] sas_destruct_devices+0x64/0x98
[  237.161293] [] process_one_work+0x128/0x2e4
[  237.167027] [] worker_thread+0x58/0x434
[  237.172415] [] kthread+0xd4/0xe8
[  237.177198] [] ret_from_fork+0x10/0x50
[  237.182557] sysfs group 'power' not found for kobject 'end_device-0:0:5'

(this can be really huge when an expander is unplugged)

The problem is with the process of sas_port and domain_device
destruction in domain revalidation. There is a 2-stage process:
In domain revalidation (which runs in work queue context), if a
domain_device is discovered to be gone, then the following happens:
- the domain_device is queued for destruction in a separate work item
- the associated sas_port is destroyed immediately

This causes a problem in that the sas_port associated with
a domain_device is destroyed prior the domain_device: this causes
the sysfs WARN. Essentially the "rug has been pulled from underneath".

Also, likewise, when a root port is deformed due to loss of signal,
we have the same issue.

To solve, destroy the sas_port in a separate work item to which
we do the domain revalidation with a new discovery event, as follows:
- When a domain_device is detected to be gone, the domain_device is
  queued for destruction in a separate work item. The associated
  sas_port is also queued for destruction in another separate work item
  (needs to be queued 2nd)
- the domain_device is destroyed
- the sas_port is destroyed
[similar is done for loss of signal event, in sas_port_deformed()].

Fixes: 87c8331fcf72e501c3a3c0cdc5c [SCSI] libsas: prevent domain
rediscovery competing with ata error handling

Signed-off-by: John Garry 

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..01d0fe2 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -361,7 +361,7 @@ static void sas_destruct_devices(struct work_struct *work)

clear_bit(DISCE_DESTRUCT, >disc.pending);

-   list_for_each_entry_safe(dev, n, >destroy_list, disco_list_node) {
+   list_for_each_entry_safe(dev, n, >dev_destroy_list, 
disco_list_node) {
list_del_init(>disco_list_node);

sas_remove_children(>rphy->dev);
@@ -383,7 +383,7 @@ void sas_unregister_dev(struct asd_sas_port *port, struct 
domain_device *dev)

if (!test_and_set_bit(SAS_DEV_DESTROY, >state)) {
sas_rphy_unlink(dev->rphy);
-   list_move_tail(>disco_list_node, >destroy_list);
+   list_move_tail(>disco_list_node, >dev_destroy_list);
sas_discover_event(dev->port, DISCE_DESTRUCT);
}
 }
@@ -525,6 +525,28 @@ static void sas_revalidate_domain(struct work_struct *work)
mutex_unlock(>disco_mutex);
 }

+/* -- Async Port destruct -- */
+static void sas_async_port_destruct(struct work_struct *work)
+{
+   struct sas_discovery_event *ev = to_sas_discovery_event(work);
+   struct asd_sas_port *port = ev->port;
+   struct sas_port *sas_port, *n;
+
+   clear_bit(DISCE_PORT_DESTRUCT, >disc.pending);
+
+   list_for_each_entry_safe(sas_port, n, >port_destroy_list, 
destroy_list) {
+   list_del_init(>port_destroy_list);
+
+   sas_port_delete(sas_port);
+   }
+}
+
+void sas_port_destruct(struct asd_sas_port *port, struct sas_port *sas_port)
+{
+   list_move_tail(_port->destroy_list, >port_destroy_list);
+   sas_discover_event(port, DISCE_PORT_DESTRUCT);
+}
+
 /* 

Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1

[Rameshwar Sahu]

Hi Olof/Tejun,

On Thu, Oct 20, 2016 at 4:44 PM, Rameshwar Prasad Sahu  wrote:
>
> This patch enables NCQ support for APM X-Gene SATA controller
> hardware v1.1 that was broken with hardware v1.0.
>
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/ata/ahci_xgene.c |   14 --
>  1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
> index 73b19b2..8b88be9 100644
> --- a/drivers/ata/ahci_xgene.c
> +++ b/drivers/ata/ahci_xgene.c
> @@ -87,6 +87,7 @@
>
>  enum xgene_ahci_version {
> XGENE_AHCI_V1 = 1,
> +   XGENE_AHCI_V1_1,
> XGENE_AHCI_V2,
>  };
>
> @@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
>  #ifdef CONFIG_ACPI
>  static const struct acpi_device_id xgene_ahci_acpi_match[] = {
> { "APMC0D0D", XGENE_AHCI_V1},
> +   { "APMC0D67", XGENE_AHCI_V1_1},
> { "APMC0D32", XGENE_AHCI_V2},
> {},
>  };
> @@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
>
>  static const struct of_device_id xgene_ahci_of_match[] = {
> {.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
> +   {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) 
> XGENE_AHCI_V1_1},
> {.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
> {},
>  };
> @@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> struct resource *res;
> const struct of_device_id *of_devid;
> enum xgene_ahci_version version = XGENE_AHCI_V1;
> -   const struct ata_port_info *ppi[] = { _ahci_v1_port_info,
> - _ahci_v2_port_info };
> +   const struct ata_port_info *ppi;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
> dev_warn(>dev, "%s: Error reading 
> device info. Assume version1\n",
> __func__);
> version = XGENE_AHCI_V1;
> -   } else if (info->valid & ACPI_VALID_CID) {
> -   version = XGENE_AHCI_V2;
> }
> }
> }
> @@ -858,18 +858,20 @@ skip_clk_phy:
>
> switch (version) {
> case XGENE_AHCI_V1:
> +   ppi = _ahci_v1_port_info;
> hpriv->flags = AHCI_HFLAG_NO_NCQ;
> break;
> case XGENE_AHCI_V2:
> +   ppi = _ahci_v2_port_info;
> hpriv->flags |= AHCI_HFLAG_YES_FBS;
> hpriv->irq_handler = xgene_ahci_irq_intr;
> break;
> default:
> +   ppi = _ahci_v1_port_info;
> break;
> }
>
> -   rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
> -_platform_sht);
> +   rc = ahci_platform_init_host(pdev, hpriv, ppi, _platform_sht);
> if (rc)
> goto disable_resources;
>
> --
> 1.7.1


Any comment on above patch ??
--
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

[PATCH] megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression caused by commit 1e793f6fc0db920400574211c48f9157a37e3945

[Sumit Saxena]

This patch will fix regression caused by below commit-
1e793f6 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices

The problem was MEGASAS_IS_LOGICAL macro does not have braces and because of 
above commit 
using this macro was exposing lot of non-existing SCSI devices(all SCSI 
commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).

Fixes: 1e793f6fc0db920400574211c48f9157a37e3945 
Reported-by: Jens Axboe 
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai 
Signed-off-by: Sumit Saxena 
Tested-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_sas.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ca86c88..3aaea71 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2233,7 +2233,7 @@ struct megasas_instance_template {
 };
 
 #define MEGASAS_IS_LOGICAL(scp)
\
-   (scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1
+   ((scp->device->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1)
 
 #define MEGASAS_DEV_INDEX(scp) \
(((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) +   \
-- 
1.8.3.1

--
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: Ordering problems with 3ware controller

[Paul Menzel]

Dear Martin,


On 11/09/16 00:45, Martin K. Petersen wrote:

"Paul" == Paul Menzel  writes:



Paul> Updating from Linux 4.4.X to Linux 4.8.4, we noticed that the
Paul> 3ware devices under `/dev` – `/dev/twa0`, `/dev/twa1`, … – map to
Paul> the controllers differently.

Paul> This unfortunately breaks quite a lot of our scripts, as we depend
Paul> on the fact that the first controller is also in the front.

It's not the 3ware drivers since they have not been updated in a long
time (since way before 4.4).


Yes, that’s what made me wonder too.


Linux does not provide device discovery ordering guarantees. You need to
fix your scripts to use UUIDs, filesystem labels, or DM devices to get
stable naming.


Indeed. But it worked for several years, so that *something* must have 
changed that the ordering of the result of `getdents64` is different now.


Fixing the scripts is unfortunately not that easy, as `tw_cli` is a 
proprietary tool [1], and we do not have the sources. It does a `readdir()`.



open("/proc/scsi/3w-9xxx", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No 
such file or directory)
open("/sys/class/scsi_host", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
getdents64(3, /* 12 entries */, 4096)   = 368
stat("/sys/class/scsi_host/host0/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host9/stats", {st_mode=S_IFREG|0444, st_size=4096, 
...}) = 0
open("/sys/class/scsi_host/host9/stats", O_RDONLY) = 4
read(4, "3w-9xxx Driver v", 16) = 16
close(4)= 0
open("/dev/twa0", O_RDWR)   = 4
close(4)= 0
stat("/sys/class/scsi_host/host7/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host5/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host3/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host1/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host8/stats", {st_mode=S_IFREG|0444, st_size=4096, 
...}) = 0
open("/sys/class/scsi_host/host8/stats", O_RDONLY) = 4
read(4, "3w-9xxx Driver v", 16) = 16
close(4)= 0
open("/dev/twa1", O_RDWR)   = 4
close(4)= 0
stat("/sys/class/scsi_host/host6/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host4/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
stat("/sys/class/scsi_host/host2/stats", 0x7fffafd05290) = -1 ENOENT (No such 
file or directory)
getdents64(3, /* 0 entries */, 4096)= 0
close(3)= 0
open("/proc/devices", O_RDONLY) = 3


Please find attached a wrapper from my colleague, using name spaces to 
ensure the ordering, that `tw_cli` expects.



Kind regards,

Paul


[1] https://wiki.hetzner.de/index.php/3Ware_RAID_Controller/en
#! /usr/bin/perl
use strict;
use warnings;

sub sort_host {
my ($n1,$n2);
($n1)=$a=~/^host(\d+)$/ and ($n2)=$b=~/^host(\d+)$/ and return $n1 <=> 
$n2;
return $a cmp $b;
}


our $SYS_unshare=272;  # /usr/include/asm/unistd_64.h
our $CLONE_NEWNS=0x2;  # /usr/include/linux/sched.h

my $pid=fork;
defined $pid or die "$!\n";
unless ($pid) {
opendir my $d,"/sys/class/scsi_host";
my @names=sort sort_host grep !/^\.\.?$/,readdir $d;

syscall($SYS_unshare,$CLONE_NEWNS) and die "$!\n";
-d '/tmp/sysfs' or mkdir("/tmp/sysfs") or die "/tmp/sysfs: $!\n";
system 'mount','-tsysfs','BLA','/tmp/sysfs' and exit 1;
system 'mount','-ttmpfs','BLA','/sys/class/scsi_host' and exit 1;

for my $name (reverse @names) {

symlink("/tmp/sysfs/class/scsi_host/$name","/sys/class/scsi_host/$name") or die 
"/sys/class/scsi_host/$name: $!\n";
}
exec '/root/bin/tw_cli.exe',@ARGV;
die "$!\n";
}
wait;
$? and exit 1;