Re: [PATCH] sd_zbc: Write unlock zone from sd_uninit_cmnd()

On 8/10/17 11:14, Damien Le Moal wrote: > Bart, > > On 8/10/17 00:24, Bart Van Assche wrote: >> On Wed, 2017-08-09 at 14:15 +0900, Damien Le Moal wrote: >>> Overall, yes, that is possible. However, considering only write commands >>> to a single zone, since at any time only one command is

Re: [PATCH] sd_zbc: Write unlock zone from sd_uninit_cmnd()

Bart, On 8/10/17 00:24, Bart Van Assche wrote: > On Wed, 2017-08-09 at 14:15 +0900, Damien Le Moal wrote: >> Overall, yes, that is possible. However, considering only write commands >> to a single zone, since at any time only one command is dequeued (the >> one holding the zone lock), having the

[RFT PATCH v3 1/1] aic7xxx: printk() lines unbroken (WIP)

Current code is not SMP-friendly and since now each printk() call generates a separate line in the log, the output is mostly unreadable. This patch makes printed lines consistent and unbroken. It is necessarily big since it touches almost every printk() in the driver. Signed-off-by: Michał

Re: [PATCH v2 3/5] aic7xxx: remove rules for shipped files

On Fri, Aug 04, 2017 at 01:28:09AM +0200, Michał Mirosław wrote: [...] > --- a/drivers/scsi/aic7xxx/Makefile > +++ b/drivers/scsi/aic7xxx/Makefile > @@ -61,8 +61,6 @@ $(obj)/aic7xxx_seq.h: $(src)/aic7xxx.seq $(src)/aic7xxx.reg > $(obj)/aicasm/aicasm [...] > -else > -$(obj)/aic7xxx_reg_print.c:

RE: [PATCH RESEND 0/6] hpsa: support legacy boards

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Tuesday, August 08, 2017 3:35 AM > To: Martin K. Petersen > Cc: Don Brace ; Christoph Hellwig > ; James Bottomley >

Re: [PATCHv2 4/4] scsi_devinfo: fixup string compare

On Wed, 9 Aug 2017, Hannes Reinecke wrote: > When checking the model and vendor string we need to use the > minimum value of either string, otherwise we'll miss out on > wildcard matches. This is now true only for the model string, not the vendor string. And even for the model string, you

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On Wed, 2017-08-09 at 12:43 -0400, Laurence Oberman wrote: > Your latest patch on stock upstream without Ming's latest patches is > behaving for me. > > As already mentioned, the requeue -11 and clone failure messages are > gone and I am not actually seeing any soft lockups or hard lockups. >

Re: Increased memory usage with scsi-mq

On 09/08/2017 18:01, Christoph Hellwig wrote: > On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote: >> can_queue should depend on the virtqueue size, which unfortunately can >> vary for each virtio-scsi device in theory. The virtqueue size is >> retrieved by drivers/virtio prior to

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On 08/08/2017 10:28 PM, Laurence Oberman wrote: On Tue, 2017-08-08 at 20:11 -0400, Laurence Oberman wrote: On Tue, 2017-08-08 at 22:17 +0800, Ming Lei wrote: Hi Guys, Laurence and I see a system lockup issue when running concurrent big buffered write(4M bytes) to IB SRP on v4.13-rc3.

Re: [PATCHv2] scsi_dh_alua: suppress errors from unsupported devices

> index 0962fd5..c3aea06 100644 > --- a/drivers/scsi/device_handler/scsi_dh_alua.c > +++ b/drivers/scsi/device_handler/scsi_dh_alua.c > @@ -1100,6 +1100,8 @@ static int alua_bus_attach(struct scsi_device *sdev) > err = alua_initialize(sdev, h); > if (err == SCSI_DH_NOMEM) >

Re: Increased memory usage with scsi-mq

On Mon, Aug 07, 2017 at 03:07:48PM +0200, Paolo Bonzini wrote: > can_queue should depend on the virtqueue size, which unfortunately can > vary for each virtio-scsi device in theory. The virtqueue size is > retrieved by drivers/virtio prior to calling vring_create_virtqueue, and > in QEMU it is

Re: [PATCH 2/6] hpsa: add support for legacy boards

On Wed, Aug 09, 2017 at 05:08:05PM +0200, Hannes Reinecke wrote: > On 08/09/2017 03:41 PM, Christoph Hellwig wrote: > > On Tue, Aug 08, 2017 at 10:35:11AM +0200, Hannes Reinecke wrote: > >> Add support for legacy boards, ensuring to enable the driver for > >> those boards only when

Re: [PATCH] scsi: make 'state' device attribute pollable

On Wed, Aug 09, 2017 at 03:09:18PM +0200, Hannes Reinecke wrote: > While the 'state' attribute can (and will) change occasionally, > calling 'poll()' or 'select()' on it fails as sysfs is never > notified that the state has changed. > With this patch calling 'poll()' or 'select()' will work >

Re: [PATCH] sd_zbc: Write unlock zone from sd_uninit_cmnd()

On Wed, 2017-08-09 at 14:15 +0900, Damien Le Moal wrote: > Overall, yes, that is possible. However, considering only write commands > to a single zone, since at any time only one command is dequeued (the > one holding the zone lock), having the "lock+dequeue" and > "unlock+requeue" both atomic

Re: [PATCH 3/4] scsi: add Mylex RAID controller

On 08/09/2017 04:10 PM, Christoph Hellwig wrote: > On Mon, Aug 07, 2017 at 08:09:11AM +0200, Hannes Reinecke wrote: >> On 08/05/2017 01:39 PM, Christoph Hellwig wrote: >>> Can you use normal linux style for the code instead of copy and >>> pasting the weird naming and capitalization from the

Re: [PATCH 0/4] mylex: Replace DAC960 block driver

On 08/09/2017 04:23 PM, Christoph Hellwig wrote: > On Wed, Aug 02, 2017 at 04:13:24PM +0200, Hannes Reinecke wrote: >> Hi all, >> >> as we're trying to get rid of the remaining request_fn drivers here's >> a patchset to move the DAC960 driver to the SCSI stack. >> The new driver is called 'mylex'.

Re: [PATCH 2/6] hpsa: add support for legacy boards

On 08/09/2017 03:41 PM, Christoph Hellwig wrote: > On Tue, Aug 08, 2017 at 10:35:11AM +0200, Hannes Reinecke wrote: >> Add support for legacy boards, ensuring to enable the driver for >> those boards only when 'hpsa_allow_any' is set. > > Why the wildcard instead of the specific IDs from the

Re: [PATCH 5/6] hpsa: do not print errors for unsupported report luns format

On 08/09/2017 03:46 PM, Christoph Hellwig wrote: > I don't like the misnamed supported flag. Either we should always ignore > the errors, or key it off a specific flag for newer firmware. > Well, there is no such hardware flag; there are several features implemented across the board. Hence we

Re: [PATCH 2/6] hpsa: add support for legacy boards

On 08/09/2017 03:45 PM, Christoph Hellwig wrote: >> -static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id) >> +static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id, >> +bool *supported) >> { >> int i; >> u32 subsystem_vendor_id,

Re: [PATCH 0/4] mylex: Replace DAC960 block driver

On Wed, Aug 02, 2017 at 04:13:24PM +0200, Hannes Reinecke wrote: > Hi all, > > as we're trying to get rid of the remaining request_fn drivers here's > a patchset to move the DAC960 driver to the SCSI stack. > The new driver is called 'mylex'. > > The Mylex/DAC960 HBA comes in two flavours; the

[RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

In contrast to the normal SCSI-lib, the BSG block-queue doesn't make use of any extra init_rq_fn() to make additional allocations during request-creation, and the request sense-pointer is not used to transport SCSI sense data, but is used as backing for the bsg_job->reply pointer; that in turn is

[RFC PATCH 0/6] bsg: fix regression resulting in panics when sending commands via BSG and some sanity cleanups

Hello all, Steffen noticed recently that we have a regression in the BSG code that prevents us from sending any traffic over this interface. After I researched this a bit, it turned out that this affects not only zFCP, but likely all LLDs that implements the BSG API. This was introduced in 4.11

[RFC PATCH 3/6] bsg: scsi-transport: add compile-tests to prevent reply-buffer overflows

The BSG implementations use the bsg_job's reply buffer as storage for their own custom reply structures (e.g.: struct fc_bsg_reply or struct iscsi_bsg_reply). The size of bsg_job's reply buffer and those of the implementations is not dependent in any way the compiler can currently check. To make

[RFC PATCH 6/6] bsg: reduce unnecessary arguments for blk_complete_sgv4_hdr_rq()

Since struct bsg_command is now used in every calling case, we don't need separation of arguments anymore that are contained in the same bsg_command. Signed-off-by: Benjamin Block --- block/bsg.c | 20 +--- 1 file changed, 9 insertions(+), 11

[RFC PATCH 5/6] bsg: reduce unnecessary arguments for bsg_map_hdr()

Since struct bsg_command is now used in every calling case, we don't need separation of arguments anymore that are contained in the same bsg_command. Signed-off-by: Benjamin Block --- block/bsg.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-)

[RFC PATCH 4/6] bsg: refactor ioctl to use regular BSG-command infrastructure for SG_IO

Before, the SG_IO ioctl for BSG devices used to use its own on-stack data to assemble and send the specified command. The read and write calls use their own infrastructure build around the struct bsg_command and a custom slab-pool for that. Rafactor this, so that SG_IO ioctl also uses struct

[RFC PATCH 2/6] bsg: assign sense_len instead of fixed SCSI_SENSE_BUFFERSIZE

We do set rq->sense_len when we assigne the reply-buffer in blk_fill_sgv4_hdr_rq(). No point in possibly deviating from this value later on. bsg-lib.h specifies: unsigned int reply_len; /* * On entry : reply_len indicates the buffer size allocated for * the reply. * *

Re: [PATCH 3/4] scsi: add Mylex RAID controller

On Mon, Aug 07, 2017 at 08:09:11AM +0200, Hannes Reinecke wrote: > On 08/05/2017 01:39 PM, Christoph Hellwig wrote: > > Can you use normal linux style for the code instead of copy and > > pasting the weird naming and capitalization from the DAC960 driver? > > > Yes; already planned for v2. But

Re: [PATCH] megaraid_sas: move command counter to correct place

On 8.8.2017 09:37, Sumit Saxena wrote: >> -Original Message- >> From: Martin K. Petersen [mailto:martin.peter...@oracle.com] >> Sent: Monday, August 07, 2017 11:07 PM >> To: Tomas Henzl >> Cc: linux-scsi@vger.kernel.org; sumit.sax...@broadcom.com; >> kashyap.de...@broadcom.com >> Subject:

Re: [PATCH 6/6] hpsa: handle unsupported devices more gracefully

On Tue, Aug 08, 2017 at 10:35:15AM +0200, Hannes Reinecke wrote: > From: Jeff Mahoney > > Add a warning message if an unsupported device is found and the > hpsa_allow_any parameter is not set. > Also make the hpsa_allow_any parameter writeable once the hpsa > driver is loaded.

Re: [PATCH 5/6] hpsa: do not print errors for unsupported report luns format

I don't like the misnamed supported flag. Either we should always ignore the errors, or key it off a specific flag for newer firmware.

Re: [PATCH 4/6] hpsa: Ignore errors for unsupported LV_DEVICE_ID VPD page

Looks fine, Reviewed-by: Christoph Hellwig

Re: [PATCH 2/6] hpsa: add support for legacy boards

> -static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id) > +static int hpsa_lookup_board_id(struct pci_dev *pdev, u32 *board_id, > + bool *supported) > { > int i; > u32 subsystem_vendor_id, subsystem_device_id; > @@ -7242,9 +7266,22 @@ static

Re: [PATCH 3/6] hpsa: disable volume status check for older controller

Why that weird supported flag check? (which also means I need to got back to the previous patch and understand that part..)

Re: [PATCH 2/6] hpsa: add support for legacy boards

On Tue, Aug 08, 2017 at 10:35:11AM +0200, Hannes Reinecke wrote: > Add support for legacy boards, ensuring to enable the driver for > those boards only when 'hpsa_allow_any' is set. Why the wildcard instead of the specific IDs from the cciss driver?

Re: [PATCH 1/6] hpsa: consolidate status variables

These seem to be modified from sysfs files, so you'll run into read-modify-write atomicy issues with bitfields. That being said while plain ints are somewhat safe the right thing would be to use proper atomic bitops.

[PATCH] scsi: make 'state' device attribute pollable

While the 'state' attribute can (and will) change occasionally, calling 'poll()' or 'select()' on it fails as sysfs is never notified that the state has changed. With this patch calling 'poll()' or 'select()' will work properly. Signed-off-by: Hannes Reinecke ---

Re: [PATCH v3 03/13] mpt3sas: SGL to PRP Translation for I/Os to NVMe devices

Hi Martin, This code was added to detect holes, when we started testing with 4.9 kernel. when we disabled "use_blk_mq" and no merges, we are hitting issues with holes. Anyhow In latest upstream, it got fixed with this commit 5a8d75a1b8c99bdc926ba69b7b7dbe4fae81a5af So we are removing the code

[no subject]

внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность

[PATCH 1/2] tests/scsi: add SCSI midlayer test group

Add a test group for tests of the SCSI midlayer. Signed-off-by: Hannes Reinecke --- tests/scsi/group | 26 ++ 1 file changed, 26 insertions(+) create mode 100644 tests/scsi/group diff --git a/tests/scsi/group b/tests/scsi/group new file mode 100644 index

[PATCH 2/2] tests/scsi/0001: Regression test for SCSI device blacklisting

SCSI device blacklisting seems to be a tricky subject, with lots of potential for messing up the selection algorithm. This adds a test for catching regressions here. Signed-off-by: Hannes Reinecke --- tests/scsi/001 | 69 ++

[PATCHv2 3/4] scsi: whitespace fixes in scsi_devinfo.c

Signed-off-by: Hannes Reinecke --- drivers/scsi/scsi_devinfo.c | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c index 28fea83..776c701 100644 ---

[PATCHv2 0/4] Fixup blacklist handling

Hi all, the SCSI blacklist handling seems to be rather tricky issue; everytime a fix is included it tends to break other devices. This patchset attempt to simplify the devlist handling yet again, but this time implementing the framework for regression testing, too. A patch adding a regression

[PATCHv2 4/4] scsi_devinfo: fixup string compare

When checking the model and vendor string we need to use the minimum value of either string, otherwise we'll miss out on wildcard matches. And we should take card when matching with zero size strings; results might be unpredictable. With this patch the rules for matching devinfo strings are as

[PATCHv2 1/4] scsi_debug: allow to specify inquiry vendor and model

For testing purposes we need to be able to pass in the inquiry vendor and model. Signed-off-by: Hannes Reinecke --- drivers/scsi/scsi_debug.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/scsi_debug.c

[PATCHv2 2/4] scsi: Export blacklist flags to sysfs

Each scsi device is scanned according to the found blacklist flags, but this information is never presented to sysfs. This makes it quite hard to figure out if blacklisting worked as expected. With this patch we're exporting an additional attribute 'blacklist' containing the blacklist flags for

[PATCH] scsi: dpt_i2o: remove redundant null check on array device

From: Colin Ian King The null check on pHba->channel[chan].device is redundant because device is an array and hence can never be null. Remove the check. Detected by CoverityScan, CID#115362 ("Array compared against 0") Signed-off-by: Colin Ian King

UFS maximum access unit is 8KB

Hi, I am now using one hikey960, and Linux kernel version is 4.4.77. And found that for UFS driver version, the maximum transformation is 8KB. Means that if I using 128KB chuck size to program in the user space, but, from ftrace/blktrace, It shows that it always programs by 8KB in kernel. please

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

Hi Martin, Subhash On Wed, Aug 9, 2017 at 11:18 AM, Kishon Vijay Abraham I wrote: > Vivek, > > On Tuesday 08 August 2017 09:20 PM, Vivek Gautam wrote: >> Hi Koshon, >> >> On 2017-08-08 17:39, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Friday 04 August 2017 12:18 PM, Vivek