'
description in 'fc_rport_create'
drivers/scsi/libfc/fc_rport.c:1452: warning: Function parameter or member
'rdata_arg' not described in 'fc_rport_logo_resp'
drivers/scsi/libfc/fc_rport.c:1452: warning: Excess function parameter
'lport_arg' description in 'fc_rport_logo_resp'
Cc: Hannes Reinecke
: warning: Function parameter or member
'tov' not described in 'fc_lport_els_request'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/libfc/fc_lport.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes
'netdev' not described in 'fcoe_netdev_map_lookup'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/fcoe/fcoe_transport.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/fcoe/fcoe_transport.c
b/drivers/scsi/fcoe/fcoe_transport.c
index
: warning: Function parameter or member
'lport' not described in 'fcoe_ctlr_disc_start'
drivers/scsi/fcoe/fcoe_ctlr.c:3033: warning: Excess function parameter 'fip'
description in 'fcoe_ctlr_disc_start'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/fcoe/fcoe_ctlr.c | 26
'timeout' not described in 'fcoe_elsct_send'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/fcoe/fcoe.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index cb41d166e0c0f..0f9274960dc6b 100644
On 7/13/20 9:46 AM, Lee Jones wrote:
This is my fault (can't even blame copy/paste).
Cc: Hannes Reinecke
Reported-by: Johannes Thumshirn
Signed-off-by: Lee Jones
---
drivers/scsi/libfc/fc_disc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/libfc
0
+#define FC_FDMI_HBA_ATTR_SERIALNUMBER_LEN 80
#define FC_FDMI_HBA_ATTR_MODEL_LEN256
#define FC_FDMI_HBA_ATTR_MODELDESCR_LEN 256
#define FC_FDMI_HBA_ATTR_HARDWAREVERSION_LEN 256
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamle
parameter or member 'sp'
not described in 'fc_invoke_resp'
drivers/scsi/libfc/fc_exch.c:727: warning: Function parameter or member 'fp'
not described in 'fc_invoke_resp'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/libfc/fc_exch.c | 7 ++-
1 file changed, 6 insertions
: warning: Function parameter or member
'disc_arg' not described in 'fc_disc_gpn_ft_resp'
drivers/scsi/libfc/fc_disc.c:498: warning: Excess function parameter 'lp_arg'
description in 'fc_disc_gpn_ft_resp'
Cc: Hannes Reinecke
Signed-off-by: Lee Jones
---
drivers/scsi/libfc/fc_disc.c | 6
gt;transferred_length = 0;
+ fd->status = NVME_SC_INTERNAL;
}
- fd->status = 0;
spin_unlock_irqrestore(>cmd_lock, flags);
fd->done(fd);
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead
sent' :-)
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
return ret;
}
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
tate == FC_OBJSTATE_ONLINE &&
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
;nr_zones =
DIV_ROUND_UP(reg_dev->capacity,
str r1, [r6, #64] @ tmp306, reg_dev_166->nr_zones
git blame points at this commit:
commit 70978208ec91d798066f4c291bc98ff914bea222
Author: Hannes Reinecke
Date: Mon May 11 10:24:30 2020 +0200
dm zoned: metadata version 2
Reverting
lag);
+ kfree(fc_trc_flag);
}
/*
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG N
_adisc && (vport->fc_flag & FC_RSCN_MODE)) ||
> + if (vport->cfg_use_adisc && ((vport->fc_flag & FC_RSCN_MODE) ||
> ((ndlp->nlp_fcp_info & NLP_FCP_2_DEVICE) &&
> - (ndlp->nlp_type & NLP_FCP_TARGET))) {
&
s_cont_entry_t *pkt)
> if (sense_len == 0) {
> rsp->status_srb = NULL;
> sp->done(sp, cp->result);
> - } else {
> - WARN_ON_ONCE(true);
> }
> }
>
>
Not that I can speak for firmware documentation, but:
*shost)
> {
> @@ -1996,6 +2003,7 @@ static struct fc_function_template qedf_fc_transport_fn
> = {
> .show_host_active_fc4s = 1,
> .show_host_maxframe_size = 1,
>
> + .get_host_port_id = qedf_get_host_port_id,
> .show_host_port_id = 1,
> .show_host_suppo
al. Although I'm not sure for RDMA; here we don't
necessarily have a host transport address, so we _might_ send the
discovery via the wrong controller in a CMIC enviroment.
- Match the options in nvme-cli, and just discard the event if it
doesn't match. Which is some additional coding in nvme-cli and might ran
afoul if we ever miss events.
I'd go for the second option; after considering the first introduces far
too many conditions rendering debugging impractical.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 247165 (AG München), GF: Felix Imendörffer
me/host/core.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE Soft
, *end;
> struct scatterlist *sgde = scsi_prot_sglist(cmnd);
>
> if (!_dump_buf_dif) {
> @@ -138,7 +143,12 @@ struct scsi_dif_tuple {
> }
>
> dst = _dump_buf_dif;
> + end = ((char *) dst) + ((1 << PAGE_SHIFT) << _
isk(struct gendisk
> *disk, struct nvme_id_ns *id)
> if (ns->head->disk) {
> nvme_update_disk_info(ns->head->disk, ns, id);
> blk_queue_stack_limits(ns->head->disk->queue, ns->queue);
> + revalidate_disk(ns->head->disk);
>
itation interval (mS) */
> #define FCOE_CTLR_FCF_LIMIT 20 /* max. number of FCF entries */
> #define FCOE_CTLR_VN2VN_LOGIN_LIMIT 3 /* max. VN2VN rport login
> retries */
>
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTe
y\n");
> + FC_LIBFC_DBG("Receiving frames for an lport that "
> + "has not been initialized correctly\n");
> fc_frame_free(fp);
> return;
> }
>
Reviewed-by: Hannes Reinecke
Cheers
On 7/5/19 7:53 PM, Douglas Gilbert wrote:
> On 2019-07-05 3:22 a.m., Hannes Reinecke wrote:
[ .. ]
>> As mentioned, rescan-scsi-bus.sh is keeping references to /proc/scsi as
>> a fall back only, as it's meant to work kernel independent. Per default
>> it'll be using /sys,
ssion before the last request is reached.
>
> Suggested-by: Stefan Hajnoczi
> Signed-off-by: Paolo Bonzini
> ---
> drivers/scsi/virtio_scsi.c | 55 +++---
> 1 file changed, 40 insertions(+), 15 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers
On 7/5/19 9:44 AM, Stefan Hajnoczi wrote:
> On Fri, Jul 05, 2019 at 09:12:37AM +0200, Hannes Reinecke wrote:
>> On 7/4/19 3:19 PM, Paolo Bonzini wrote:
>>> On 19/06/19 12:31, Paolo Bonzini wrote:
>>>>> I'm a bit unsure if 'bd->last' is always set; it's quite ob
c/sgp_dd.8:mapping to SCSI block devices should be checked with 'cat
> /proc/scsi/scsi'
> ./doc/sg_dd.8:notes this at completion. If direct IO is selected and
> /proc/scsi/sg/allow_dio
> ./doc/sg_dd.8:this at completion. If direct IO is selected and
> /proc/scsi/sg/allow_dio
> ./doc/sg_dd.
t;> That is 6 (not 38) by my count.
>
> Hi Doug,
>
> This is the command I ran:
>
> $ git grep /proc/scsi | wc -l
> 38
>
> I think your query excludes scripts/rescan-scsi-bus.sh.
>
You can ignore rescan-scsi-bus.sh.
It's keeping /proc access as a fallback opt
re is the ->commit_rqs() callback invoked?
I don't seem to be able to find it...
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer
encountered before sending
* the request with SCMD_LAST set.
So it should be somewhere in the error path, probably scsi_error or
something. But I don't seem to be able to find it ...
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
t; @@ -659,5 +666,6 @@ void nvme_mpath_uninit(struct nvme_ctrl *ctrl)
> {
> kfree(ctrl->ana_log_buf);
> ctrl->ana_log_buf = NULL;
> + ctrl->ana_enabled = false;
> }
>
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> inde
On 6/19/19 11:52 AM, Marcos Paulo de Souza wrote:
> On Wed, Jun 19, 2019 at 08:34:56AM +0200, Hannes Reinecke wrote:
>> On 6/19/19 5:35 AM, Martin K. Petersen wrote:
>>>
>>> Marcos,
>>>
>>>> WWID composed from VPD data from device, specifically pag
gt;last' setting
onto the SCMD_LAST flag; I would even go so far and make this an
independent patch.
Once to above points are cleared, that is.
But if that one is in, why do we need to have the separate 'commit_rqs'
callback?
Can't we let the driver decide to issue a doorbell kick (or whatever the
driver decides to do there)?
If we ensure that the SCMD_LAST flag is always set for the end of a
batch (even if this batch consists only of one request), the driver
simply can evaluate the flag and do its actions.
Why do we need a new callback here?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
attribute is not present.
So making 'wwid' conditional would actually defeat its very purpose, and
we should leave it blank if not supported.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com +49 911 74053 688
SUSE
er chips, this
>* area can be read and written by both the host and the sequencer.
>
Indeed trivial.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com +49 911 74053 688
SUSE
. Wysocki
---
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: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284
/sysfs-devices-system-cpu | 18
Documentation/admin-guide/pm/intel_epb.rst | 27 ++
arch/x86/kernel/cpu/intel_epb.c| 93
-
3 files changed, 134 insertions(+), 4 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes
nlock(>disc.disc_mutex);
+ return;
+ }
kref_get(>ptp_rdata->kref);
lport->ptp_rdata->ids.port_name = remote_wwpn;
lport->ptp_rdata->ids.node_name = remote_wwnn;
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
On 2/27/19 7:09 AM, YueHaibing wrote:
Friendly ping:
Who can review or take this, please?
Thanks
On 2019/1/30 18:11, YueHaibing wrote:
There is a potential NULL pointer dereference in case
fc_rport_create() fails and returns NULL.
Fixes: 2580064b5ec6 ("scsi: libfc: Replace ->rport_create
wahn
CC: Nick Desaulniers
CC: Nathan Chancellor
CC: Hannes Reinecke
Suggested-by: Johannes Thumshirn
---
[ v2:
- Based on the original patch by Lukas Bulwahn
- Suggestion by Johannes T. [1] required some changes:
+ s/case FIP_ST_VMMP_START/case FIP_ST_V*N*MP_START
+ s/return FI
On 2/5/19 4:09 PM, John Garry wrote:
On 05/02/2019 14:52, Keith Busch wrote:
On Tue, Feb 05, 2019 at 05:24:11AM -0800, John Garry wrote:
On 04/02/2019 07:12, Hannes Reinecke wrote:
Hi Hannes,
So, as the user then has to wait for the system to declars 'ready for
CPU remove', why can't we
On 2/5/19 3:52 PM, Keith Busch wrote:
On Tue, Feb 05, 2019 at 05:24:11AM -0800, John Garry wrote:
On 04/02/2019 07:12, Hannes Reinecke wrote:
Hi Hannes,
So, as the user then has to wait for the system to declars 'ready for
CPU remove', why can't we just disable the SQ and wait for all I/O
On 2/1/19 10:57 PM, Thomas Gleixner wrote:
On Fri, 1 Feb 2019, Hannes Reinecke wrote:
Thing is, if we have _managed_ CPU hotplug (ie if the hardware provides some
means of quiescing the CPU before hotplug) then the whole thing is trivial;
disable SQ and wait for all outstanding commands
can handle surprise CPU hotplug at all, given all
the possible race conditions.
But then I might be wrong.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 904
'm totally wrong and
it's already been taken care of.
But if there is no generic mechanism this really is a fit topic for
LSF/MM, as most other drivers would be affected, too.
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
On 1/28/19 12:06 PM, Johannes Thumshirn wrote:
I'll be moving on to different things in the storage stack and Hannes
agreed to take over FCoE.
Cc: Hannes Reinecke
Signed-off-by: Johannes Thumshirn
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 1/26/19 11:39 AM, Greg Kroah-Hartman wrote:
On Sat, Jan 26, 2019 at 11:26:47AM +0100, Hannes Reinecke wrote:
On 1/22/19 3:27 PM, Greg Kroah-Hartman wrote:
We are trying to get rid of BUS_ATTR() and the usage of that in the fcoe
driver can be trivially converted to use BUS_ATTR_WO(), so use
On 1/22/19 3:27 PM, Greg Kroah-Hartman wrote:
We are trying to get rid of BUS_ATTR() and the usage of that in the fcoe
driver can be trivially converted to use BUS_ATTR_WO(), so use that
instead.
Cc: Johannes Thumshirn
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Signed-off-by: Greg
,7 +855,6 @@ ssize_t fcoe_ctlr_destroy_store(struct bus_type *bus,
mutex_unlock(_mutex);
return rc;
}
-EXPORT_SYMBOL(fcoe_ctlr_destroy_store);
/**
* fcoe_transport_create() - Create a fcoe interface
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
u want ...
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
t;Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/scsi/aic7xxx/aic79xx_core.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
Sorry, I thought I'd done so already.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reineck
On 12/21/18 4:29 PM, James Bottomley wrote:
[scsi list cc added]
On Fri, 2018-12-21 at 08:54 +0100, Greg Kroah-Hartman wrote:
We are trying to get rid of BUS_ATTR() and the usage of that in the
fcoe driver can be trivially converted to use BUS_ATTR_WO(), so use
that instead.
At the same time
.
Addresses-Coverity-ID: 1465234 ("Missing break in switch")
Addresses-Coverity-ID: 1465238 ("Missing break in switch")
Addresses-Coverity-ID: 1465242 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/scsi/myrb.c | 3 +++
1 file changed, 3 inser
Cc: Sergey Senozhatsky
Cc: Hannes Reinecke
Tested-by: Howard Chen
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
Actually, I have a similar patch for NVMe in older revisions, so maybe I
should
Cc: Sergey Senozhatsky
Cc: Hannes Reinecke
Tested-by: Howard Chen
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
Actually, I have a similar patch for NVMe in older revisions, so maybe I
should
On 10/7/18 11:04 AM, Daniel Vetter wrote:
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> wrote:
>>
>> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
>> From: James Bottomley
>> Date: Sat, 6 Oct 2018 14:21:56 -0700
>> Subject: [PATCH 1/2] code-of-conduct: Fix the
On 10/7/18 11:04 AM, Daniel Vetter wrote:
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> wrote:
>>
>> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
>> From: James Bottomley
>> Date: Sat, 6 Oct 2018 14:21:56 -0700
>> Subject: [PATCH 1/2] code-of-conduct: Fix the
(presumably it is being inlined) and this looks like an actual bug :-(
>
> This warning now appears after the merge of the scsi tree.
>
I have send a new round of patches to the scsi mailing list (cf
'libfc/fcoe: disc_mutex fixes') which address this issue.
Cheers,
Hannes
--
Dr. Hannes R
(presumably it is being inlined) and this looks like an actual bug :-(
>
> This warning now appears after the merge of the scsi tree.
>
I have send a new round of patches to the scsi mailing list (cf
'libfc/fcoe: disc_mutex fixes') which address this issue.
Cheers,
Hannes
--
Dr. Hannes R
On Mon, 28 May 2018 23:02:36 -0400
Mike Snitzer wrote:
> On Mon, May 28 2018 at 9:19pm -0400,
> Martin K. Petersen wrote:
>
> >
> > Mike,
> >
> > I understand and appreciate your position but I still don't think
> > the arguments for enabling DM multipath are sufficiently
> > compelling.
On Mon, 28 May 2018 23:02:36 -0400
Mike Snitzer wrote:
> On Mon, May 28 2018 at 9:19pm -0400,
> Martin K. Petersen wrote:
>
> >
> > Mike,
> >
> > I understand and appreciate your position but I still don't think
> > the arguments for enabling DM multipath are sufficiently
> > compelling.
that the file gets
> cleaned up.
>
> Fixes: 345e29608b4b ("scsi: scsi: Export blacklist flags to sysfs")
>
> Cc: Hannes Reinecke <h...@suse.de>
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> ---
> drivers/scsi/Makefile |2 +-
> 1 file changed,
8b4b ("scsi: scsi: Export blacklist flags to sysfs")
>
> Cc: Hannes Reinecke
> Signed-off-by: Randy Dunlap
> ---
> drivers/scsi/Makefile |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-4.17-rc4.orig/drivers/scsi/Makefile
> +++ linux-4.1
_fc_create_ctrl(struct device *dev, struct
> nvmf_ctrl_options *opts)
> }
> spin_unlock_irqrestore(_fc_lock, flags);
>
> + pr_warn("%s: %s - %s combination not found\n",
> + __func__, opts->traddr, opts->host_traddr);
> return ERR_PTR(-ENOENT);
> }
>
ns *opts)
> }
> spin_unlock_irqrestore(_fc_lock, flags);
>
> + pr_warn("%s: %s - %s combination not found\n",
> + __func__, opts->traddr, opts->host_traddr);
> return ERR_PTR(-ENOENT);
> }
>
>
Reviewed-by: Hannes
te(cmd, DRIVER_SENSE);
> set_host_byte(cmd, DID_ABORT);
> - cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
> + cmd->result |= SAM_STAT_CHECK_CONDITION;
> return 1;
> }
>
>
Reviewed-by: Hannes Reinecke <h...@sus
;result |= SAM_STAT_CHECK_CONDITION << 1;
> + cmd->result |= SAM_STAT_CHECK_CONDITION;
> return 1;
> }
>
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
struct scsi_device_handler *dh;
>
> + if (!name || strlen(name) == 0)
> + return NULL;
> +
> dh = __scsi_dh_lookup(name);
> if (!dh) {
> request_module("scsi_dh_%s", name);
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheers,
Hannes
ame || strlen(name) == 0)
> + return NULL;
> +
> dh = __scsi_dh_lookup(name);
> if (!dh) {
> request_module("scsi_dh_%s", name);
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
>
RISC-V ?
(evil grin :-)
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE
On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
>
RISC-V ?
(evil grin :-)
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE
> drivers/scsi/device_handler/scsi_dh_alua.c | 8
> drivers/scsi/device_handler/scsi_dh_emc.c | 2 +-
> drivers/scsi/device_handler/scsi_dh_rdac.c | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Cheer
ers/scsi/device_handler/scsi_dh_alua.c | 8
> drivers/scsi/device_handler/scsi_dh_emc.c | 2 +-
> drivers/scsi/device_handler/scsi_dh_rdac.c | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke
CHL_INT0_SL_PHY_ENABLE_MSK);
> @@ -1217,7 +1219,7 @@ static int phy_down_v3_hw(int phy_no, struct hisi_hba
> *hisi_hba)
> hisi_sas_phy_write32(hisi_hba, phy_no, CHL_INT0, CHL_INT0_NOT_RDY_MSK);
> hisi_sas_phy_write32(hisi_hba, phy_
phy_down_v3_hw(int phy_no, struct hisi_hba
> *hisi_hba)
> hisi_sas_phy_write32(hisi_hba, phy_no, CHL_INT0, CHL_INT0_NOT_RDY_MSK);
> hisi_sas_phy_write32(hisi_hba, phy_no, PHYCTRL_NOT_RDY_MSK, 0);
>
> - return 0;
> + return IRQ_HANDLED;
> }
>
> static void phy_bcast_v3_hw(int phy_
a no-op.
Care to clarify?
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)
e internal abort task will
> be executed only when the retry process finished.
>
Hmm. That sounds weird.
I would have expected that a link retrain will force a device reset,
after which no tasks should be active on the target.
Consequently the succeeding abort task will be a no-op.
Care to clarify?
Che
R10: ffdf R11: 0293 R12:
> 55867dd47410
> [ 70.441199] R13: R14: 0001 R15:
> 7f6d4c03be00
> [ 70.441486] Code: fe ff ff 44 0f b6 bd 7f ff ff ff 80 7d ab 00 79
> 05 45 84 ff 74 7b 48 83 c4 78 5b 41 5c 41 5d 41 5e 41 5f 5d 4
R10: ffdf R11: 0293 R12:
> 55867dd47410
> [ 70.441199] R13: R14: 0001 R15:
> 7f6d4c03be00
> [ 70.441486] Code: fe ff ff 44 0f b6 bd 7f ff ff ff 80 7d ab 00 79
> 05 45 84 ff 74 7b 48 83 c4 78 5b 41 5c 41 5d 41 5e 41 5f 5d 4
("command_id=%u, result=%llu, retries=%u, flags=0x%x,
> status=%u",
> + __entry->cid,
> + (unsigned long long)le64_to_cpu(__entry->result),
> + __entry->retries, __entry->flags, __entry->status)
> +
> +);
_id=%u, result=%llu, retries=%u, flags=0x%x,
> status=%u",
> + __entry->cid,
> + (unsigned long long)le64_to_cpu(__entry->result),
> + __entry->retries, __entry->flags, __entry->status)
> +
nd, cmd, sizeof(__entry->cmnd));
> + ),
> +
> + TP_printk("nsid=%u, command_id=%u, flags=0x%x, metadata=0x%llx,
> cmd=(%s %s)",
> + le32_to_cpu(__entry->nsid), __entry->cid, __entry->flags,
> + (unsigned long long) le6
entry->cmnd));
> + ),
> +
> + TP_printk("nsid=%u, command_id=%u, flags=0x%x, metadata=0x%llx,
> cmd=(%s %s)",
> + le32_to_cpu(__entry->nsid), __entry->cid, __entry->flags,
> + (unsigned long long) le64_to_cpu(__entry->meta
complete_request);
>
>
Hmm. Why do we need to call blk_mq_map_queue() here?
Is there a chance that we end up with a _different_ hctx on completion
than that one used for submission?
If not, why can't we just keep a pointer to the hctx in struct request?
Cheers,
Hannes
--
Dr. Hannes Rein
request);
>
>
Hmm. Why do we need to call blk_mq_map_queue() here?
Is there a chance that we end up with a _different_ hctx on completion
than that one used for submission?
If not, why can't we just keep a pointer to the hctx in struct request?
Cheers,
Hannes
--
Dr. Hannes ReineckeTe
On 12/15/2017 01:18 PM, Hannes Reinecke wrote:
> On 12/08/2017 10:42 AM, Jason Yan wrote:
>> If the PHY burst too many events, we will alloc a lot of events for the
>> worker. This may leads to memory exhaustion.
>>
>> Dan Williams suggested to shut down th
On 12/15/2017 01:18 PM, Hannes Reinecke wrote:
> On 12/08/2017 10:42 AM, Jason Yan wrote:
>> If the PHY burst too many events, we will alloc a lot of events for the
>> worker. This may leads to memory exhaustion.
>>
>> Dan Williams suggested to shut down th
eue_event(ev, >disc_work[ev].work, ha);
> + if (list_empty(>phy_list))
> + continue;
> +
> + sas_phy = container_of(port->phy_list.next, struct asd_sas_phy,
> + port_phy_el);
> + ha->
of(port->phy_list.next, struct asd_sas_phy,
> + port_phy_el);
> + ha->notify_port_event(sas_phy, PORTE_BROADCAST_RCVD);
> }
> mutex_unlock(>disco_mutex);
> }
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinec
> drivers/scsi/libsas/sas_discover.c | 32 ++--
> drivers/scsi/libsas/sas_expander.c | 8 +++-
> drivers/scsi/libsas/sas_internal.h | 1 +
> drivers/scsi/libsas/sas_port.c | 3 +++
> include/scsi/libsas.h | 3 +
drivers/scsi/libsas/sas_port.c | 3 +++
> include/scsi/libsas.h | 3 +--
> include/scsi/scsi_transport_sas.h | 1 +
> 7 files changed, 27 insertions(+), 22 deletions(-)
>
Signed-off-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTea
sas_discover_event(phy->port, DISCE_REVALIDATE_DOMAIN);
> +
> + if (phy->port)
> + flush_workqueue(phy->port->ha->disco_q);
> }
>
> void sas_porte_link_reset_err(struct work_struct *work)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
orte_broadcast_rcvd(struct work_struct *work)
>
> SAS_DPRINTK("broadcast received: %d\n", prim);
> sas_discover_event(phy->port, DISCE_REVALIDATE_DOMAIN);
> +
> + if (phy->port)
> + flush_workqueue(phy->port->ha->disco_
er.c | 2 +-
> drivers/scsi/libsas/sas_event.c| 6 +++---
> drivers/scsi/libsas/sas_init.c | 18 ++
> include/scsi/libsas.h | 3 +++
> 4 files changed, 25 insertions(+), 4 deletions(-)
>
Reviewed-by: Hannes Reinecke <h...@suse.com>
Chee
gt; CC: Dan Williams
> Signed-off-by: Jason Yan
> ---
> drivers/scsi/libsas/sas_discover.c | 2 +-
> drivers/scsi/libsas/sas_event.c| 6 +++---
> drivers/scsi/libsas/sas_init.c | 18 ++
> include/scsi/libsas.h | 3 +++
> 4 files changed, 25 inse
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Add a sysfs attr that LLDD can configure it for every host. We made
> a example in hisi_sas. Other LLDDs using libsas can implement it if
> they want.
>
> Suggested-by: Hannes Reinecke <h...@suse.com>
> Signed-off-by: Jason Yan &l
On 12/08/2017 10:42 AM, Jason Yan wrote:
> Add a sysfs attr that LLDD can configure it for every host. We made
> a example in hisi_sas. Other LLDDs using libsas can implement it if
> they want.
>
> Suggested-by: Hannes Reinecke
> Signed-off-by: Jason Yan
> CC: John
changed, 64 insertions(+), 2 deletions(-)
>
Well, this still looks a bit error prone; what if the system runs out of
memory before the pool is exhausted?
(Also a threshold of 1024 events is a bit arbitrary; one might want to
adjust that).
Couldn't you allocate two static
024 events is a bit arbitrary; one might want to
adjust that).
Couldn't you allocate two static events always (for shutdown and signal
loss), and then use a fixed pool?
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de
101 - 200 of 1903 matches
Mail list logo
