- 30 Mar, 2016 2 commits
-
-
Bart Van Assche authored
While retesting the SRP initiator I ran the command "rmmod mlx4_ib" while I/O was in progress. That command triggers SCSI device removal indirectly. Avoid that this action triggers the following deadlock: ================================= [ INFO: inconsistent lock state ] 4.6.0-rc0-dbg+ #2 Tainted: G O --------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. multipathd/484 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&pg->lock)->rlock){+.?...}, at: [<ffffffffa04f50a2>] alua_bus_detach+0x52/0xa0 [scsi_dh_alua] {IN-SOFTIRQ-W} state was registered at: [<ffffffff810a64a9>] __lock_acquire+0x7e9/0x1ad0 [<ffffffff810a7fd0>] lock_acquire+0x60/0x80 [<ffffffff8159910e>] _raw_spin_lock_irqsave+0x3e/0x60 [<ffffffffa04f5131>] alua_rtpg_queue+0x41/0x1d0 [scsi_dh_alua] [<ffffffffa04f5531>] alua_check+0xe1/0x220 [scsi_dh_alua] [<ffffffffa04f5709>] alua_check_sense+0x99/0xb0 [scsi_dh_alua] [<ffffffff813f0d01>] scsi_check_sense+0x71/0x3f0 [<ffffffff813f2f8b>] scsi_decide_disposition+0x18b/0x1d0 [<ffffffff813f6e52>] scsi_softirq_done+0x52/0x140 [<ffffffff812a26f2>] blk_done_softirq+0x52/0x90 [<ffffffff8105bc1f>] __do_softirq+0x10f/0x230 [<ffffffff8105bec8>] irq_exit+0xa8/0xb0 [<ffffffff8101a675>] do_IRQ+0x65/0x110 [<ffffffff8159a2c9>] ret_from_intr+0x0/0x19 [<ffffffff811732f1>] kmem_cache_alloc+0x151/0x190 [<ffffffff8118e534>] create_object+0x34/0x2d0 [<ffffffff8158eaa6>] kmemleak_alloc_percpu+0x56/0xd0 [<ffffffff8113ab0d>] pcpu_alloc+0x38d/0x660 [<ffffffff8113aded>] __alloc_percpu_gfp+0xd/0x10 [<ffffffff812e56a5>] __percpu_counter_init+0x55/0xb0 [<ffffffff812b4989>] blkg_alloc+0x79/0x230 [<ffffffff812b6756>] blkcg_init_queue+0x26/0x1d0 [<ffffffff81297eed>] blk_alloc_queue_node+0x27d/0x2e0 [<ffffffffa017766c>] dm_create+0x20c/0x570 [dm_mod] [<ffffffffa017e356>] dev_create+0x56/0x2c0 [dm_mod] [<ffffffffa017dcae>] ctl_ioctl+0x26e/0x520 [dm_mod] [<ffffffffa017df6e>] dm_ctl_ioctl+0xe/0x20 [dm_mod] [<ffffffff811aa8ee>] do_vfs_ioctl+0x8e/0x660 [<ffffffff811aaefc>] SyS_ioctl+0x3c/0x70 [<ffffffff81599929>] entry_SYSCALL_64_fastpath+0x1c/0xac irq event stamp: 4290931 hardirqs last enabled at (4290931): [ 1662.892772] [<ffffffff81599341>] _raw_spin_unlock_irqrestore+0x31/0x50 hardirqs last disabled at (4290930): [<ffffffff815990e7>] _raw_spin_lock_irqsave+0x17/0x60 softirqs last enabled at (4290774): [<ffffffff8105bcdb>] __do_softirq+0x1cb/0x230 softirqs last disabled at (4289831): [<ffffffff8105bec8>] irq_exit+0xa8/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&pg->lock)->rlock); <Interrupt> lock(&(&pg->lock)->rlock); *** DEADLOCK *** 2 locks held by multipathd/484: #0: (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811d1cc3>] __blkdev_put+0x33/0x360 #1: (sd_ref_mutex){+.+...}, at: [<ffffffff81400afc>] scsi_disk_put+0x1c/0x40 stack backtrace: CPU: 6 PID: 484 Comm: multipathd Tainted: G O 4.6.0-rc0-dbg+ #2 Call Trace: [<ffffffff812bd115>] dump_stack+0x67/0x92 [<ffffffff810a5175>] print_usage_bug+0x215/0x240 [<ffffffff810a56ea>] mark_lock+0x54a/0x610 [<ffffffff810a6505>] __lock_acquire+0x845/0x1ad0 [<ffffffff810a7fd0>] lock_acquire+0x60/0x80 [<ffffffff81598f23>] _raw_spin_lock+0x33/0x50 [<ffffffffa04f50a2>] alua_bus_detach+0x52/0xa0 [scsi_dh_alua] [<ffffffff813ff6f7>] scsi_dh_release_device+0x17/0x50 [<ffffffff813fb8da>] scsi_device_dev_release_usercontext+0x2a/0x120 [<ffffffff810701f0>] execute_in_process_context+0x80/0x90 [<ffffffff813fb8a7>] scsi_device_dev_release+0x17/0x20 [<ffffffff813c8cfd>] device_release+0x2d/0x90 [<ffffffff812bfa8a>] kobject_release+0x7a/0x190 [<ffffffff812bf946>] kobject_put+0x26/0x50 [<ffffffff813c8ee2>] put_device+0x12/0x20 [<ffffffff813edc86>] scsi_device_put+0x26/0x30 [<ffffffff81400b0d>] scsi_disk_put+0x2d/0x40 [<ffffffff81400b68>] sd_release+0x48/0xb0 [<ffffffff811d1f2e>] __blkdev_put+0x29e/0x360 [<ffffffff811d24b9>] blkdev_put+0x49/0x170 [<ffffffff811d2600>] blkdev_close+0x20/0x30 [<ffffffff81198f48>] __fput+0xe8/0x1f0 [<ffffffff81199089>] ____fput+0x9/0x10 [<ffffffff81075d9e>] task_work_run+0x6e/0xa0 [<ffffffff81001119>] exit_to_usermode_loop+0xa9/0xb0 [<ffffffff81001590>] syscall_return_slowpath+0xb0/0xc0 [<ffffffff815999b7>] entry_SYSCALL_64_fastpath+0xaa/0xac Fixes: cb0a168c (scsi_dh_alua: update 'access_state' field) Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Reviewed-by:
Hannes Reinicke <hare@suse.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ewan Milne <emilne@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Bart Van Assche authored
Avoid that building with W=1 causes gcc to report warnings about symbols that have not been declared. Cc: Hannes Reinecke <hare@suse.de> Signed-off-by:
-
- 29 Mar, 2016 2 commits
-
-
Manoj N. Kumar authored
While profiling the cxlflash_queuecommand() path under a heavy load it was found that number of retries to find cmd_room was fairly high. There are two problems with the current back-off: a) It starts with a udelay of 0 b) It backs-off linearly Tried several approaches (a higher multiple 10*n, 100*n, as well as n^2, 2^n) and found that the exponential back-off(2^n) approach had the least overall cost. Cost as being defined as overall time spent waiting. The fix is to change the linear back-off to an exponential back-off. This solution also takes care of the problem with the initial delay (starts with 1 usec). Signed-off-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
-
Manoj N. Kumar authored
While running 'sg_reset -H' back to back the following exception was seen: [ 735.115695] Faulting instruction address: 0xd0000000098c0864 cpu 0x0: Vector: 300 (Data Access) at [c000000ffffafa80] pc: d0000000098c0864: cxlflash_async_err_irq+0x84/0x5c0 [cxlflash] lr: c00000000013aed0: handle_irq_event_percpu+0xa0/0x310 sp: c000000ffffafd00 msr: 9000000000009033 dar: 2010000 dsisr: 40000000 current = 0xc000000001510880 paca = 0xc00000000fb80000 softe: 0 irq_happened: 0x01 pid = 0, comm = swapper/0 Linux version 4.5.0-491-26f710d+ enter ? for help [c000000ffffafe10] c00000000013aed0 handle_irq_event_percpu+0xa0/0x310 [c000000ffffafed0] c00000000013b1a8 handle_irq_event+0x68/0xc0 [c000000ffffaff00] c0000000001404ec handle_fasteoi_irq+0xec/0x2a0 [c000000ffffaff30] c00000000013a084 generic_handle_irq+0x54/0x80 [c000000ffffaff60] c000000000011130 __do_irq+0x80/0x1d0 [c000000ffffaff90] c000000000024d40 call_do_irq+0x14/0x24 [c000000001573a20] c000000000011318 do_IRQ+0x98/0x140 [c000000001573a70] c000000000002594 hardware_interrupt_common+0x114/0x180 This exception is being hit because the async_err interrupt path performs an MMIO to read the interrupt status register. The MMIO region in this case is not available. Commit 6ded8b3c ("cxlflash: Unmap problem state area before detaching master context") re-ordered the sequence in which term_mc() and stop_afu() are called. This introduces a window for interrupts to come in with the problem space area unmapped, that did not exist previously. The fix is to separate the disabling of all AFU interrupts to a distinct function, term_intr() so that it is the first thing that is done in the tear down process. To keep the initialization process symmetric, separate the AFU interrupt setup also to a distinct function: init_intr(). Fixes: 6ded8b3c ("cxlflash: Unmap problem state area before detaching master context") Signed-off-by:
-
- 23 Mar, 2016 1 commit
-
-
Calvin Owens authored
In _base_make_ioc_operational(), we walk ioc->reply_queue_list and pull a pointer out of successive elements of ioc->reply_post[] for each entry in that list if RDPQ is enabled. Since the code pulls the pointer for the next iteration at the bottom of the loop, it triggers the a KASAN dump on the final iteration: BUG: KASAN: slab-out-of-bounds in _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] at addr ffff880754816ab0 Read of size 8 by task modprobe/305 <snip> Call Trace: [<ffffffff81dfc591>] dump_stack+0x4d/0x6c [<ffffffff814c9689>] print_trailer+0xf9/0x150 [<ffffffff814ceda4>] object_err+0x34/0x40 [<ffffffff814d1231>] kasan_report_error+0x221/0x530 [<ffffffff814d1673>] __asan_report_load8_noabort+0x43/0x50 [<ffffffffa0043637>] _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] [<ffffffffa0049a51>] mpt3sas_base_attach+0x1991/0x2120 [mpt3sas] [<ffffffffa0053c93>] _scsih_probe+0xeb3/0x16b0 [mpt3sas] [<ffffffff81ebd047>] local_pci_probe+0xc7/0x170 [<ffffffff81ebf2cf>] pci_device_probe+0x20f/0x290 [<ffffffff820d50cd>] really_probe+0x17d/0x600 [<ffffffff820d56a3>] __driver_attach+0x153/0x190 [<ffffffff820cffac>] bus_for_each_dev+0x11c/0x1a0 [<ffffffff820d421d>] driver_attach+0x3d/0x50 [<ffffffff820d378a>] bus_add_driver+0x44a/0x5f0 [<ffffffff820d666c>] driver_register+0x18c/0x3b0 [<ffffffff81ebcb76>] __pci_register_driver+0x156/0x200 [<ffffffffa00c8135>] _mpt3sas_init+0x135/0x1000 [mpt3sas] [<ffffffff81000423>] do_one_initcall+0x113/0x2b0 [<ffffffff813caa5a>] do_init_module+0x1d0/0x4d8 [<ffffffff81273909>] load_module+0x6729/0x8dc0 [<ffffffff81276123>] SYSC_init_module+0x183/0x1a0 [<ffffffff8127625e>] SyS_init_module+0xe/0x10 [<ffffffff828fe7d7>] entry_SYSCALL_64_fastpath+0x12/0x6a Fix this by pulling the value at the beginning of the loop. Signed-off-by:Calvin Owens <calvinowens@fb.com> Reviewed-by:
Jens Axboe <axboe@fb.com> Acked-by:
Chaitra Basappa <chaitra.basappa@broadcom.com> Signed-off-by:
-
- 22 Mar, 2016 1 commit
-
-
Arnd Bergmann authored
gcc-6 warns about obviously wrong indentation for newly added code in aac_slave_configure(): drivers/scsi/aacraid/linit.c: In function 'aac_slave_configure': drivers/scsi/aacraid/linit.c:458:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] sdev->tagged_supported = 1; ^~~~ drivers/scsi/aacraid/linit.c:455:4: note: ...this 'else' clause, but it is not gcc is correct, and evidently this was meant to be within the curly braces that should have been there to start with. This patch adds them, which avoids the warning and makes it clear what was intended here. Nothing changes in behavior because in the 'if' block, the sdev->tagged_supported flag is known to be set already. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 6bf3b630 ("aacraid: SCSI blk tag support") Reviewed-by:
Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com> Signed-off-by:
-
- 18 Mar, 2016 7 commits
-
-
Hannes Reinecke authored
For fixed sense the information field is 32 bits, to we need to truncate the information field to avoid clobbering the sense code. Fixes: a1524f22 ("libata-eh: Set 'information' field for autosense") Cc: <stable@vger.kernel.org> #v4.1+ Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Reviewed-by:
-
Arnd Bergmann authored
A recent change to ufshcd introduced a call to utf16s_to_utf8s, a function that is provided by the NLS module, so we get a link error when that is not present: drivers/scsi/built-in.o: In function `ufshcd_read_string_desc': :(.text+0x124d0): undefined reference to `utf16s_to_utf8s' This adds a Kconfig 'select' statement to avoid the build error. Signed-off-by:
-
Arnd Bergmann authored
A bug in the gcc-6.0 prerelease version caused at least one driver (lpfc) to have excessive stack usage when dealing with wwn data, on the ARM architecture. lpfc_scsi.c: In function 'lpfc_find_next_oas_lun': lpfc_scsi.c:117:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=] I have reported this as a gcc regression in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232 However, using a better implementation of wwn_to_u64() not only helps with the particular gcc problem but also leads to better object code for any version or architecture. The kernel already provides get_unaligned_be64() and put_unaligned_be64() helper functions that provide an optimized implementation with the desired semantics. The lpfc_find_next_oas_lun() function in the example that grew from 1146 bytes to 5144 bytes when moving from gcc-5.3 to gcc-6.0 is now 804 bytes, as the optimized get_unaligned_be64() load can be done in three instructions. The stack usage is now down to 28 bytes from 128 bytes with gcc-5.3 before. Signed-off-by:
-
Maurizio Lombardi authored
This patch moves a printk() outside of the code section where interrupt are disabled. In some cases a flood of error messages may cause a kernel panic. It also removes one of the printk()s because the same error message was printed twice. [709686.317197] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 12 [709686.317200] CPU: 12 PID: 1963 Comm: systemd-journal Tainted: GF O-------------- 3.10.0-229.el7.x86_64 #1 [709686.317201] Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.6.030620151309 03/06/2015 [709686.317206] ffffffff8182b2e8 00000000392722ba ffff88046fcc5c48 ffffffff81603f36 [709686.317209] ffff88046fcc5cc8 ffffffff815fd7da 0000000000000010 ffff88046fcc5cd8 [709686.317211] ffff88046fcc5c78 00000000392722ba ffff88046fcc5c88 000000000000000c [709686.317212] Call Trace: [709686.317221] <NMI> [<ffffffff81603f36>] dump_stack+0x19/0x1b [709686.317223] [<ffffffff815fd7da>] panic+0xd8/0x1e7 [709686.317227] [<ffffffff8110a760>] ? watchdog_enable_all_cpus.part.2+0x40/0x40 [709686.317229] [<ffffffff8110a822>] watchdog_overflow_callback+0xc2/0xd0 [709686.317233] [<ffffffff8114c901>] __perf_event_overflow+0xa1/0x250 [709686.317235] [<ffffffff8114d404>] perf_event_overflow+0x14/0x20 [709686.317239] [<ffffffff810301fd>] intel_pmu_handle_irq+0x1fd/0x410 [709686.317242] [<ffffffff811908d1>] ? unmap_kernel_range_noflush+0x11/0x20 [709686.317246] [<ffffffff81373574>] ? ghes_copy_tofrom_phys+0x124/0x210 [709686.317249] [<ffffffff8160cfcb>] perf_event_nmi_handler+0x2b/0x50 [709686.317251] [<ffffffff8160c719>] nmi_handle.isra.0+0x69/0xb0 [709686.317252] [<ffffffff8160c830>] do_nmi+0xd0/0x340 [709686.317256] [<ffffffff8160bb71>] end_repeat_nmi+0x1e/0x2e [709686.317260] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317263] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317265] [<ffffffff812e24fd>] ? memcpy+0xd/0x110 [709686.317269] <<EOE>> [<ffffffff8132c297>] ? vgacon_scroll+0x2d7/0x330 [709686.317273] [<ffffffff813a086c>] scrup+0xfc/0x110 [709686.317275] [<ffffffff813a0920>] lf+0xa0/0xb0 [709686.317278] [<ffffffff813a1b32>] vt_console_print+0x2d2/0x420 [709686.317283] [<ffffffff8106f4a1>] call_console_drivers.constprop.15+0x91/0xf0 [709686.317287] [<ffffffff8107069f>] console_unlock+0x3bf/0x400 [709686.317291] [<ffffffff81070996>] vprintk_emit+0x2b6/0x530 [709686.317294] [<ffffffff815fd961>] printk_emit+0x44/0x5b [709686.317297] [<ffffffff81070d98>] devkmsg_writev+0x158/0x1d0 [709686.317303] [<ffffffff811c5ef9>] do_sync_readv_writev+0x79/0xd0 [709686.317307] [<ffffffff811c73ee>] do_readv_writev+0xce/0x260 [709686.317310] [<ffffffff811c8d18>] ? __sb_start_write+0x58/0x110 [709686.317314] [<ffffffff811c7615>] vfs_writev+0x35/0x60 [709686.317318] [<ffffffff811c776c>] SyS_writev+0x5c/0xd0 [709686.317322] [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Reviewed-by:
-
Arnd Bergmann authored
The qlt_check_reserve_free_req() function produces an incorrect warning when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req': drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used uninitialized in this function [-Werror=maybe-uninitialized] ql_dbg(ql_dbg_io, vha, 0x305a, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "qla_target(%d): There is no room in the request ring: vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d Req-Length=%d\n", ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vha->vp_idx, vha->req->ring_index, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized] The problem is that gcc fails to track the state of the condition across an annotated branch. This slightly rearranges the code to move the second if() block into the first one, to avoid the warning while retaining the behavior of the code. Signed-off-by:Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
Arnd Bergmann authored
gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl function: drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl': drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] kbuff_arr[i] = NULL; ^~~~~~~~~ drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not if (kbuff_arr[i]) ^~ The code is actually correct, as there is no downside in clearing a NULL pointer again. This clarifies the code and avoids the warning by adding extra curly braces. Signed-off-by:Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Arnd Bergmann authored
gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array() call in lpfc_online(), which clearly doesn't look right: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online': drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] lpfc_destroy_vport_work_array(phba, vports); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not if (vports != NULL) ^~ Looking at the patch that introduced this code, it's clear that the behavior is correct and the indentation is wrong. This fixes the indentation and adds curly braces around the previous if() block for clarity, as that is most likely what caused the code to be misindented in the first place. Signed-off-by:
Sebastian Herbszt <herbszt@gmx.de> Reviewed-by:
-
- 15 Mar, 2016 19 commits
-
-
Hannes Reinecke authored
There is no way to detect the scsi_target_id for any given SAS remote port, so add a new sysfs attribute 'scsi_target_id'. Signed-off-by:
-
Dan Carpenter authored
The pg_updated variable is support to be set to false at the start but it is uninitialized. Fixes: cb0a168c ('scsi_dh_alua: update 'access_state' field') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Yaniv Gardi authored
This change adds printouts of testbus and debug registers. Reviewed-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by:
-
Yaniv Gardi authored
This change enables the device ref clock before changing to HS mode and disables it if entered to PWM mode. Reviewed-by:
-
Yaniv Gardi authored
Some UFS devices (and may be host) have issues if LCC is enabled. So we are setting PA_Local_TX_LCC_Enable to 0 before link startup which will make sure that both host and device TX LCC are disabled once link startup is completed. Reviewed-by:
-
Yaniv Gardi authored
We put the UFS device in sleep state & UFS link in hibern8 state during runtime suspend. After this we put all the UFS rails in low power modes immediately but it seems some devices may still draw more than sleep current from UFS rails (especially from VCCQ rail) at-least for 500us. To avoid this situation, this change adds 2ms delay before putting these UFS rails in LPM mode. Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Yaniv Gardi authored
Currently when we try to put the link in off/disabled state during suspend, it seems link is not being kept in low power mode. This patch fixes the issue by putting the link in hibern8 first (so device also puts the link in low power mode) and then stop the host controller. Reviewed-by:
-
Yaniv Gardi authored
Optimal values of local UniPro parameters like PA_Hibern8Time & PA_TActivate can help reduce the hibern8 exit latency. If both host and device supports UniPro ver1.6 or later, these parameters will be automatically tuned during link startup itself. But if either host or device doesn't support UniPro ver 1.6 or later, we have to manually tune them. But to keep manual tuning logic simple, we will only do manual tuning if local unipro version doesn't support ver1.6 or later. Reviewed-by:
-
Yaniv Gardi authored
We are seeing that some devices are raising the urgent bkops exception events even when BKOPS status doesn't indicate performace impacted or critical. Handle these device by determining their urgent bkops status at runtime. Reviewed-by:
-
Yaniv Gardi authored
Query commands have 100ms timeout and it may timeout if they are issued in parallel to ongoing read/write SCSI commands, this change adds the retry (max: 10) in case command timeouts. Reviewed-by:
-
Yaniv Gardi authored
Some vendor's UFS device sends back to back NACs for the DL data frames causing the host controller to raise the DFES error status. Sometimes such UFS devices send back to back NAC without waiting for new retransmitted DL frame from the host and in such cases it might be possible the Host UniPro goes into bad state without raising the DFES error interrupt. If this happens then all the pending commands would timeout only after respective SW command (which is generally too large). This change workarounds such device behaviour like this: - As soon as SW sees the DL NAC error, it would schedule the error handler - Error handler would sleep for 50ms to see if there any fatal errors raised by UFS controller. - If there are fatal errors then SW does normal error recovery. - If there are no fatal errors then SW sends the NOP command to device to check if link is alive. - If NOP command times out, SW does normal error recovery - If NOP command succeed, skip the error handling. If DL NAC error is seen multiple times with some vendor's UFS devices then enable this quirk to initiate quick error recovery and also silence related error logs to reduce spamming of kernel logs. Reviewed-by: -
Yaniv Gardi authored
UFS driver's error handler forcefully tries to clear all the pending requests. For each pending request in the queue, it waits 1 sec for it to get cleared. If we have multiple requests in the queue then it's possible that we might end up waiting for those many seconds before resetting the host. But note that resetting host would any way clear all the pending requests from the hardware. Hence this change skips the forceful clear of the pending requests if we are anyway going to reset the host (for fatal errors). Reviewed-by:
-
Yaniv Gardi authored
Some UFS devices don't require VCCQ rail for device operations hence this change adds support to recognize such devices and remove vote for the unused VCCQ rail. Reviewed-by:
-
Yaniv Gardi authored
Currently we use the host quirks mechanism in order to handle both device and host controller quirks. In order to support various of UFS devices we should separate handling the device quirks from the host controller's. Reviewed-by:
Raviv Shvili <rshvili@codeaurora.org> Signed-off-by:
-
Yaniv Gardi authored
This change adds support to read device descriptor and string descriptor from a UFS device Reviewed-by:
-
Yaniv Gardi authored
Sometimes due to hw issues it takes some time to the host controller register to update. In order to verify the register has updated, a polling is done until its value is set. In addition the functions ufshcd_hba_stop() and ufshcd_wait_for_register() was updated with an additional input parameter, indicating the timeout between reads will be done by sleeping or spinning the cpu. Reviewed-by:
-
Yaniv Gardi authored
A race condition exists between request requeueing and scsi layer error handling: When UFS driver queuecommand returns a busy status for a request, it will be requeued and its tag will be freed and set to -1. At the same time it is possible that the request will timeout and scsi layer will start error handling for it. The scsi layer reuses the request and its tag to send error related commands to the device, however its tag is no longer valid. As this request was never really sent to the device, there is no point to start error handling with the device. Implement the scsi error handling timeout callback and bypass SCSI error handling for request that were not actually sent to the device. For such requests simply reset the block layer timer. Otherwise, let SCSI layer perform the usual error handling. Reviewed-by:
-
Yaniv Gardi authored
When control reaches to Linux UFS driver during UFS boot mode, UFS host controller interrupt status/enable registers may have left over settings. In order to avoid any spurious interrupts due to these left overs, it's important to clear these interrupt status/enable registers before enabling UFS interrupt handling. Reviewed-by:
-
Yaniv Gardi authored
Different platform may have different number of lanes for the UFS link. Add parameter to device tree specifying how many lanes should be configured for the UFS link. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 14 Mar, 2016 4 commits
-
-
Douglas Gilbert authored
One of the strange things that the original sg driver did was let the user provide both a data-out buffer (it followed the sg_header+cdb) _and_ specify a reply length greater than zero. What happened was that the user data-out buffer was copied into some kernel buffers and then the mid level was told a read type operation would take place with the data from the device overwriting the same kernel buffers. The user would then read those kernel buffers back into the user space. From what I can tell, the above action was broken by commit fad7f01e ("sg: set dxferp to NULL for READ with the older SG interface") in 2008 and syzkaller found that out recently. Make sure that a user space pointer is passed through when data follows the sg_header structure and command. Fix the abnormal case when a non-zero reply_len is also given. Fixes: fad7f01e Cc: <stable@vger.kernel.org> #v2.6.28+ Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
-
Vitaly Kuznetsov authored
Commit 3209f9d7 ("scsi: storvsc: Fix a bug in the handling of SRB status flags") filtered SRB_STATUS_AUTOSENSE_VALID out effectively making the (SRB_STATUS_ABORTED | SRB_STATUS_AUTOSENSE_VALID) case a dead code. The logic from this branch (e.g. storvsc_device_scan() call) is still required, fix the check. Cc: <stable@vger.kernel.org> #v4.4+ Fixes: 3209f9d7 ("scsi: storvsc: Fix a bug in the handling of SRB status flags") Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Maurizio Lombardi authored
In beiscsi_setup_boot_info(), the boot_kset pointer should be set to NULL in case of failure otherwise an invalid pointer dereference may occur later. Cc: <stable@vger.kernel.org> Signed-off-by:
Jitendra Bhivare <jitendra.bhivare@broadcom.com> Signed-off-by:
-
Martin K. Petersen authored
Commit 39773722 ("sd: Make discard granularity match logical block size when LBPRZ=1") accidentally set the granularity to one byte instead of one logical block on devices that provide deterministic zeroes after UNMAP. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Reviewed-by:
-
- 11 Mar, 2016 2 commits
-
-
Hannes Reinecke authored
The test for the existence vpd_pg83 is inverted. Fixes: 7e47976b ("scsi_sysfs: add 'is_bin_visible' callback") Signed-off-by:
-
Sumit Saxena authored
There are few MFI adapters which do not support MR_DCMD_PD_LIST_QUERY so if MFI adapters fail this DCMD, it should not be considered as FATAL and driver should not issue kill adapter and set per controller's instance variable- pd_list_not_supported so that same variable can be used inside functions- slave_alloc and slave_configure to allow firmware scan. Killing adapter because of DCMD failure when this DCMD is not supported causes driver's probe getting failed. This issue got introduced by commit 6d40afbc ("megaraid_sas: MFI IO timeout handling"). Killing adapter in case of this DCMD failure should be limited to Fusion adapters only. Per controller's instance variable allow_fw_scan is removed as pd_list_not_supported better reflect the purpose. Fixes: 6d40afbcSigned-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
- 10 Mar, 2016 1 commit
-
-
Lars-Peter Clausen authored
Calling synchronize_irq() right before free_irq() is quite useless. On one hand the IRQ can easily fire again before free_irq() is entered, on the other hand free_irq() itself calls synchronize_irq() internally (in a race condition free way), before any state associated with the IRQ is freed. Patch was generated using the following semantic patch: // <smpl> @@ expression irq; @@ -synchronize_irq(irq); free_irq(irq, ...); // </smpl> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
- 09 Mar, 2016 1 commit
-
-
Manoj N. Kumar authored
With the current value of cmd_per_lun at 16, the throughput over a single adapter is limited to around 150kIOPS. Increase the value of cmd_per_lun to 256 to improve throughput. With this change a single adapter is able to attain close to the maximum throughput (380kIOPS). Also change the number of RRQ entries that can be queued. Signed-off-by:
-
