On Thu, Jan 12, 2017 at 7:50 PM, Hannes Reinecke wrote:
> Cleanup the MSI-X handling allowing us to use
> the PCI-layer provided vector allocation.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 98
>
The parameter name should be wwpn instead of wwnn.
Signed-off-by: Fam Zheng
---
include/scsi/libfc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
index 96dd0b3..da5033d 100644
--- a/include/scsi/libfc.h
On 1/13/17 00:02, Jeff Moyer wrote:
> Christoph Hellwig writes:
>
>> On Thu, Jan 12, 2017 at 05:13:52PM +0900, Damien Le Moal wrote:
>>> (3) Any other idea ?
>>
>> Do nothing and ignore the problem. This whole idea so braindead that
>> the person coming up with the T10 language
Dear E-Mail User.
Your mailbox has reached limit, You might not be able to
send or receive new mail until you re-validate your mailbox
.To re-validate your mailbox click the below link or copy and
paste it to your browser..
http://3cruyyp46.ulcraft.com
Technical Support
192.168.0.1
--
To
On Thu, Jan 12 2017 at 3:00am -0500,
Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 08:09:37PM -0500, Mike Snitzer wrote:
> > I'm not following your reasoning.
> >
> > dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl
> > (sd_ioctl -> scsi_cmd_blk_ioctl ->
Sorry sent prematurely...
On Thu, Jan 12, 2017 at 2:22 PM, Robert LeBlanc wrote:
> I'm having trouble replicating the D state issue on Infiniband (I was
> able to trigger it reliably a couple weeks back, I don't know if OFED
> to verify the same results happen there as
In sd.c there are two comment references to 'struct scsi_device *sdp'
as an argument. One of the references has a typo and the other should
be a reference to 'struct device *dev' instead.
Fixed by correcting the typo in the first and changing the explanation
in the second.
Signed-off-by: John
I have a crappy patch (sledgehammer approach) that seems to prevent
the D state issue and the connection recovers, but things are possibly
not being cleaned up properly in iSCSI and so it may have issues after
a few recoveries (one test completed with a lot of resets but no iSCSI
errors).
Hello James Bottomley,
The patch 3417c1b5cb1f: "ses: Fix problems with simple enclosures"
from Dec 8, 2015, leads to the following static checker warning:
drivers/scsi/ses.c:103 ses_recv_diag()
info: return a literal instead of 'ret'
drivers/scsi/ses.c
86 static int
In sd.c there are two comment references to 'struct scsi_device *sdp'
as an argument. One of the references has a typo and the other should
be a reference to 'struct device *dev' instead.
Fixed by correcting the typo in the first and changing the explanation
in the second.
Signed-off-by: John
Hello James Smart,
The patch 352e5fd10598: "scsi: lpfc: Reinstate lpfc_soft_wwn
parameter" from Dec 30, 2016, leads to the following static checker
warning:
drivers/scsi/lpfc/lpfc_attr.c:2156 lpfc_soft_wwpn_store()
info: return a literal instead of 'rc'
Hi, Kashyap,
I'm CC-ing Kent, seeing how this is his code.
Kashyap Desai writes:
> Objective of this patch is -
>
> To move code used in bcache module in block layer which is used to
> find IO stream. Reference code @drivers/md/bcache/request.c
>
On Thu, 2017-01-12 at 10:41 +0200, Sagi Grimberg wrote:
> First, when the nvme device fires an interrupt, the driver consumes
> the completion(s) from the interrupt (usually there will be some more
> completions waiting in the cq by the time the host start processing it).
> With irq-poll, we
Hello Sasikumar Chandrasekaran,
The patch d889344e4e59: "scsi: megaraid_sas: Dynamic Raid Map Changes
for SAS3.5 Generic Megaraid Controllers" from Jan 10, 2017, leads to
the following static checker warning:
drivers/scsi/megaraid/megaraid_sas_fusion.c:2043
megasas_build_ldio_fusion()
On Thu, Jan 12, 2017 at 04:41:00PM +0200, Sagi Grimberg wrote:
>
> >>**Note: when I ran multiple threads on more cpus the performance
> >>degradation phenomenon disappeared, but I tested on a VM with
> >>qemu emulation backed by null_blk so I figured I had some other
> >>bottleneck somewhere
Hello Sasikumar Chandrasekaran,
The patch fdd84e2514b0: "scsi: megaraid_sas: SAS3.5 Generic Megaraid
Controllers Stream Detection and IO Coalescing" from Jan 10, 2017,
leads to the following static checker warning:
drivers/scsi/megaraid/megaraid_sas_fusion.c:1771 megasas_stream_detect()
On Thu, Jan 12, 2017 at 09:27:40AM +0100, Hannes Reinecke wrote:
> On 01/11/2017 11:23 PM, Mike Snitzer wrote:
> >On Wed, Jan 11 2017 at 4:44am -0500,
> >Hannes Reinecke wrote:
> >
> >>Hi all,
> >>
> >>I'd like to attend LSF/MM this year, and would like to discuss a
> >>redesign of
Hello,
I'm Dr. Gertjan Vlieghe (Bank Of England),we have an inheritance of a
deceased client with your surname Contact Dr. Gertjan Vlieghe With
your: Full Name, Tel Number, Age, Occupation and Address through
email: d.vlie...@yahoo.com
Thanks
Dr. Gertjan Vlieghe
Christoph Hellwig writes:
> On Thu, Jan 12, 2017 at 05:13:52PM +0900, Damien Le Moal wrote:
>> (3) Any other idea ?
>
> Do nothing and ignore the problem. This whole idea so braindead that
> the person coming up with the T10 language should be shot. Either a device
> has 511
**Note: when I ran multiple threads on more cpus the performance
degradation phenomenon disappeared, but I tested on a VM with
qemu emulation backed by null_blk so I figured I had some other
bottleneck somewhere (that's why I asked for some more testing).
That could be because of the vmexits
From: Wei Yongjun
A spin lock is taken here so we should use GFP_ATOMIC.
Fixes: 987132167f4b ("scsi: be2iscsi: Fix for crash in beiscsi_eh_device_reset")
Signed-off-by: Wei Yongjun
---
drivers/scsi/be2iscsi/be_main.c | 2 +-
1 file changed, 1
On 01/12/2017 01:23 PM, Sreekanth Reddy wrote:
On Tue, Dec 20, 2016 at 6:57 PM, Hannes Reinecke wrote:
Cleanup the MSI-X handling allowing us to use
the PCI-layer provided vector allocation.
Signed-off-by: Hannes Reinecke
diff --git
Cleanup the MSI-X handling allowing us to use
the PCI-layer provided vector allocation.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 98 +
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 -
2 files changed, 45
On 01/12/2017 08:45 AM, Fam Zheng wrote:
On Thu, 01/12 08:28, Eric Farman wrote:
- if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) !=
0)
+ ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
+ if (ret == -EIO) {
+
On Thu, 01/12 08:28, Eric Farman wrote:
> > > - if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) !=
> > > 0)
> > > + ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
> > > + if (ret == -EIO) {
> > > + cmd->resp.cmd.response =
On 01/11/2017 10:11 PM, Fam Zheng wrote:
On Wed, 01/11 17:02, Eric Farman wrote:
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache
On Thu, Jan 12, 2017 at 01:44:05PM +0200, Sagi Grimberg wrote:
[...]
> Its pretty basic:
> --
> [global]
> group_reporting
> cpus_allowed=0
> cpus_allowed_policy=split
> rw=randrw
> bs=4k
> numjobs=4
> iodepth=32
> runtime=60
> time_based
> loops=1
> ioengine=libaio
> direct=1
> invalidate=1
>
Anyone that know how to figure out the mapping?
Kind regards,
Jelle de Jong
On 08/12/16 13:57, Jelle de Jong wrote:
Hello everybody,
Can anyone help me out with my question?
Thank you in advance.
Kind regards,
Jelle de Jong
On 26/11/16 21:43, Jelle de Jong wrote:
Hello everybody,
I am
On Tue, Dec 20, 2016 at 6:57 PM, Hannes Reinecke wrote:
> Cleanup the MSI-X handling allowing us to use
> the PCI-layer provided vector allocation.
>
> Signed-off-by: Hannes Reinecke
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>
I agree with Jens that we'll need some analysis if we want the
discussion to be affective, and I can spend some time this if I
can find volunteers with high-end nvme devices (I only have access
to client nvme devices.
I have a P3700 but somehow burned the FW. Let me see if I can bring it back
Hi Folks,
I would like to propose a general discussion on Storage stack and device driver
testing.
I think its very useful and needed.
Purpose:-
-
The main objective of this discussion is to address the need for
a Unified Test Automation Framework which can be used by
On Thu, Jan 12, 2017 at 10:23:47AM +0200, Sagi Grimberg wrote:
>
> >>>Hi all,
> >>>
> >>>I'd like to attend LSF/MM and would like to discuss polling for block
> >>>drivers.
> >>>
> >>>Currently there is blk-iopoll but it is neither as widely used as NAPI in
> >>>the
> >>>networking field and
A typical Ethernet network adapter delays the generation of an
interrupt
after it has received a packet. A typical block device or HBA does not
delay
the generation of an interrupt that reports an I/O completion.
>>>
>>> NVMe allows for configurable interrupt coalescing,
I'd like to attend LSF/MM and would like to discuss polling for block
drivers.
Currently there is blk-iopoll but it is neither as widely used as NAPI in
the networking field and accoring to Sagi's findings in [1] performance
with polling is not on par with IRQ usage.
On LSF/MM I'd like to
our patch is applied to the wrong git tree, please drop us a note to
help
> improve the system]
>
> url:
https://github.com/0day-ci/linux/commits/Kashyap-Desai/preview-block-
> layer-help-to-detect-sequential-IO/20170112-024228
> config: i386-randconfig-a0-201702 (attached as .config)
>
On 01/11/2017 11:23 PM, Mike Snitzer wrote:
On Wed, Jan 11 2017 at 4:44am -0500,
Hannes Reinecke wrote:
Hi all,
I'd like to attend LSF/MM this year, and would like to discuss a
redesign of the multipath handling.
With recent kernels we've got quite some functionality required
Hi all,
I'd like to attend LSF/MM and would like to discuss polling for block drivers.
Currently there is blk-iopoll but it is neither as widely used as NAPI in the
networking field and accoring to Sagi's findings in [1] performance with
polling is not on par with IRQ usage.
On LSF/MM I'd
On Thu, Jan 12, 2017 at 05:13:52PM +0900, Damien Le Moal wrote:
> (3) Any other idea ?
Do nothing and ignore the problem. This whole idea so braindead that
the person coming up with the T10 language should be shot. Either a device
has 511 logical sectors or 4k but not this crazy mix.
And make
Regular block devices are always accessible in units of logical block
sizes, regardless of the actual physical block size that the device has.
For hard disks, the common cases are:
512n: 512 B logical and physical blocks
512e: 512B logical blocks and 4096B physical blocks
4Kn: 4096B logical and
On Wed, Jan 11, 2017 at 08:09:37PM -0500, Mike Snitzer wrote:
> I'm not following your reasoning.
>
> dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl
> (sd_ioctl -> scsi_cmd_blk_ioctl -> scsi_cmd_ioctl) if DM's underlying
> block device is a scsi device.
Yes, it it does.
On Wed, Jan 11, 2017 at 05:41:42PM -0500, Mike Snitzer wrote:
> I removed blk-mq on request_fn paths support because it was one of the
> permutations that I felt least useful/stable (see commit c5248f79f3 "dm:
> remove support for stacking dm-mq on .request_fn device(s)")
>
> As for all of the
41 matches
Mail list logo