tree: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc
head: 523c106ad4b186f1f869accf24be35c370f5e611
commit: 523c106ad4b186f1f869accf24be35c370f5e611 [192/192] scsi: tcm_qla2xxx:
Minimize #include directives
config: sparc64-allyesconfig (attached as .config)
compiler: sparc6
On Do, 2019-04-04 at 08:51 -0700, Bart Van Assche wrote:
> On Thu, 2019-04-04 at 16:47 +0200, Oliver Neukum wrote:
> > If a reset of a SCSI device requires no relocking of the door, the
> > flag must be reset anyway, lest it trigger unnecessary door action
> > later on.
> >
> > Signed-off-by: Oliv
On Tue, 2019-04-09 at 16:10 +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc
> head: 523c106ad4b186f1f869accf24be35c370f5e611
> commit: 523c106ad4b186f1f869accf24be35c370f5e611 [192/192] scsi: tcm_qla2xxx:
> Minimize #include directives
Replace the static define (ZFCP_DIAG_MAX_AGE) with a module parameter.
This way users can choose how much time should pass between refreshes of
diagnostic buffers. The default remains to be 5s, like it was before.
By setting the new module parameter to 0, the caching of diagnostic
buffers for user
In the same vein as the previous patch, add diagnostic data capture for
the Exchange Config Data command.
Reviewed-by: Steffen Maier
Signed-off-by: Benjamin Block
---
drivers/s390/scsi/zfcp_diag.c | 14 --
drivers/s390/scsi/zfcp_diag.h | 7 +++
drivers/s390/scsi/zfcp_fsf.c |
Hello all,
with FC-LS-3 Fibre Channel got support for the RDP Extended Link
Service, which we can use to gather diagnostics data (health values from
the optics and such). To gather those data from our local link, the FCP
Channel firmware added some new fields in our Exchange Port Data
firmware com
The FCP channel exposes two central interfaces to receive information
about the local FCP-Adapter/-Port: Exchange Port and Exchange Config
Data. Using these commands can negatively impact the adapter if we allow
them to be sent at a very high rate.
The later parts of this patchset will introduce n
In addition to the diagnostic data from the local SFP transceiver this
patch adds an interface to read the advertised buffer-to-buffer credit
from the local FC_Port.
With this patch the userspace-interface will only read data stored in
the corresponding "diagnostic buffer" (that was stored during
Adds implicit updates of cached diagnostics via Exchange Config Data
when reading SysFS attributes interfacing them. Right now this only
affects the new B2B-Credit diagnostic attribute.
This uses the same mechanism previously also used for cached diagnostics
of Exchange Port Data.
Reviewed-by: St
This adds an interface to read the diagnostics of the local SFP
transceiver of an FCP-Channel from userspace. This comes in the form of
new SysFS entries that are attached to the CCW device representing the
FCP device. Each type of data gets its own SysFS entry; the whole
collection of entries is p
A new FCP channel feature allows us to read the diagnostics from our
local SFP transceivers. To make use of that add a flag
(FSF_FEATURE_REQUEST_SFP_DATA) to the feature-set we request from the
FCP channel. Whether the channel actually implements this can be
determined via an other new flag (FSF_FE
When the FSF functions for Exchange Config/Port Data were separated into
a async- and synchronous variation - where the synchronous variation is
and was only used by userspace-interfaces, and the asynchronous
variation by ERP - it was designed such that the synchronous variation
could optionally ta
This patch adds implicit updates to the SysFS entries that read the
diagnostic data stored in the "caching buffer" for Exchange Port Data.
An update is triggered once the buffer is older than ZFCP_DIAG_MAX_AGE
milliseconds (5s). This entails sending an Exchange Port Data command to
the FCP-Channel
Adds a new FSF-Request status flag (ZFCP_STATUS_FSFREQ_XDATAINCOMPLETE)
that signal that the data received using Exchange Config Data or
Exchange Port Data was incomplete. This new flags is set in the
respective handlers during the response path.
With this patch, only the synchronous FSF-functions
Avoid that the SPARC build fails as follows:
drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_init_lport':
>> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1614:3: error: implicit declaration of
>> function 'vzalloc'; did you mean 'kvzalloc'?
>> [-Werror=implicit-function-declaration]
On Wed, 2019-04-03 at 09:06 -0700, Bart Van Assche wrote:
> scsi_send_eh_cmnd() is only used to request sense data, to submit a TUR or
> to submit a START UNIT. None of these commands modify the data stored on
> the SCSI device so there is no risk of data loss.
>
> The ability to modify the SCSI d
Bart,
> Avoid that the SPARC build fails as follows:
Rolled into the original commit.
--
Martin K. Petersen Oracle Linux Engineering
Bart,
>> (1) Accept that some error handling steps are skipped if a user sets the
>> device state to "blocked".
>> (2) Prevent users to change the device state to "blocked".
We can't really remove an exposed interface. So at the very least the
string "blocked" would have to trigger somethin
Hi Himanshu,
If I boot and install commit 1a61e5486aeb from Martin's tree ("scsi: lpfc: add
support for posting FC events on FPIN reception"; that's before my changes went
in) then a kernel oops appears if I try to enable target mode. This does not
happen with Linus' master tree so it must have b
Hi Bart,
Thanks for reporting this issue. I will take a look and send correction patch.
Thanks,
Himanshu
On 4/9/19, 9:18 PM, "Bart Van Assche" wrote:
External Email
--
Hi Himanshu,
If I boot and in
Hi Martin,
This series fixes issue with driver such as device staying in blocked
state and Link up hang.
Please apply this series to 5.1/scsi-fixes for 5.1.0-rc6 inclusion at your
earliest convenience.
Thanks,
Himanshu
Quinn Tran (2):
qla2xxx: Fix device staying in blocked state
qla2xxx:
From: Quinn Tran
Prevent driver from endless loop or hang in the case of
NPort ID change.
Following stack trace is seen
Feb 12 08:21:17 localhost kernel: Call Trace:
Feb 12 08:21:17 localhost kernel: ? __schedule+0x254/0x840
Feb 12 08:21:17 localhost kernel: ? up+0x12/0x50
Feb 12 08:21:17 local
From: Quinn Tran
This patch fixes issue reported by some of the customers,
who discvored that after some event in SAN if the devices
disappear and path seems to remain in blocked state. Once
the device reappears, driver does not seem to update path
to online. This issue appears because of the def
On Wed 2019-04-03 14:28:14, Sakari Ailus wrote:
> Ping.
>
> On Tue, Mar 26, 2019 at 02:35:10PM +0100, Petr Mladek wrote:
> > Linus,
> >
> > On Mon 2019-03-25 21:32:28, Sakari Ailus wrote:
> > > %pF and %pf are functionally equivalent to %pS and %ps conversion
> > > specifiers. The former are depr
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 434
From: Alastair D'Silva
With modern high resolution screens, we can display more data, which makes
life a bit easier when debugging.
Allow 64 bytes to be dumped per line.
Signed-off-by: Alastair D'Silva
---
lib/hexdump.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
dif
From: Alastair D'Silva
In order to support additional features in hex_dump_to_buffer, replace
the ascii bool parameter with flags.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
drive
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces flags which allow lines of padding bytes to be
suppressed, making the output easier to interpret: HEXDUMP_SUPPRESS_0X00,
HEXDUMP_SUPPRE
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg. wi
On Wed, 2019-04-10 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Some buffers may only be partially filled with useful data, while the
> rest
> is padded (typically with 0x00 or 0xff).
>
This patch introduces flags which allow lines of padding bytes to be
> suppressed, mak
On Wed, Apr 10, 2019 at 01:17:19PM +1000, Alastair D'Silva wrote:
> @@ -107,7 +108,7 @@ EXPORT_SYMBOL(bin2hex);
> * string if enough space had been available.
> */
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int
> groupsize,
> -char *linebuf, size_t
On Sun, Apr 07, 2019 at 08:56:16PM +0200, Ondrej Zary wrote:
> This reverts commit e184f2bf4d9f1a3c612a8c1d67e73e9cf8ab5ab9.
> It does not compile but following patches will fix that.
Please just resurrect it as a proper driver that fits modern standards,
including the coding style. To make your
From: Colin Ian King
The error return path via label rel_resource checks for a non-null
skb before free'ing it. However, skb is always null at this exit
path, so the null check and the free are redundant and can be removed.
Removing this allows the original goto's to rel_resource to be cleaned
u
Am 09.04.2019 15:38, schrieb Colin King:
> From: Colin Ian King
>
> The error return path via label rel_resource checks for a non-null
> skb before free'ing it. However, skb is always null at this exit
> path, so the null check and the free are redundant and can be removed.
> Removing this al
On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> Alan,
>
> > So it looks as though the SCSI subsystem doesn't like to have a reset
> > handler call scsi_remove_host.
>
> Are you talking about a PCI device removal handler or a SCSI error
> handler?
The context of this discussion is a USB mass
On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> On Mon, 8 Apr 2019, Martin K. Petersen wrote:
>
> >
> > Alan,
> >
> > > So it looks as though the SCSI subsystem doesn't like to have a reset
> > > handler call scsi_remove_host.
> >
> > Are you talking about a PCI device removal handler o
When printing a megasas_decode_evt() message, the code member of the evt_detail
is not reported.
This make the debugging more complicated as some code paths depends on this
value.
Reporting the code member makes the context more explicit.
Signed-off-by: Erwan Velu
---
drivers/scsi/megaraid/me
On Tue, 9 Apr 2019, Bart Van Assche wrote:
> On Tue, 2019-04-09 at 10:44 -0400, Alan Stern wrote:
> +AD4 On Mon, 8 Apr 2019, Martin K. Petersen wrote:
> +AD4
> +AD4 +AD4
> +AD4 +AD4 Alan,
> +AD4 +AD4
> +AD4 +AD4 +AD4 So it looks as though the SCSI subsystem doesn't like to have
> a reset
> +A
On 4/8/2019 1:50 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a ql_log message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Cheers,
-Mukesh
---
drivers/scsi/qla2xxx/qla_nvme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi,
Thanks for the comments.
I tried to run sg_write_same over sg device and I am seeing the same problem.
The result is as follows:
0. Kernel configs
Version: 5.1-rc1
Boot parameter: dm_mod.use_blk_mq=Y scsi_mod.use_blk_mq=Y
1. Normal state
: (As expected) The command succeeded
$ sg_write_sa
When SCSI blk-mq is enabled, there is a bug in handling errors in scsi_queue_rq.
Specifically, the bug is not setting result field of scsi_request correctly when
the dispatch of the command has been failed. Since the upper layer code
including the sg_io ioctl expects to receive any error status fro
Hello,
This is the test results.
0. Kernel configs
Version: 5.1-rc1
Boot parameter: dm_mod.use_blk_mq=Y scsi_mod.use_blk_mq=Y
1. Normal state
: (As expected) The command succeeded
$ sg_write_same --lba=100 --xferlen=512 /dev/sg5
$
2. Immediately after bringing down the iSCSI interface at the t
On Tue, 2019-04-09 at 14:53 -0700, Jaesoo Lee wrote:
> When SCSI blk-mq is enabled, there is a bug in handling errors in
> scsi_queue_rq.
> Specifically, the bug is not setting result field of scsi_request correctly
> when
> the dispatch of the command has been failed. Since the upper layer code
On 4/8/19 7:22 PM, Finn Thain wrote:
>
> It has been queued up by Martin and James on git.kernel.org. Apparently it
> is to be pushed in the v5.2 merge window.
>
Awesome.
Thanks
--
Gustavo
Let me comment in line.
On Tue, Apr 9, 2019 at 3:14 PM Bart Van Assche wrote:
>
> On Tue, 2019-04-09 at 14:53 -0700, Jaesoo Lee wrote:
> > When SCSI blk-mq is enabled, there is a bug in handling errors in
> > scsi_queue_rq.
> > Specifically, the bug is not setting result field of scsi_request co
On Tue, 2019-04-09 at 16:29 -0700, Jaesoo Lee wrote:
> Let me comment in line.
>
> On Tue, Apr 9, 2019 at 3:14 PM Bart Van Assche wrote:
> >
> > On Tue, 2019-04-09 at 14:53 -0700, Jaesoo Lee wrote:
> > > When SCSI blk-mq is enabled, there is a bug in handling errors in
> > > scsi_queue_rq.
> >
Let me send v2 addressing your comments.
Thanks,
Jaesoo Lee.
On Tue, Apr 9, 2019 at 4:45 PM Bart Van Assche wrote:
>
> On Tue, 2019-04-09 at 16:29 -0700, Jaesoo Lee wrote:
> > Let me comment in line.
> >
> > On Tue, Apr 9, 2019 at 3:14 PM Bart Van Assche wrote:
> > >
> > > On Tue, 2019-04-09 a
When SCSI blk-mq is enabled, there is a bug in handling errors in scsi_queue_rq.
Specifically, the bug is not setting result field of scsi_request correctly when
the dispatch of the command has been failed. Since the upper layer code
including the sg_io ioctl expects to receive any error status fro
Bart,
> From which context does that unbind happen? From inside a SCSI EH
> callback or from the context of a workqueue? I think the former is not
> allowed but that the latter is allowed. The SRP initiator driver
> (ib_srp.c) follows the latter approach.
Yeah. It's better to punt the actual te
On 20-03-19, 15:19, Rajendra Nayak wrote:
> On some qualcomm platforms DPU needs to express a perforamnce state
> requirement on a power domain depennding on the clock rates.
> Use OPP table from DT to register with OPP framework and use
> dev_pm_opp_set_rate() to set the clk/perf state.
>
> Signe
On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
>
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the fr
On 4/10/19 2:02 AM, Jaesoo Lee wrote:
When SCSI blk-mq is enabled, there is a bug in handling errors in scsi_queue_rq.
Specifically, the bug is not setting result field of scsi_request correctly when
the dispatch of the command has been failed. Since the upper layer code
including the sg_io ioctl
On Tue, Apr 09, 2019 at 04:33:59PM +0200, walter harms wrote:
>
>
> Am 09.04.2019 15:38, schrieb Colin King:
> > From: Colin Ian King
> >
> > The error return path via label rel_resource checks for a non-null
> > skb before free'ing it. However, skb is always null at this exit
> > path, so the
53 matches
Mail list logo
