Add the UUID field from the NVMe Namespace Identification Descriptor
to the nvmet_ns structure and allow it's population via configfs.
Signed-off-by: Johannes Thumshirn
---
drivers/nvme/target/configfs.c | 48 ++
drivers/nvme/target/nvmet.h| 1 +
2
Now that we can configure a namespace's EUI-64, report it back to the
host in an 'Identify Namespace' command reply.
Signed-off-by: Johannes Thumshirn
---
drivers/nvme/target/admin-cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target
Add the EUI-64 field from the NVMe Namespace Identification Descriptor
to the nvmet_ns structure and allow it's population via configfs.
Signed-off-by: Johannes Thumshirn
---
drivers/nvme/target/configfs.c | 48 ++
drivers/nvme/target/nvmet.h| 1 +
2
.
Johannes Thumshirn (7):
nvme: rename uuid to nguid in nvme_ns
nvmet: add uuid field to nvme_ns and populate via configfs
nvmet: add eui64 field to nvme_ns and populate via configfs
nvme: also report include the EUI-64 in identify NS report
nvmet: implement namespace identify descriptor
.
Johannes Thumshirn (7):
nvme: rename uuid to nguid in nvme_ns
nvmet: add uuid field to nvme_ns and populate via configfs
nvmet: add eui64 field to nvme_ns and populate via configfs
nvme: also report include the EUI-64 in identify NS report
nvmet: implement namespace identify descriptor
directly return
*iff* one of the pci_enable_device() calls fails.
Additionally rename the 'probe_out' goto label's name to the more
descriptive 'disable_device'.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla dat
directly return
*iff* one of the pci_enable_device() calls fails.
Additionally rename the 'probe_out' goto label's name to the more
descriptive 'disable_device'.
Signed-off-by: Johannes Thumshirn
Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure
refactoring")
--
- Adjust identations;
> - Remove title numbering;
> - mark literal blocks;
> - comment its TOC.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
Looks good,
Acked-by: Johannes Thumshirn <jthumsh...@suse.de>
- Adjust identations;
> - Remove title numbering;
> - mark literal blocks;
> - comment its TOC.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
Looks good,
Acked-by: Johannes Thumshirn
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the
list search doesn't find a valid request.
Signed-off-by: Johannes
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the
list search doesn't find a valid request.
Signed-off-by: Johannes
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the
list search doesn't find a valid request.
Signed-off-by: Johannes
If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in sg_remove_scat().
So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the
list search doesn't find a valid request.
Signed-off-by: Johannes
On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an RDMA WRITE pa
On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an RDMA WRITE pa
Looks good,
Acked-by: Johannes Thumshirn <j...@kernel.org>
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB
On Mon, Apr 24, 2017 at 06:04:18PM +0100, Colin King wrote:
> From: Colin Ian King
>
> These module parameter variables don't need global scope, make them static
>
> Signed-off-by: Colin Ian King
> ---
Looks good,
Acked-by: Johannes Thumshirn
--
On Mon, Apr 24, 2017 at 02:38:40PM +0100, John Garry wrote:
> On 24/04/2017 11:09, John Garry wrote:
> >On 21/04/2017 13:11, Johannes Thumshirn wrote:
> >>Move scsi_remove_host call into sas_remove_host and remove it from SAS
> >>HBA
> >>drivers, so we don
On Mon, Apr 24, 2017 at 02:38:40PM +0100, John Garry wrote:
> On 24/04/2017 11:09, John Garry wrote:
> >On 21/04/2017 13:11, Johannes Thumshirn wrote:
> >>Move scsi_remove_host call into sas_remove_host and remove it from SAS
> >>HBA
> >>drivers, so we don
rsive").
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
Suggested-by: Christoph Hellwig <h...@lst.de>
Cc: Hannes Reinecke <h...@suse.de>
Cc: James Bottomley <j...@linux.vnet.ibm.com>
Cc: Jinpu Wang <jinpu.w...@profitbricks.com>
Cc: John Garry <john.
rsive").
Signed-off-by: Johannes Thumshirn
Suggested-by: Christoph Hellwig
Cc: Hannes Reinecke
Cc: James Bottomley
Cc: Jinpu Wang
Cc: John Garry
---
drivers/scsi/aic94xx/aic94xx_init.c | 1 -
drivers/scsi/hisi_sas/hisi_sas_main.c | 1 -
drivers/scsi/isci/init.c | 1 -
drivers/sc
On Fri, Apr 21, 2017 at 01:19:41PM +0200, Christoph Hellwig wrote:
>
> Any reason to not just make sas_remove_host call scsi_remove_host
> to ensure we get the ordering right?
No other than "haven't thought of it". But let me double check the LLDDs fist.
--
On Fri, Apr 21, 2017 at 01:19:41PM +0200, Christoph Hellwig wrote:
>
> Any reason to not just make sas_remove_host call scsi_remove_host
> to ensure we get the ordering right?
No other than "haven't thought of it". But let me double check the LLDDs fist.
--
On Fri, Apr 21, 2017 at 09:34:18AM +0100, John Garry wrote:
> Thanks Johannes.
>
> @wangyijing, can you test this patchset please (specifically 3/5)? I know
> that you have the modified version of libsas which you dabbled with
> upstreaming.
>
> On 21/04/2017 09:04, Joh
On Fri, Apr 21, 2017 at 09:34:18AM +0100, John Garry wrote:
> Thanks Johannes.
>
> @wangyijing, can you test this patchset please (specifically 3/5)? I know
> that you have the modified version of libsas which you dabbled with
> upstreaming.
>
> On 21/04/2017 09:04, Joh
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups
for kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups
for kobjects.
Signed-off-by: Johannes Thumshirn
an idea how to tackle the ordering issues and place it into
sas_unregister_ha() as per James' comment.
Thanks,
Johannes
Johannes Thumshirn (5):
scsi: isci: remove the SAS host after the SCSI host
aic94xx: remove the SAS host after the SCSI host
scsi: hisi_sas: remove the SAS host
an idea how to tackle the ordering issues and place it into
sas_unregister_ha() as per James' comment.
Thanks,
Johannes
Johannes Thumshirn (5):
scsi: isci: remove the SAS host after the SCSI host
aic94xx: remove the SAS host after the SCSI host
scsi: hisi_sas: remove the SAS host
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
;
>
> I'd prefer removing the dynamic allocation and use d on the stack to
> simplify the code.
> Any thoughts ?
Hi Max,
Pasting from above:
> >we can't allocate this memory on the stack as the kbuild test robot
> >reports some frame size overflows on i386.
--
Johannes
d on the stack to
> simplify the code.
> Any thoughts ?
Hi Max,
Pasting from above:
> >we can't allocate this memory on the stack as the kbuild test robot
> >reports some frame size overflows on i386.
--
Johannes Thumshirn Storage
jthumsh...@
eprom(),
b) Linux error codes are negative,
c) ahd_write_seeprom() has 'retval' and 'error' for returning error values
back to the caller (which doesn't care...)
So to sum it up, this change doesn't change anything here. But "fixing" the
list above would make a change.
HTH,
om() has 'retval' and 'error' for returning error values
back to the caller (which doesn't care...)
So to sum it up, this change doesn't change anything here. But "fixing" the
list above would make a change.
HTH,
Johannes
--
Johannes Thumshirn
On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote:
> On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote:
> > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> >
On Thu, Apr 13, 2017 at 10:45:10PM +0800, Ming Lei wrote:
> On Thu, Apr 13, 2017 at 01:53:28PM +0200, Johannes Thumshirn wrote:
> > On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> > > On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> >
On Thu, Apr 13, 2017 at 03:22:00PM +0300, Leon Romanovsky wrote:
> On Thu, Apr 13, 2017 at 02:00:00PM +0200, Johannes Thumshirn wrote:
> > On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> > > When reading a RDMA WRITE FIRST packet we copy the DMA length fr
On Thu, Apr 13, 2017 at 03:22:00PM +0300, Leon Romanovsky wrote:
> On Thu, Apr 13, 2017 at 02:00:00PM +0200, Johannes Thumshirn wrote:
> > On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> > > When reading a RDMA WRITE FIRST packet we copy the DMA length fr
On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an RDMA WRITE pa
On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
> header into the qp->resp.resid variable for later use. Later in check_rkey()
> we clamp it to the MTU if the packet is an RDMA WRITE pa
On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic
> > in nvme_setup_prps() because the dma_len will drop below zero but
On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic
> > in nvme_setup_prps() because the dma_len will drop below zero but
On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> Could you try the following patch to see if it fixes your issue?
Sure, jsut have a short lunch break and then I'll report back.
--
Johannes Thumshirn Storage
jthumsh...@suse
On Thu, Apr 13, 2017 at 06:02:21PM +0800, Ming Lei wrote:
> Could you try the following patch to see if it fixes your issue?
Sure, jsut have a short lunch break and then I'll report back.
--
Johannes Thumshirn Storage
jthumsh...@suse
On Thu, Apr 13, 2017 at 11:48:35AM +0200, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic
> > in nvme_setup_prps() because the dma_len will drop below zero but
On Thu, Apr 13, 2017 at 11:48:35AM +0200, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 10:06:29AM +0200, Johannes Thumshirn wrote:
> > Doing a mkfs.btrfs on a (qemu emulated) PCIe NVMe causes a kernel panic
> > in nvme_setup_prps() because the dma_len will drop below zero but
a regression that came in with -rc1 I'd rather like to have it
fixed or at least have a band aid in place.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr.
a regression that came in with -rc1 I'd rather like to have it
fixed or at least have a band aid in place.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr.
roblem with __deprecated is that
> it causes warnings for existing users, not just new ones.
So a checkpatch rule is the way to go, I guess.
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX
roblem with __deprecated is that
> it causes warnings for existing users, not just new ones.
So a checkpatch rule is the way to go, I guess.
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX
's offsets are not
taken into account in the decision if the bio will gap any more. Restore
the old behavior of checking bio offsets as well for the decision if a
bio will gap.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
Fixes: 729204ef49ec ("block: relax check on sg gap
's offsets are not
taken into account in the decision if the bio will gap any more. Restore
the old behavior of checking bio offsets as well for the decision if a
bio will gap.
Signed-off-by: Johannes Thumshirn
Fixes: 729204ef49ec ("block: relax check on sg gap")
Cc: Ming Lei
---
includ
On Thu, Apr 13, 2017 at 11:59:20AM +0900, Minchan Kim wrote:
> Johannes Thumshirn reported system goes the panic when using NVMe over
> Fabrics loopback target with zram.
>
> The reason is zram expects each bvec in bio contains a single page
> but nvme can attach a huge bulk of
On Thu, Apr 13, 2017 at 11:59:20AM +0900, Minchan Kim wrote:
> Johannes Thumshirn reported system goes the panic when using NVMe over
> Fabrics loopback target with zram.
>
> The reason is zram expects each bvec in bio contains a single page
> but nvme can attach a huge bulk of
from scsi_prep_fn()
back to the block layer.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
Cc: <sta...@vger.kernel.org>
Reviewed-by: Christoph Hellwig <h...@lst.de>
---
Changes to v1:
* s/iscsi_prep_fn()/scsi_
from scsi_prep_fn()
back to the block layer.
Signed-off-by: Johannes Thumshirn
Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
Cc:
Reviewed-by: Christoph Hellwig
---
Changes to v1:
* s/iscsi_prep_fn()/scsi_prep_fn()
* Add Cc stable
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2
On Tue, Apr 11, 2017 at 06:43:22PM +, Bart Van Assche wrote:
> On Tue, 2017-04-11 at 09:46 +0200, Johannes Thumshirn wrote:
> > When instrumenting the SCSI layer to run into the
> > !blk_rq_nr_phys_segments(rq) case the following warning emitted from the
On Tue, Apr 11, 2017 at 06:43:22PM +, Bart Van Assche wrote:
> On Tue, 2017-04-11 at 09:46 +0200, Johannes Thumshirn wrote:
> > When instrumenting the SCSI layer to run into the
> > !blk_rq_nr_phys_segments(rq) case the following warning emitted from the
from iscsi_prep_fn()
back to the block layer.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
Reviewed-by: Christoph Hellwig <h...@lst.de>
---
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
from iscsi_prep_fn()
back to the block layer.
Signed-off-by: Johannes Thumshirn
Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
Reviewed-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Re-send as in the initial send I
>
> Signed-off-by: John Garry <john.ga...@huawei.com>
> ---
Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de>
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfe
h SATA device uses independent and continuous 32 even IPTT from
> 64 to 4094, then v2 hw can only support 63 SATA devices.
> All SAS device(SSP/SMP devices) share odd IPTT value from 1 to
> 4095.
>
> Signed-off-by: Xiaofei Tan
> Signed-off-by: John Garry
IO timeout", that also uses
> the same register to control STP link, is not effective before
> the PHY accepts STP link.
>
> Signed-off-by: Xiaofei Tan <tanxiao...@huawei.com>
> Signed-off-by: John Garry <john.ga...@huawei.com>
> ---
Looks good,
Reviewed-by: Johannes Thumshir
e same register to control STP link, is not effective before
> the PHY accepts STP link.
>
> Signed-off-by: Xiaofei Tan
> Signed-off-by: John Garry
> ---
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@su
Directly call ELS request handler functions in fc_lport_recv_els_req
instead of saving the pointer to the handler's receive function and then
later dereferencing this pointer.
This makes the code a bit more obvious.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
---
drivers/scsi
Directly call ELS request handler functions in fc_lport_recv_els_req
instead of saving the pointer to the handler's receive function and then
later dereferencing this pointer.
This makes the code a bit more obvious.
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/libfc/fc_lport.c | 20
7991 s, 306 MB/s
# sha256sum test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a test.bin
# cp test.bin /tmp/
sha256sum /tmp/test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a /tmp/test.bin
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
7991 s, 306 MB/s
# sha256sum test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a test.bin
# cp test.bin /tmp/
sha256sum /tmp/test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a /tmp/test.bin
Signed-off-by: Johannes Thumshirn
Cc: Hannes Reinecke
Cc
,
> >> +GFP_KERNEL);
> >
> > Are we fine with loosing the zeroing of the entries?
>
> How did you get this concern?
>
> Do you really miss such functionality from the other interface?
Ahm... Don't kzall
,
> >> +GFP_KERNEL);
> >
> > Are we fine with loosing the zeroing of the entries?
>
> How did you get this concern?
>
> Do you really miss such functionality from the other interface?
Ahm... Don't kzall
sas_domain_release_transport is unused since at least v3.13, remove it.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
---
drivers/scsi/libsas/sas_init.c | 7 ---
include/scsi/libsas.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/scsi/libsas/sas_in
sas_domain_release_transport is unused since at least v3.13, remove it.
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/libsas/sas_init.c | 7 ---
include/scsi/libsas.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas
On Wed, Mar 29, 2017 at 02:47:54PM +0200, Johannes Thumshirn wrote:
> > > John, mind giving that one a shot in your test setup as well?
>
> Well, don't mind. It doesn't work in my test setup.
>
> I'm back to the drawing board...
Please ignore my last mail, apparently i
On Wed, Mar 29, 2017 at 02:47:54PM +0200, Johannes Thumshirn wrote:
> > > John, mind giving that one a shot in your test setup as well?
>
> Well, don't mind. It doesn't work in my test setup.
>
> I'm back to the drawing board...
Please ignore my last mail, apparently i
On Wed, Mar 29, 2017 at 02:36:11PM +0200, Jinpu Wang wrote:
> On Wed, Mar 29, 2017 at 2:26 PM, Johannes Thumshirn <jthumsh...@suse.de>
> wrote:
> > On Wed, Mar 29, 2017 at 12:53:28PM +0100, John Garry wrote:
> >> On 29/03/2017 12:29, Johannes Thumshirn wrote:
> >
On Wed, Mar 29, 2017 at 02:36:11PM +0200, Jinpu Wang wrote:
> On Wed, Mar 29, 2017 at 2:26 PM, Johannes Thumshirn
> wrote:
> > On Wed, Mar 29, 2017 at 12:53:28PM +0100, John Garry wrote:
> >> On 29/03/2017 12:29, Johannes Thumshirn wrote:
> >> >On Wed, Mar 2
On Wed, Mar 29, 2017 at 12:53:28PM +0100, John Garry wrote:
> On 29/03/2017 12:29, Johannes Thumshirn wrote:
> >On Wed, Mar 29, 2017 at 12:15:44PM +0100, John Garry wrote:
> >>On 29/03/2017 10:41, Johannes Thumshirn wrote:
> >>>In the advent of an SAS device unre
On Wed, Mar 29, 2017 at 12:53:28PM +0100, John Garry wrote:
> On 29/03/2017 12:29, Johannes Thumshirn wrote:
> >On Wed, Mar 29, 2017 at 12:15:44PM +0100, John Garry wrote:
> >>On 29/03/2017 10:41, Johannes Thumshirn wrote:
> >>>In the advent of an SAS device unre
On Wed, Mar 29, 2017 at 12:15:44PM +0100, John Garry wrote:
> On 29/03/2017 10:41, Johannes Thumshirn wrote:
> >In the advent of an SAS device unregister we have to wait for all destruct
> >works to be done to not accidently delay deletion of a SAS rphy or it's
> >children to
On Wed, Mar 29, 2017 at 12:15:44PM +0100, John Garry wrote:
> On 29/03/2017 10:41, Johannes Thumshirn wrote:
> >In the advent of an SAS device unregister we have to wait for all destruct
> >works to be done to not accidently delay deletion of a SAS rphy or it's
> >children to
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
--
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
--
6
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
---
drivers/scsi/isci/init.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 0b5b5db..afa6b25 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isc
In the advent of an SAS device unregister we have to wait for all destruct
works to be done to not accidently delay deletion of a SAS rphy or it's
children to the point when we're removing the SCSI or SAS hosts.
Signed-off-by: Johannes Thumshirn <jthumsh...@suse.de>
---
drivers/scsi/
6
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/isci/init.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 0b5b5db..afa6b25 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -267,15 +267,22
In the advent of an SAS device unregister we have to wait for all destruct
works to be done to not accidently delay deletion of a SAS rphy or it's
children to the point when we're removing the SCSI or SAS hosts.
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/libsas/sas_discover.c | 4
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
--
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshir
they have no callstack of the affected path in their changelogs.
I'm not sure whether to mark this patches as stable or not. I tend to say no
here, although we've seen complaints/bug reports on lkml and the scsi list.
Johannes Thumshirn (6):
scsi: sas: flush destruct workqueue on device
After commit bcdde7e ("sysfs: make __sysfs_remove_dir() recursive") changed the
removal path of kernfs to make it recursive we have to remove the SAS host
before the SCSI host or we will see sysfs warnings on not found sysfs groups for
kobjects.
Signed-off-by: Johannes Thumshirn
--
1001 - 1100 of 2637 matches
Mail list logo
