On 03/30/2018 03:29 PM, Ilya Dryomov wrote:
On Fri, Mar 30, 2018 at 9:17 PM, Gustavo A. R. Silva
wrote:
In preparation to enabling -Wvla, remove the use of stack VLA.
In this particular case, variable buf_size is replaced with a constant
expression that can be
On Fri, Mar 30, 2018 at 9:17 PM, Gustavo A. R. Silva
wrote:
> In preparation to enabling -Wvla, remove the use of stack VLA.
>
> In this particular case, variable buf_size is replaced with a constant
> expression that can be computed at preprocessing time. This avoids two
On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote:
> Yes I will be there to discuss the multi-LUN approach. I wanted to get
> these interface details out so we could have some background and
> perhaps folks would come with ideas. I don't have much more to put
> out, but I will certainly answer
In preparation to enabling -Wvla, remove the use of stack VLA.
In this particular case, variable buf_size is replaced with a constant
expression that can be computed at preprocessing time. This avoids two
VLA warnings. Also, as a consequence of the mentioned change, some code
was slightly
Yes I will be there to discuss the multi-LUN approach. I wanted to get
these interface details out so we could have some background and
perhaps folks would come with ideas. I don't have much more to put
out, but I will certainly answer questions - either on this list or
directly.
Best regards,
On Fri, 2018-03-30 at 12:21 -0600, Tim Walker wrote:
> Yes, the header LUN field. Sorry!
>
> We hadn't intended to broadcast - we expect to see a LUN specified.
> For a device specific command both LUNs will be affected regardless of
> which LUN is specified in the transport field. e.g. if we
Hi Bart-
Yes, the header LUN field. Sorry!
We hadn't intended to broadcast - we expect to see a LUN specified.
For a device specific command both LUNs will be affected regardless of
which LUN is specified in the transport field. e.g. if we command LUN1
to stop (START STOP UNIT) then LUN0 will
On Fri, 2018-03-30 at 12:07 -0600, Tim Walker wrote:
> Concerning how we are currently allocating commands to LUNs or the
> device as a whole, here is a list based on the current two LUN model.
> This model has LUN0 & LUN1, both reporting 1/2 the total storage. Our
> definition of "device based"
Hello-
Concerning how we are currently allocating commands to LUNs or the
device as a whole, here is a list based on the current two LUN model.
This model has LUN0 & LUN1, both reporting 1/2 the total storage. Our
definition of "device based" is that it ignores the LUN field and
executes the
On Fri, 2018-03-30 at 10:23 +0200, Paolo Valente wrote:
> Still 4.16-rc1, being that the version for which you reported this
> issue in the first place.
A vanilla v4.16-rc1 kernel is not sufficient to run the srp-test software
since RDMA/CM support for the SRP target driver is missing from that
Hi Doug-
Currently, the dual actuator firmware safely spins the drive down if
either LUN receives the START STOP UNIT command. In other words, if
LUN1 receives the command, it will flush any dirty data from LUN1l and
LUN0, then spin down, taking both LUN1 & LUN0 off line. Alternatively,
we've
Hello
I got this kernel BUG on 4.16.0-rc7, here is the reproducer and log, let me
know if you need more info, thanks.
Reproducer:
1. setup target
#nvmetcli restore /etc/rdma.json
2. connect target on host
#nvme connect-all -t rdma -a $IP -s 4420during my NVMeoF RDMA testing
3. do fio background
Added CC-s, start of the thread is at
https://lkml.org/lkml/2018/2/26/165
> > > 4.16 git bootup on HP Proliant DL380 G3 pauses for a a minute or two and
> > > then continues with "blocked for more than 120 seconds" message with
> > > libata detection functions in ther stack -
> > >
+Jens, Mike
> Il giorno 30 mar 2018, alle ore 01:16, Bart Van Assche
> ha scritto:
>
> On Thu, 2018-03-29 at 11:02 +0200, Paolo Valente wrote:
>>> Il giorno 01 mar 2018, alle ore 02:35, Bart Van Assche
>>> ha scritto:
>>> Thank you for having
14 matches
Mail list logo