[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]
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
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
> >
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
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:
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
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 = _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 (>mutex){+.+.}, at: >>>
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=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=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
[PATCH] scsi: lpfc: Uninitialized variable in lpfc_debugfs_nodelist_data()
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;
struct lpfc_nvme_rport *rport;
cnt = (LPFC_NODELIST_SIZE / LPFC_NODELIST_ENTRY_SIZE);
--
2.11.0
