[PATCH -next] scsi: a100u2w: remove set but not used variable 'bios_phys'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/a100u2w.c: In function 'inia100_probe_one':
drivers/scsi/a100u2w.c:1093:8: warning:
variable 'bios_phys' set but not used [-Wunused-but-set-variable]
It never used since introduction in
comit 4023c4747861 ("[SCSI] a100u2w: Convert into Linux style")
Signed-off-by: YueHaibing
---
drivers/scsi/a100u2w.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
index 00072ed..012aa25 100644
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1089,8 +1089,6 @@ static int inia100_probe_one(struct pci_dev *pdev,
unsigned long port, bios;
int error = -ENODEV;
u32 sz;
- unsigned long biosaddr;
- char *bios_phys;
if (pci_enable_device(pdev))
goto out;
@@ -1140,9 +1138,6 @@ static int inia100_probe_one(struct pci_dev *pdev,
goto out_free_scb_array;
}
- biosaddr = host->BIOScfg;
- biosaddr = (biosaddr << 4);
- bios_phys = phys_to_virt(biosaddr);
if (init_orchid(host)) {/* Initialize orchid chip */
printk("inia100: initial orchid fail!!\n");
goto out_free_escb_array;
Memory leak in ISCSI/pSCSI backend
Hi, I'm not sure if this is the correct list to send this to. I've been trying to set up ISCSI for a number of DVD-ROM drives using targetcli. I have the initiator logging in and creating the device node correctly, however when it reads from the device, the target system rapidly chews up RAM until crashing. Kernel version on target: 4.18.16, from kernel.org, no patches applied I tested the pSCSI backend with a WD 120GB SSD as well, and found that "file -s" on the initiator seemed to cause a slow memory leak on the target, but "mkfs.ext4" again caused a rapid consumption of all RAM. I also tested the IBLOCK backend on the same SSD and found no memory leakage when running "mkfs.ext4" on the initiator. I have the kernel set up to create a vmcore file but haven't worked out where the debug symbols are to use it. So without being able to debug the vmcore, I tried using the 120GB SSD as a swap partition to see if the kernel chewed up swap as well as RAM. It doesn't. When a read on the initiated DVD-ROM device, e.g. "file -s", happens, only system RAM is consumed and swap is untouched. Attached, you will find the output of targetcli for my desired configuration of a single drive. I have another 4 to export from the same system if I can get it working. Please let me know if there's any more information you would like. Thanks, Ben Klein o- / . [...] o- backstores .. [...] | o- block .. [Storage Objects: 0] | o- fileio . [Storage Objects: 0] | o- pscsi .. [Storage Objects: 1] | | o- sr0 .. [/dev/sr0 activated] | o- ramdisk [Storage Objects: 0] o- iscsi [Targets: 1] | o- iqn.2003-01.org.linux-iscsi.frankie.x8664:sn.7ff065e33228 . [TPGs: 1] | o- tpg1 ... [no-gen-acls, no-auth] | o- acls .. [ACLs: 1] | | o- iqn.1993-08.org.debian:kubrik [Mapped LUNs: 1] | | o- mapped_lun1 ... [lun1 pscsi/sr0 (rw)] | o- luns .. [LUNs: 1] | | o- lun1 ... [pscsi/sr0 (/dev/sr0)] | o- portals [Portals: 1] | o- 192.168.9.1:3260 . [OK] o- loopback . [Targets: 0] o- vhost [Targets: 0]
[RFC][PATCH v2] scsi: ufs: Fix hynix ufs bug with quirk on hi36xx SoC
From: Wei Li
Hynix ufs has deviations on hi36xx platform which will result in
ufs bursts transfer failures.
To fix the problem, the Hynix device must set the register
VS_DebugSaveConfigTime to 0x10, which will set time reference
for SaveConfigTime is 250 ns. The time reference for SaveConfigTime
is 40 ns by default.
This patch is necessary to boot on HiKey960 boards that use
Hynix UFS chips (H28U62301AMR model: hB8aL1).
Not sure if this is the preferred way of scoping the quirk to
the controller or not. Feedback would be greatly appreciated!
Cc: Vinayak Holikatti
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Wei Li
Signed-off-by: Dmitry Shmidt
[jstultz: Forward ported from older code, slight tweak to commit message]
Signed-off-by: John Stultz
---
v2:
* Narrowed the UFS chip model to the specific model where
the issue has been seen. (SKhynix H28U62301AMR model: hB8aL1)
* Reworked logic to be contained in ufs-hisi.c since it seems to
be a controller issue that crops up with this specific chip
---
drivers/scsi/ufs/ufs-hisi.c | 14 ++
drivers/scsi/ufs/ufshcd.c | 2 +-
drivers/scsi/ufs/ufshcd.h | 2 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 46df707..a306acf 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -20,6 +20,7 @@
#include "unipro.h"
#include "ufs-hisi.h"
#include "ufshci.h"
+#include "ufs_quirks.h"
static int ufs_hisi_check_hibern8(struct ufs_hba *hba)
{
@@ -390,6 +391,19 @@ static void ufs_hisi_set_dev_cap(struct
ufs_hisi_dev_params *hisi_param)
static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
{
+ struct ufs_dev_desc card = {0};
+
+ if (!ufs_get_device_desc(hba, &card)) {
+ if ((card.wmanufacturerid == UFS_VENDOR_SKHYNIX) &&
+ (STR_PRFX_EQUAL("hB8aL1" /*H28U62301AMR*/, card.model))) {
+ pr_info("Hynix ufs flash device must set
VS_DebugSaveConfigTime 0x10\n");
+ /* VS_DebugSaveConfigTime */
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0xD0A0), 0x10);
+ /* sync length */
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x1556), 0x48);
+ }
+ }
+
/* update */
ufshcd_dme_set(hba, UIC_ARG_MIB(0x15A8), 0x1);
/* PA_TxSkip */
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c55f38e..326fa32 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6242,7 +6242,7 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
return ret;
}
-static int ufs_get_device_desc(struct ufs_hba *hba,
+int ufs_get_device_desc(struct ufs_hba *hba,
struct ufs_dev_desc *dev_desc)
{
int err;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 33fdd3f..31c0562 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -877,6 +877,8 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
u8 param_offset,
u8 *param_read_buf,
u8 param_size);
+int ufs_get_device_desc(struct ufs_hba *hba,
+ struct ufs_dev_desc *dev_desc);
int ufshcd_query_attr(struct ufs_hba *hba, enum query_opcode opcode,
enum attr_idn idn, u8 index, u8 selector, u32 *attr_val);
int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
--
2.7.4
Re: [PATCH] bsg: convert to use blk-mq
On 10/22/18 9:21 AM, Benjamin Block wrote:
> On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote:
>> On 10/22/18 4:03 AM, Benjamin Block wrote:
>>> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
On 10/19/18 9:01 AM, Benjamin Block wrote:
> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
>> On 10/17/18 9:55 AM, Benjamin Block wrote:
>>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
Requires a few changes to the FC transport class as well.
Cc: Johannes Thumshirn
Cc: Benjamin Block
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jens Axboe
---
block/bsg-lib.c | 102 +--
drivers/scsi/scsi_transport_fc.c | 61 ++
2 files changed, 91 insertions(+), 72 deletions(-)
but that's not going to apply cleanly... Can you just try and run my
mq-conversions branch? That has everything, and it also has that
alloc failure fixed.
git://git.kernel.dk/linux-block mq-conversions
>>>
>>> Ok so, that gets past the stage where we initialize the queues. Simple
>>> SCSI-I/O also seems to work, that is for example an INQUIRY(10), but
>>> transport commands that get passed to the driver break. Tried to send
>>> a FibreChannel GPN_FT (remote port discovery).
>>>
>>> As the BSG interface goes. This is a bidirectional command, that has
>>> both a buffer for the request and for the reply. AFAIR BSG will create a
>>> struct request for each of them. Protocol is BSG_PROTOCOL_SCSI,
>>> Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be
>>> transparent till we get into the driver.
>>>
>>> First got this:
>>>
>>> [ 566.531100] BUG: sleeping function called from invalid context at
>>> mm/slab.h:421
>>> [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name:
>>> bsg_api_test
>>> [ 566.531460] 1 lock held by bsg_api_test/3104:
>>> [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at:
>>> hctx_lock+0x30/0x118
>>> [ 566.531498] Preemption disabled at:
>>> [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218
>>> [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
>>>4.19.0-rc6-bb-next+ #1
>>> [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR)
>>> [ 566.531533] Call Trace:
>>> [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8)
>>> [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8
>>> [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298
>>> [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560
>>> [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0
>>> [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118
>>> [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670
>>> [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130
>>> [ 566.531615] [<00820dfe>]
>>> blk_mq_sched_dispatch_requests+0x156/0x1a0
>>> [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160
>>> [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218
>>> [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0
>>> [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8
>>> [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80
>>> [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8
>>> [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500
>>> [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710
>>> [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0
>>> [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40
>>> [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0
>>> [ 566.531815] 1 lock held by bsg_api_test/3104:
>>> [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at:
>>> hctx_lock+0x30/0x118
>>>
>>> And then it dies completely:
>>>
>>> [ 566.531854] Unable to handle kernel pointer dereference in virtual
>>> kernel address space
>>> [ 566.531861] Failing address: TEID: 0483
>>> [ 566.531867] Fault in home space mode while using kernel ASCE.
>>> [ 566.531885] AS:013ec007 R3:effc8007 S:effce000
>>> P:013d
>>> [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>>> [ 566.531938] Modules linked in: ...
>>> [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
>>>4.19.0-rc6-bb-next+ #1
>>> [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR)
>>> [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c
>>> (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp])
>>> [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3
>>> PM:0 RI:0 EA:3
>>> [ 566.532077] Krnl GPRS: 1000 bfb84178
>>> 0001 8004
>>> [ 566.532082]1000 a66251
Re: [RESEND][PATCH] scsi: ufs: Fix hynix ufs bug with quirk on hi36xx SoC
On Tue, Oct 16, 2018 at 4:50 PM, John Stultz wrote: > On Tue, Oct 16, 2018 at 3:48 PM, John Stultz wrote: >> On Mon, Oct 15, 2018 at 8:41 PM, Martin K. Petersen >> wrote: >>> >>> John, >>> Hynix ufs has deviations on hi36xx platform which will result in ufs bursts transfer failures. >>> >>> Is this specific to the particular implementation on hi36xx or all SK >>> Hynix implementations? >> >> I'd have to defer to Wei Li on that question. So I followed up with Wei Li and it seems its something specific to hi36xx that the specific hynix chip brings out, which most other chips don't seem to trigger. > Just to short-cut things a bit, as this is probably an obvious > followup: if it is hi36xx specific, how would you suggest a such a > targeted quirk be added? I'm not sure I see how to get to the > ufs_dev_desc from the ufs-hisi.c code. So yea, I've already reworked the quirk to be specific to the one model of hynix chip, but I'm still a bit confused on best practices for handling these quirks on the controller side. If there's a pointer to similar controller side quirks that are device specific, I'd be glad to rework the patch in that fashion. Otherwise I'll just try to figure out how to get to the ufs_dev_desc from ufs-hisi.c thanks -john
Re: [PATCH] bsg: convert to use blk-mq
On Mon, Oct 22, 2018 at 06:38:36AM -0600, Jens Axboe wrote:
> On 10/22/18 4:03 AM, Benjamin Block wrote:
> > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
> >> On 10/19/18 9:01 AM, Benjamin Block wrote:
> >>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
> On 10/17/18 9:55 AM, Benjamin Block wrote:
> > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
> >> Requires a few changes to the FC transport class as well.
> >>
> >> Cc: Johannes Thumshirn
> >> Cc: Benjamin Block
> >> Cc: linux-scsi@vger.kernel.org
> >> Signed-off-by: Jens Axboe
> >> ---
> >> block/bsg-lib.c | 102 +--
> >> drivers/scsi/scsi_transport_fc.c | 61 ++
> >> 2 files changed, 91 insertions(+), 72 deletions(-)
> >>
> >>
> >> but that's not going to apply cleanly... Can you just try and run my
> >> mq-conversions branch? That has everything, and it also has that
> >> alloc failure fixed.
> >>
> >> git://git.kernel.dk/linux-block mq-conversions
> >>
> >
> > Ok so, that gets past the stage where we initialize the queues. Simple
> > SCSI-I/O also seems to work, that is for example an INQUIRY(10), but
> > transport commands that get passed to the driver break. Tried to send
> > a FibreChannel GPN_FT (remote port discovery).
> >
> > As the BSG interface goes. This is a bidirectional command, that has
> > both a buffer for the request and for the reply. AFAIR BSG will create a
> > struct request for each of them. Protocol is BSG_PROTOCOL_SCSI,
> > Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be
> > transparent till we get into the driver.
> >
> > First got this:
> >
> > [ 566.531100] BUG: sleeping function called from invalid context at
> > mm/slab.h:421
> > [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name:
> > bsg_api_test
> > [ 566.531460] 1 lock held by bsg_api_test/3104:
> > [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at:
> > hctx_lock+0x30/0x118
> > [ 566.531498] Preemption disabled at:
> > [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218
> > [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
> >4.19.0-rc6-bb-next+ #1
> > [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR)
> > [ 566.531533] Call Trace:
> > [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8)
> > [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8
> > [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298
> > [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560
> > [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0
> > [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118
> > [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670
> > [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130
> > [ 566.531615] [<00820dfe>]
> > blk_mq_sched_dispatch_requests+0x156/0x1a0
> > [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160
> > [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218
> > [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0
> > [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8
> > [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80
> > [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8
> > [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500
> > [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710
> > [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0
> > [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40
> > [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0
> > [ 566.531815] 1 lock held by bsg_api_test/3104:
> > [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at:
> > hctx_lock+0x30/0x118
> >
> > And then it dies completely:
> >
> > [ 566.531854] Unable to handle kernel pointer dereference in virtual
> > kernel address space
> > [ 566.531861] Failing address: TEID: 0483
> > [ 566.531867] Fault in home space mode while using kernel ASCE.
> > [ 566.531885] AS:013ec007 R3:effc8007 S:effce000
> > P:013d
> > [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [ 566.531938] Modules linked in: ...
> > [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
> >4.19.0-rc6-bb-next+ #1
> > [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR)
> > [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c
> > (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp])
> > [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3
> > PM:0 RI:0 EA:3
> > [ 566.532077] Krnl GPRS: 1000 bfb84178
> > 0001 8004
> > [ 566.532082]1000 a6625108
> > 000
Re: Looking for some help understanding error handling
On 10/22/18 10:17 AM, John Garry wrote: On 19/10/2018 17:46, chris.mo...@microchip.com wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org On Behalf Of John Garry Sent: Friday, October 19, 2018 2:19 AM To: Chris Moore - C33997 ; h...@suse.de; linux-scsi@vger.kernel.org; Jason Yan Subject: Re: Looking for some help understanding error handling On 05/10/2018 16:51, chris.mo...@microchip.com wrote: Thanks Hannes, After some pointers from Shane Seymour I found that the FC and SRP transport layers have a devloss timer, so that when a device disappears they hold on to the target information for a time waiting to see if it comes back. The SAS transport layer doesn't have that feature. The options for me then would be to modify scsi_transport_sas.c to implement the devloss timeout, or to put that functionality into my LLDD. I'm willing to put the work into the SAS transport and libsas, but I suspect there's not a universal need for it. And since my LLDD is for internal use at our company and won't be upstreamed, I'll probably just do the work there. If anyone feels that this is a feature that more people would want then I'll look into doing that. Hello, This feature sounds interesting for libsas. I however have a question on feasibility of devloss here (note: I'm not familiar with the concept/realization for other standards): if a device is deattached and re-attached, how can we confirm the same device? For SAS device it's ok as a disk has the WWN, but what about SATA? Thanks, John Would the serial number work? I haven't worked a lot with SATA drives, but ATA8-ACS says the IDENTIFY DEVICE response must contain a unique serial number. I guess in principle it would be possible. The issue is that libsas does not deal with topics like querying disks. It just deals with SAS layers below application layer, like link+port managament. The underlying idea of the devloss mechanism is that the driver maintains a _stable_ relationship between transport endpoints (eg FC remote ports or SAS rports/rphy) and the target devices in the SCSI subsystem. _And_ it is assumed that the LUN enumeration within the target devices / endpoints remain stable during disconnect. If these restrictions are met then the driver just has to reconnect the rport (of which he has the identification anyway) to the matching SCSI target device. Of course, if we can't identify the rport properly (as would be the case with SATA devices) we'll have to check if this mechanism can be used at all. (But for STP devices you probably can use the port index, hoping that that won't change ...) Cheers, Hannes
[GIT PULL] pcmcia odd fixes for v4.20-rc1
Linus, please pull the following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) which are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next up to 95691e3eddc41da2d1cd3cca51fecdfb46bd85bc: pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges (2018-10-01 12:17:03 +0200) These are just a few odd fixes and improvements to the PCMCIA core and to a few PCMCIA device drivers. Thanks, Dominik Colin Ian King (1): pcmcia: remove KERN_INFO level from debug message Jia-Ju Bai (2): char: pcmcia: cm4000_cs: Replace mdelay with usleep_range in set_protocol pcmcia: pcmcia_resource: Replace mdelay() with msleep() Maciej S. Szmigiero (1): pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges Vaishali Thakkar (1): pcmcia: Use module_pcmcia_driver for scsi drivers Zhouyang Jia (1): pcmcia: add error handling for pcmcia_enable_device in qlogic_stub drivers/char/pcmcia/cm4000_cs.c| 4 ++-- drivers/char/pcmcia/cm4040_cs.c| 2 +- drivers/pcmcia/pcmcia_resource.c | 4 ++-- drivers/pcmcia/ricoh.h | 35 +++ drivers/pcmcia/yenta_socket.c | 3 ++- drivers/scsi/pcmcia/aha152x_stub.c | 14 +- drivers/scsi/pcmcia/nsp_cs.c | 15 +-- drivers/scsi/pcmcia/nsp_cs.h | 4 drivers/scsi/pcmcia/qlogic_stub.c | 19 ++- drivers/scsi/pcmcia/sym53c500_cs.c | 16 +--- 10 files changed, 51 insertions(+), 65 deletions(-) signature.asc Description: PGP signature
Re: [PATCH] bsg: convert to use blk-mq
On 10/22/18 4:03 AM, Benjamin Block wrote:
> On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
>> On 10/19/18 9:01 AM, Benjamin Block wrote:
>>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
On 10/17/18 9:55 AM, Benjamin Block wrote:
> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
>> Requires a few changes to the FC transport class as well.
>>
>> Cc: Johannes Thumshirn
>> Cc: Benjamin Block
>> Cc: linux-scsi@vger.kernel.org
>> Signed-off-by: Jens Axboe
>> ---
>> block/bsg-lib.c | 102 +--
>> drivers/scsi/scsi_transport_fc.c | 61 ++
>> 2 files changed, 91 insertions(+), 72 deletions(-)
>>
>>
>> but that's not going to apply cleanly... Can you just try and run my
>> mq-conversions branch? That has everything, and it also has that
>> alloc failure fixed.
>>
>> git://git.kernel.dk/linux-block mq-conversions
>>
>
> Ok so, that gets past the stage where we initialize the queues. Simple
> SCSI-I/O also seems to work, that is for example an INQUIRY(10), but
> transport commands that get passed to the driver break. Tried to send
> a FibreChannel GPN_FT (remote port discovery).
>
> As the BSG interface goes. This is a bidirectional command, that has
> both a buffer for the request and for the reply. AFAIR BSG will create a
> struct request for each of them. Protocol is BSG_PROTOCOL_SCSI,
> Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be
> transparent till we get into the driver.
>
> First got this:
>
> [ 566.531100] BUG: sleeping function called from invalid context at
> mm/slab.h:421
> [ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name:
> bsg_api_test
> [ 566.531460] 1 lock held by bsg_api_test/3104:
> [ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at:
> hctx_lock+0x30/0x118
> [ 566.531498] Preemption disabled at:
> [ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218
> [ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
> 4.19.0-rc6-bb-next+ #1
> [ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR)
> [ 566.531533] Call Trace:
> [ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8)
> [ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8
> [ 566.531565] [<00196410>] ___might_sleep+0x280/0x298
> [ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560
> [ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0
> [ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118
> [ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670
> [ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130
> [ 566.531615] [<00820dfe>]
> blk_mq_sched_dispatch_requests+0x156/0x1a0
> [ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160
> [ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218
> [ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0
> [ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8
> [ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80
> [ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8
> [ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500
> [ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710
> [ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0
> [ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40
> [ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0
> [ 566.531815] 1 lock held by bsg_api_test/3104:
> [ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at:
> hctx_lock+0x30/0x118
>
> And then it dies completely:
>
> [ 566.531854] Unable to handle kernel pointer dereference in virtual kernel
> address space
> [ 566.531861] Failing address: TEID: 0483
> [ 566.531867] Fault in home space mode while using kernel ASCE.
> [ 566.531885] AS:013ec007 R3:effc8007 S:effce000
> P:013d
> [ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 566.531938] Modules linked in: ...
> [ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
> 4.19.0-rc6-bb-next+ #1
> [ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR)
> [ 566.532051] Krnl PSW : d16c67b2 e4a74b5c
> (zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp])
> [ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0
> RI:0 EA:3
> [ 566.532077] Krnl GPRS: 1000 bfb84178 0001
> 8004
> [ 566.532082]1000 a6625108
> 0001
> [ 566.532086]bfb870e8 b6276930
> bb3a6fc8
> [ 566.532091]b6276800 03ff80306228 03ff802fc048
> a7313830
> [ 566.532104] Krnl Code: 03ff802fc090: a7740004
Re: [PATCH] bsg: convert to use blk-mq
On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote:
> On 10/19/18 9:01 AM, Benjamin Block wrote:
> > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote:
> >> On 10/17/18 9:55 AM, Benjamin Block wrote:
> >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote:
> Requires a few changes to the FC transport class as well.
>
> Cc: Johannes Thumshirn
> Cc: Benjamin Block
> Cc: linux-scsi@vger.kernel.org
> Signed-off-by: Jens Axboe
> ---
> block/bsg-lib.c | 102 +--
> drivers/scsi/scsi_transport_fc.c | 61 ++
> 2 files changed, 91 insertions(+), 72 deletions(-)
>
>
> but that's not going to apply cleanly... Can you just try and run my
> mq-conversions branch? That has everything, and it also has that
> alloc failure fixed.
>
> git://git.kernel.dk/linux-block mq-conversions
>
Ok so, that gets past the stage where we initialize the queues. Simple
SCSI-I/O also seems to work, that is for example an INQUIRY(10), but
transport commands that get passed to the driver break. Tried to send
a FibreChannel GPN_FT (remote port discovery).
As the BSG interface goes. This is a bidirectional command, that has
both a buffer for the request and for the reply. AFAIR BSG will create a
struct request for each of them. Protocol is BSG_PROTOCOL_SCSI,
Subprotocol BSG_SUB_PROTOCOL_SCSI_TRANSPORT. The rest should be
transparent till we get into the driver.
First got this:
[ 566.531100] BUG: sleeping function called from invalid context at
mm/slab.h:421
[ 566.531452] in_atomic(): 1, irqs_disabled(): 0, pid: 3104, name: bsg_api_test
[ 566.531460] 1 lock held by bsg_api_test/3104:
[ 566.531466] #0: cb4b58e8 (rcu_read_lock){}, at:
hctx_lock+0x30/0x118
[ 566.531498] Preemption disabled at:
[ 566.531503] [<008175d0>] __blk_mq_delay_run_hw_queue+0x50/0x218
[ 566.531519] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
4.19.0-rc6-bb-next+ #1
[ 566.531527] Hardware name: IBM 3906 M03 704 (LPAR)
[ 566.531533] Call Trace:
[ 566.531544] ([<001167fa>] show_stack+0x8a/0xd8)
[ 566.531555] [<00bcc6d2>] dump_stack+0x9a/0xd8
[ 566.531565] [<00196410>] ___might_sleep+0x280/0x298
[ 566.531576] [<003e528c>] __kmalloc+0xbc/0x560
[ 566.531584] [<0083186a>] bsg_map_buffer+0x5a/0xb0
[ 566.531591] [<00831948>] bsg_queue_rq+0x88/0x118
[ 566.531599] [<0081ab56>] blk_mq_dispatch_rq_list+0x37e/0x670
[ 566.531607] [<0082050e>] blk_mq_do_dispatch_sched+0x11e/0x130
[ 566.531615] [<00820dfe>] blk_mq_sched_dispatch_requests+0x156/0x1a0
[ 566.531622] [<00817564>] __blk_mq_run_hw_queue+0x144/0x160
[ 566.531630] [<00817614>] __blk_mq_delay_run_hw_queue+0x94/0x218
[ 566.531638] [<008178b2>] blk_mq_run_hw_queue+0xda/0xf0
[ 566.531645] [<008211d8>] blk_mq_sched_insert_request+0x1a8/0x1e8
[ 566.531653] [<00811ee2>] blk_execute_rq_nowait+0x72/0x80
[ 566.531660] [<00811f66>] blk_execute_rq+0x76/0xb8
[ 566.531778] [<00830d0e>] bsg_ioctl+0x426/0x500
[ 566.531787] [<00440cb4>] do_vfs_ioctl+0x68c/0x710
[ 566.531794] [<00440dac>] ksys_ioctl+0x74/0xa0
[ 566.531801] [<00440e0a>] sys_ioctl+0x32/0x40
[ 566.531808] [<00bf1dd0>] system_call+0xd8/0x2d0
[ 566.531815] 1 lock held by bsg_api_test/3104:
[ 566.531821] #0: cb4b58e8 (rcu_read_lock){}, at:
hctx_lock+0x30/0x118
And then it dies completely:
[ 566.531854] Unable to handle kernel pointer dereference in virtual kernel
address space
[ 566.531861] Failing address: TEID: 0483
[ 566.531867] Fault in home space mode while using kernel ASCE.
[ 566.531885] AS:013ec007 R3:effc8007 S:effce000
P:013d
[ 566.531927] Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 566.531938] Modules linked in: ...
[ 566.532042] CPU: 3 PID: 3104 Comm: bsg_api_test Tainted: GW
4.19.0-rc6-bb-next+ #1
[ 566.532047] Hardware name: IBM 3906 M03 704 (LPAR)
[ 566.532051] Krnl PSW : d16c67b2 e4a74b5c
(zfcp_fc_exec_bsg_job+0x116/0x2c0 [zfcp])
[ 566.532071]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0
RI:0 EA:3
[ 566.532077] Krnl GPRS: 1000 bfb84178 0001
8004
[ 566.532082]1000 a6625108
0001
[ 566.532086]bfb870e8 b6276930
bb3a6fc8
[ 566.532091]b6276800 03ff80306228 03ff802fc048
a7313830
[ 566.532104] Krnl Code: 03ff802fc090: a7740004brc
7,3ff802fc098
[ 566.532104]03ff802fc094: a7f4002ebrc
15,3ff802fc0f0
[ 566.532104] #03ff802fc098: e310a034lg
%r1,48(%r10)
Re: [PATCH] bsg: convert to use blk-mq
On 10/19/18 9:57 AM, Benjamin Block wrote: > On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: >> On 10/19/18 9:01 AM, Benjamin Block wrote: >>> On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: On 10/17/18 9:55 AM, Benjamin Block wrote: > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: >> Requires a few changes to the FC transport class as well. >> >> Cc: Johannes Thumshirn >> Cc: Benjamin Block >> Cc: linux-scsi@vger.kernel.org >> Signed-off-by: Jens Axboe >> --- >> block/bsg-lib.c | 102 +-- >> drivers/scsi/scsi_transport_fc.c | 61 ++ >> 2 files changed, 91 insertions(+), 72 deletions(-) >> > > Hey Jens, > > I haven't had time to look into this in any deep way - but I did plan to > -, but just to see whether it starts and runs some I/O I tried giving it > a spin and came up with nothing (see line 3 and 5): I'm an idiot, can you try this on top? diff --git a/block/bsg-lib.c b/block/bsg-lib.c index 1aa0ed3fc339..95e12b635225 100644 --- a/block/bsg-lib.c +++ b/block/bsg-lib.c @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device *dev, const char *name, int ret = -ENOMEM; set = kzalloc(sizeof(*set), GFP_KERNEL); - if (set) + if (!set) return ERR_PTR(-ENOMEM); set->ops = &bsg_mq_ops; >>> >>> Well, yes, that would be wrong. But it still doesn't fly (s390x stack >>> trace): >>> >>> [ 36.271953] scsi host0: scsi_eh_0: sleeping >>> [ 36.272571] scsi host0: zfcp >>> [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 >>> blk_queue_rq_timed_out+0x44/0x60 >>> [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath >>> [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW >>>4.19.0-rc8-bb-next+ #1 >>> [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) >>> [ 36.299101] Krnl PSW : 0704e0018000 00ced494 >>> (blk_queue_rq_timed_out+0x44/0x60) >>> [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 >>> PM:0 RI:0 EA:3 >>> [ 36.299259] Krnl GPRS: 015cee60 >>> a0ce0180 0300 >>> [ 36.299304]0300 00ced486 >>> a5738000 03ff8069eba0 >>> [ 36.299349]a11ec6a8 a0ce >>> a11ec400 03ff805ee438 >>> [ 36.299394]a0ce 03ff805f6b00 >>> 00ced486 a28af0b0 >>> [ 36.299460] Krnl Code: 00ced486: e310c182ltg >>> %r1,384(%r12) >>> 00ced48c: a7840004brc >>> 8,ced494 >>> #00ced490: a7f40001brc >>> 15,ced492 >>> >00ced494: 4120c150la >>> %r2,336(%r12) >>> 00ced498: c0e5ffc76290brasl >>> %r14,5d99b8 >>> 00ced49e: e3b0c1500024stg >>> %r11,336(%r12) >>> 00ced4a4: ebbff0a4lmg >>> %r11,%r15,160(%r15) >>> 00ced4aa: 07febcr >>> 15,%r14 >>> [ 36.299879] Call Trace: >>> [ 36.299922] ([] 0xa11ec6a8) >>> [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 >>> [scsi_transport_fc] >>> [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 >>> [ 36.300075] [<00f0b592>] >>> attribute_container_add_device+0x182/0x1d0 >>> [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 >>> [scsi_mod] >>> [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 >>> [scsi_mod] >>> [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 >>> [zfcp] >>> [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 >>> [zfcp] >>> [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] >>> [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 >>> [ 36.300527] [<00f8b374>] >>> online_store_recog_and_online+0x204/0x230 >>> [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 >>> [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 >>> [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 >>> [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 >>> [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 >>> [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 >>> [ 36.300843] 5 locks held by systemd-udevd/856: >>> [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: >>> vfs_write+0xd6/0x238 >>> [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: >>> kernfs_fop_write+0
Re: [PATCH -next] mvsas: Remove set but not used variable 'id'
On 21/10/2018 10:50, YueHaibing wrote:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/mvsas/mv_sas.c: In function 'mvs_work_queue':
drivers/scsi/mvsas/mv_sas.c:1909:31: warning:
variable 'id' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
20b09c2992fe ("[SCSI] mvsas: add support for 94xx; layout change; bug fixes")
Signed-off-by: YueHaibing
Reviewed-by: John Garry
---
drivers/scsi/mvsas/mv_sas.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index 3df1428..ab50798 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -1906,8 +1906,6 @@ static void mvs_work_queue(struct work_struct *work)
if (phy->phy_event & PHY_PLUG_OUT) {
u32 tmp;
- struct sas_identify_frame *id;
- id = (struct sas_identify_frame *)phy->frame_rcvd;
It would have been worth leaving a newline to avoid a possible
checkpatch warning.
tmp = MVS_CHIP_DISP->read_phy_ctl(mvi, phy_no);
phy->phy_event &= ~PHY_PLUG_OUT;
if (!(tmp & PHY_READY_MASK)) {
.
Re: Looking for some help understanding error handling
On 19/10/2018 17:46, chris.mo...@microchip.com wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org On Behalf Of John Garry Sent: Friday, October 19, 2018 2:19 AM To: Chris Moore - C33997 ; h...@suse.de; linux-scsi@vger.kernel.org; Jason Yan Subject: Re: Looking for some help understanding error handling On 05/10/2018 16:51, chris.mo...@microchip.com wrote: Thanks Hannes, After some pointers from Shane Seymour I found that the FC and SRP transport layers have a devloss timer, so that when a device disappears they hold on to the target information for a time waiting to see if it comes back. The SAS transport layer doesn't have that feature. The options for me then would be to modify scsi_transport_sas.c to implement the devloss timeout, or to put that functionality into my LLDD. I'm willing to put the work into the SAS transport and libsas, but I suspect there's not a universal need for it. And since my LLDD is for internal use at our company and won't be upstreamed, I'll probably just do the work there. If anyone feels that this is a feature that more people would want then I'll look into doing that. Hello, This feature sounds interesting for libsas. I however have a question on feasibility of devloss here (note: I'm not familiar with the concept/realization for other standards): if a device is deattached and re-attached, how can we confirm the same device? For SAS device it's ok as a disk has the WWN, but what about SATA? Thanks, John Would the serial number work? I haven't worked a lot with SATA drives, but ATA8-ACS says the IDENTIFY DEVICE response must contain a unique serial number. I guess in principle it would be possible. The issue is that libsas does not deal with topics like querying disks. It just deals with SAS layers below application layer, like link+port managament. Thanks, John
Re: [PATCH] scsi: lpfc: Uninitialized variable in lpfc_debugfs_nodelist_data()
On Mon, Oct 22, 2018 at 08:25:49AM +0100, James Bottomley wrote:
> On Mon, 2018-10-22 at 09:50 +0300, Dan Carpenter wrote:
> > There was a merge problem and we accidentally removed the "nrport"
> > initialization.
> >
> > Fixes: 77c5bf5647b5 ("Merge branch 'misc' into for-next")
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/scsi/lpfc/lpfc_debugfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c
> > b/drivers/scsi/lpfc/lpfc_debugfs.c
> > index c6912394b56d..0c8005bb0f53 100644
> > --- a/drivers/scsi/lpfc/lpfc_debugfs.c
> > +++ b/drivers/scsi/lpfc/lpfc_debugfs.c
> > @@ -550,7 +550,7 @@ lpfc_debugfs_nodelist_data(struct lpfc_vport
> > *vport, char *buf, int size)
> > struct lpfc_nodelist *ndlp;
> > unsigned char *statep;
> > struct nvme_fc_local_port *localport;
> > - struct nvme_fc_remote_port *nrport;
> > + struct nvme_fc_remote_port *nrport = NULL;
>
> Really? that's not the way I did the merge in my for-next:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git/commit/?h=for-next&id=1f86cc958e2a60cef07546b15bdce90713a05e80
>
> 77c5bf5647b5 looks to be the orphaned residue of a failed merge ... how
> did you find it because it's not in any of the public branches?
It was in Friday's linux-next. Anyway, so long as it was fixed now.
regards,
dan carpenter
Re: [PATCH] scsi: lpfc: Uninitialized variable in lpfc_debugfs_nodelist_data()
On Mon, 2018-10-22 at 09:50 +0300, Dan Carpenter wrote:
> There was a merge problem and we accidentally removed the "nrport"
> initialization.
>
> Fixes: 77c5bf5647b5 ("Merge branch 'misc' into for-next")
> Signed-off-by: Dan Carpenter
> ---
> drivers/scsi/lpfc/lpfc_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c
> b/drivers/scsi/lpfc/lpfc_debugfs.c
> index c6912394b56d..0c8005bb0f53 100644
> --- a/drivers/scsi/lpfc/lpfc_debugfs.c
> +++ b/drivers/scsi/lpfc/lpfc_debugfs.c
> @@ -550,7 +550,7 @@ lpfc_debugfs_nodelist_data(struct lpfc_vport
> *vport, char *buf, int size)
> struct lpfc_nodelist *ndlp;
> unsigned char *statep;
> struct nvme_fc_local_port *localport;
> - struct nvme_fc_remote_port *nrport;
> + struct nvme_fc_remote_port *nrport = NULL;
Really? that's not the way I did the merge in my for-next:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git/commit/?h=for-next&id=1f86cc958e2a60cef07546b15bdce90713a05e80
77c5bf5647b5 looks to be the orphaned residue of a failed merge ... how
did you find it because it's not in any of the public branches?
James
