Shaun,
On 8/23/16 09:22, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 6:57 PM, Damien Le Moal
> wrote:
>>
>> Shaun,
>>
>> On 8/22/16 13:31, Shaun Tancheff wrote:
>> [...]
>>> -int sd_zbc_setup_discard(struct scsi_disk *sdkp, struct request *rq,
>>> - sector_t sector, uns
Please check the return on line 1517. It looks suspicious that it does
not release the lock, unlike the return on line 1508.
julia
---
Hi Jitendra,
[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree
On Mon, Aug 22, 2016 at 6:57 PM, Damien Le Moal wrote:
>
> Shaun,
>
> On 8/22/16 13:31, Shaun Tancheff wrote:
> [...]
>> -int sd_zbc_setup_discard(struct scsi_disk *sdkp, struct request *rq,
>> - sector_t sector, unsigned int num_sectors)
>> +int sd_zbc_setup_discard(struct sc
Shaun,
On 8/22/16 13:31, Shaun Tancheff wrote:
[...]
> -int sd_zbc_setup_discard(struct scsi_disk *sdkp, struct request *rq,
> - sector_t sector, unsigned int num_sectors)
> +int sd_zbc_setup_discard(struct scsi_cmnd *cmd)
> {
> - struct blk_zone *zone;
> + struct re
https://bugzilla.kernel.org/show_bug.cgi?id=151661
--- Comment #11 from Piotr Szymaniak ---
Created attachment 229761
--> https://bugzilla.kernel.org/attachment.cgi?id=229761&action=edit
config-4.7.0
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsub
https://bugzilla.kernel.org/show_bug.cgi?id=151661
--- Comment #10 from Piotr Szymaniak ---
Created attachment 229751
--> https://bugzilla.kernel.org/attachment.cgi?id=229751&action=edit
config-4.3.6
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsub
https://bugzilla.kernel.org/show_bug.cgi?id=151661
--- Comment #9 from Piotr Szymaniak ---
Created attachment 229741
--> https://bugzilla.kernel.org/attachment.cgi?id=229741&action=edit
dmesg vanilla 4.3.6 (with Alex patch)
I tried previous vanilla kernels 4.x.latest-released and, as 4.6.x pri
On 22 August 2016 at 20:32, Shaun Tancheff wrote:
> On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
>> I don't see how that's possible. count / n_block will always be
>> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
>> that isn't even a "buffer limit" anyway. By SG_IO do yo
On Mon, Aug 22, 2016 at 3:07 PM, Tom Yan wrote:
> I don't see how that's possible. count / n_block will always be
> smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
> that isn't even a "buffer limit" anyway. By SG_IO do you mean like
> SCSI Write Same commands that issued with
>> @@ -526,15 +526,9 @@ static int aac_send_raw_srb(struct aac_dev* dev, void
>> __user * arg)
>> goto cleanup;
>> }
>>
>> - user_srbcmd = kmalloc(fibsize, GFP_KERNEL);
>> - if (!user_srbcmd) {
>> - dprintk((KERN_DEBUG"aacraid: Could not make a copy
I don't see how that's possible. count / n_block will always be
smaller than 65535 * ATA_MAX_TRIM_RNUM(64) = 4194240. Not to mention
that isn't even a "buffer limit" anyway. By SG_IO do you mean like
SCSI Write Same commands that issued with sg_write_same or so? If
that's the case, that's what exac
On Mon, Aug 22, 2016 at 1:55 PM, wrote:
> From: Tom Yan
>
> In commit 5c79097a28c2 ("libata-scsi: reject WRITE SAME (16) with
> n_block that exceeds limit"), it is made sure that
> ata_set_lba_range_entries() will never be called with a request
> size (n_block) that is larger than the number of
From: Tom Yan
In commit 5c79097a28c2 ("libata-scsi: reject WRITE SAME (16) with
n_block that exceeds limit"), it is made sure that
ata_set_lba_range_entries() will never be called with a request
size (n_block) that is larger than the number of blocks that a
512-byte block TRIM payload can describ
> From: Markus Elfring
> Date: Sat, 20 Aug 2016 20:05:24 +0200
>
> Reuse existing functionality from memdup_user() instead of keeping duplicate
> source code.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/scsi/aacraid/commctrl.
On 8/11/2016 2:24 PM, Christoph Hellwig wrote:
On Fri, Jul 22, 2016 at 05:24:00PM -0700, James Smart wrote:
This patchset adds NVME support to the lpfc FC driver. It reworks
the core driver for both NVME and SCSI protocol support, then adds the
nvme-over-fabrics host and target interfaces whi
On 8/11/2016 2:23 PM, Christoph Hellwig wrote:
On Fri, Jul 22, 2016 at 05:23:59PM -0700, James Smart wrote:
Add FC LLDD loopback driver to test FC host and target transport within
nvme-fabrics
To aid in the development and testing of the lower-level api of the FC
transport, this loopback driv
On 8/11/2016 2:22 PM, Christoph Hellwig wrote:
+ queue->work_q = alloc_workqueue("ntfc%d.%d.%d", 0, 0,
+ assoc->tgtport->fc_target_port.port_num,
+ assoc->a_id, qid);
Do we really need a workqueue per queue?
I thought we did
Are you going to send a FC support patch for nvme-cli as well?
I will, but concentrating on core support for now. I expect a fair
number of things need to be done in the cli.
+ assoc_rqst->assoc_cmd.ersp_ratio = cpu_to_be16(ersp_ratio);
+ assoc_rqst->assoc_cmd.sqsize = cpu_t
On 8/2/2016 5:15 PM, J Freyensee wrote:
+int
+fcloop_fcp_op(struct nvmet_fc_target_port *tgtport,
+ struct nvmefc_tgt_fcp_req *tgt_fcpreq)
+{
+ ...
+
+ return 0;
if this function returns an 'int', why would it always return 0 and not
the fcp_err values (if
On 8/1/2016 9:37 PM, J Freyensee wrote:
+static void
+nvmet_fc_free_target_queue(struct nvmet_fc_tgt_queue *queue)
+{
+ struct nvmet_fc_tgtport *tgtport = queue->assoc->tgtport;
+ unsigned long flags;
+
+ /*
+* beware: nvmet layer hangs waiting for a completion if
+
On 7/29/2016 3:10 PM, J Freyensee wrote:
+ /* TODO:
+* assoc_rqst->assoc_cmd.cntlid = cpu_to_be16(?);
+* strncpy(assoc_rqst->assoc_cmd.hostid, ?,
+* min(FCNVME_ASSOC_HOSTID_LEN, NVMF_NQN_SIZE));
+* strncpy(assoc_rqst->assoc_cmd.hostnqn, ?,
+*
On Mon, Aug 22, 2016 at 2:11 AM, Hannes Reinecke wrote:
> On 08/22/2016 06:34 AM, Shaun Tancheff wrote:
>> Currently the RB-Tree zone cache is fast and flexible. It does
>> use a rather largish amount of ram. This model reduces the ram
>> required from 120 bytes per zone to 16 bytes per zone with
Hi Vasundhara,
[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience)
>-Original Message-
>From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
>Sent: Sunday, August 21, 2016 2:19 PM
>To: linux-scsi@vger.kernel.org; megaraidlinux@avagotech.com; James E.
>J.
>Bottomley; Kashyap Desai; Martin K. Petersen; Sumit Saxena; Uday Lingala
>Cc: LKML; kern
Hi Johannes,
[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.8-rc3]
[cannot apply to next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto
When shutting down a session I'm seeing this hung_task message:
INFO: task kworker/u128:0:6 blocked for more than 480 seconds.
Tainted: GE N 4.4.17-default+ #241
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u128:0 D 880237615c00 0
target_sess_cmd_list_waiting() might hit on a condition where
the kref for the command is already 0, but the destructor has
not been called yet (or is stuck in waiting for a spin lock).
Rather than leaving the command on the list we should explicitly
remove it to avoid race issues later on.
Signed
When allocating a new command we should add the pointer to the
debug statements; that allows us to match this with other debug
statements for handling data.
Signed-off-by: Hannes Reinecke
---
drivers/target/tcm_fc/tfc_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
Update the debug statements to match those from libfc.
Signed-off-by: Hannes Reinecke
---
drivers/target/tcm_fc/tfc_sess.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/target/tcm_fc/tfc_sess.c b/drivers/target/tcm_fc/tfc_sess
The libfc stack assigns exchange IDs based on the CPU the request
was received on, so we need to send the responses via the same CPU.
Otherwise the send logic gets confuses and responses will be delayed,
causing exchange timeouts on the initiator side.
Signed-off-by: Hannes Reinecke
---
drivers/
Not every failure is due to out-of-memory; the ACLs might not be
set, too. So return a detailed error code in ft_sess_create()
instead of just a NULL pointer.
Signed-off-by: Hannes Reinecke
---
drivers/target/tcm_fc/tfc_sess.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --gi
Hi Nic,
here's a set of patches and fixes I've found during debugging
FCoE over virtio.
The first two fix a race condition I've encountered during starting
and stopping initiators; they are similar to your prior patches,
but I still think they should be applied to avoid any race issues.
The next t
On 21/08/2016 01:44, zhangfei wrote:
On 2016年08月10日 21:19, John Garry wrote:
Add core code for internal abort functionality.
The internal abort features allows the host controller
to abort commands which are still active in the
controller but have not yet been sent to the slave
device.
Typic
On 08/22/2016 06:34 AM, Shaun Tancheff wrote:
> Currently the RB-Tree zone cache is fast and flexible. It does
> use a rather largish amount of ram. This model reduces the ram
> required from 120 bytes per zone to 16 bytes per zone with a
> moderate transformation of the blk_zone_lookup() api.
>
>
34 matches
Mail list logo
