[Bug 111441] iscsi fails to attach to targets
https://bugzilla.kernel.org/show_bug.cgi?id=111441 --- Comment #4 from Serguei Bezverkhi --- with kernel 4.4.0 lsscsi [0:0:44:0] enclosu CISCOUCS 240 0809 - [0:2:0:0]diskLSI MR9261-8i2.13 /dev/sda [0:2:1:0]diskLSI MR9261-8i2.13 /dev/sdb [3:0:0:2]type? vendor? model? rev? - [4:0:0:3]type? vendor? model? rev? - [5:0:0:1]type? vendor? model? rev? - [6:0:0:4]type? vendor? model? rev? - [7:0:0:0]type? vendor? model? rev? - [8:0:0:0]type? vendor? model? rev? - with kernel 3.10.0-327.4.4 lsscsi [0:0:44:0] enclosu CISCOUCS 240 0809 - [0:2:0:0]diskLSI MR9261-8i2.13 /dev/sda [0:2:1:0]diskLSI MR9261-8i2.13 /dev/sdb [3:0:0:2]diskLIO-ORG san-disk-2 4.0 /dev/sdc [4:0:0:3]diskLIO-ORG san-disk-3 4.0 /dev/sdd [5:0:0:1]diskLIO-ORG san-disk-1 4.0 /dev/sde [6:0:0:4]diskLIO-ORG san-disk-4 4.0 /dev/sdf -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 111441] iscsi fails to attach to targets
https://bugzilla.kernel.org/show_bug.cgi?id=111441 --- Comment #3 from Serguei Bezverkhi --- Additional tracebacks: [ 25.799382] WARNING: CPU: 18 PID: 1482 at block/genhd.c:626 add_disk+0x443/0x4a0() [ 25.799383] Modules linked in: iscsi_tcp libiscsi_tcp 8021q garp mrp rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod openvswitch bonding ib_srp scsi_transport_srp ib_ipoib nf_defrag_ipv6 rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad usnic_verbs ib_core xt_comment xt_multiport iptable_filter ib_addr iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 x86_pkg_temp_thermal nf_nat_ipv4 intel_powerclamp nf_nat coretemp kvm_intel nf_conntrack kvm iptable_mangle irqbypass crct10dif_pclmul crc32_pclmul nfsd aesni_intel lrw gf128mul glue_helper ablk_helper cryptd ses enclosure sb_edac sg auth_rpcgss edac_core iTCO_wdt ipmi_devintf iTCO_vendor_support nfs_acl lockd shpchp pcspkr lpc_ich ipmi_si ipmi_msghandler mfd_core wmi acpi_power_meter grace [ 25.799435] sunrpc br_netfilter bridge stp llc dm_multipath ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ixgbe(O) drm fnic i40e libfcoe igb megaraid_sas enic libfc crc32c_intel vxlan ip6_udp_tunnel udp_tunnel ptp scsi_transport_fc i2c_algo_bit dca i2c_core pps_core dm_mirror dm_region_hash dm_log dm_mod [ 25.799462] CPU: 18 PID: 1482 Comm: kworker/u82:3 Tainted: G O 4.4.0 #1 [ 25.799464] Hardware name: Cisco Systems Inc UCSC-C240-M3S/UCSC-C240-M3S, BIOS C240M3.2.0.8.0.071620152208 07/16/2015 [ 25.799470] Workqueue: events_unbound async_run_entry_fn [ 25.799473] 866f6387 885f9d34bcf8 81329090 [ 25.799476] 885f9d34bd30 810862c6 885e6c3a8800 [ 25.799478] 885e6c3a8880 885f9c59ea80 885e6c3a880c 885e6bc78000 [ 25.799481] Call Trace: [ 25.799492] [] dump_stack+0x44/0x64 [ 25.799496] [] warn_slowpath_common+0x86/0xc0 [ 25.799499] [] warn_slowpath_null+0x1a/0x20 [ 25.799502] [] add_disk+0x443/0x4a0 [ 25.799508] [] sd_probe_async+0x115/0x1d0 [sd_mod] [ 25.799511] [] async_run_entry_fn+0x4a/0x140 [ 25.799515] [] process_one_work+0x14c/0x3c0 [ 25.799517] [] worker_thread+0x114/0x470 [ 25.799520] [] ? rescuer_thread+0x310/0x310 [ 25.799524] [] kthread+0xd8/0xf0 [ 25.799527] [] ? kthread_park+0x60/0x60 [ 25.799532] [] ret_from_fork+0x3f/0x70 [ 25.799535] [] ? kthread_park+0x60/0x60 [ 25.799538] ---[ end trace 5d59079faf7d2510 ]--- [ 25.799568] sd 3:0:0:2: [sdc] Attached SCSI disk [ 25.808827] scsi 3:0:0:0: Unexpected response from lun 2 while scanning, scan aborted [ 25.810073] scsi host6: iSCSI Initiator over TCP/IP [ 25.811250] scsi 4:0:0:3: Direct-Access LIO-ORG san-disk-3 4.0 PQ: 0 ANSI: 5 [ 25.811776] sd 4:0:0:3: alua: supports implicit and explicit TPGS [ 25.811914] sd 4:0:0:3: [sdd] 9765625856 512-byte logical blocks: (5.00 TB/4.54 TiB) [ 25.811958] sd 4:0:0:3: alua: No target port descriptors found [ 25.811961] sd 4:0:0:3: alua: Attach failed (-22) [ 25.811964] sd 4:0:0:3: failed to add device handler: -22 [ 25.812001] sd 4:0:0:3: [sdd] Write Protect is off [ 25.812005] sd 4:0:0:3: [sdd] Mode Sense: 00 00 00 00 [ 25.812009] sd 4:0:0:3: [sdd] Asking for cache data failed [ 25.812011] sd 4:0:0:3: [sdd] Assuming drive cache: write through [ 25.815398] sd 4:0:0:3: [sdd] Attached SCSI disk [ 25.819131] ixgbe :04:00.1: SR-IOV enabled with 8 VFs [ 25.819134] ixgbe :04:00.1: configure port vlans to keep your VFs secure [ 25.824709] scsi 4:0:0:0: Unexpected response from lun 3 while scanning, scan aborted [ 25.832694] scsi 6:0:0:4: Direct-Access LIO-ORG san-disk-4 4.0 PQ: 0 ANSI: 5 [ 25.832921] scsi 5:0:0:1: Direct-Access LIO-ORG san-disk-1 4.0 PQ: 0 ANSI: 5 [ 25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS [ 25.833360] sd 6:0:0:4: alua: No target port descriptors found [ 25.833363] sd 6:0:0:4: alua: Attach failed (-22) [ 25.833365] sd 6:0:0:4: failed to add device handler: -22 [ 25.833394] sd 5:0:0:1: alua: supports implicit and explicit TPGS [ 25.851814] sd 6:0:0:4: [sde] 10742171648 512-byte logical blocks: (5.49 TB/5.00 TiB) [ 25.851820] sd 5:0:0:1: [sdf] 7812499389 512-byte logical blocks: (3.99 TB/3.63 TiB) [ 25.851821] sd 6:0:0:4: [sde] Write Protect is off [ 25.851823] sd 6:0:0:4: [sde] Mode Sense: 00 00 00 00 [ 25.851825] sd 6:0:0:4: [sde] Asking for cache data failed [ 25.851827] sd 6:0:0:4: [sde] Assuming drive cache: write through [ 25.851843] sd 5:0:0:1: alua: No target port descriptors found [ 25.851847] sd 5:0:0:1: alua: Attach failed (-22) [ 25.851849] sd 5:0:0:1: failed to add device handler: -22 [ 25.851946] sd 5:0:0:1: [sdf] Write Protect is off [ 25.851948] sd 5:0:0:1: [sdf] Mode Sense: 00 00 00 00 [ 25.851949] sd 5:0:0:1: [sdf] Asking for cache data failed [
[Bug 111441] iscsi fails to attach to targets
https://bugzilla.kernel.org/show_bug.cgi?id=111441 --- Comment #2 from Serguei Bezverkhi --- HI Mike, Thank you for looking into this issue. I reproduced this issue this using both mainline compiled kernel and the one posted by El Repo. I used both of these kernels with RHEL 7.2, both kernels showed exactly the same issue. When I rollback to the original kernel 3.10.0-327.4.4, I do not see the issue. As per your request attaching kernel config file. Please let me know if you need any additional info or if you want to take a look at the router, I can setup a webex meeting to show you the issue. Thank you Serguei Serguei Bezverkhi, TECHNICAL LEADER.SERVICES Global SP Services sbezv...@cisco.com Phone: +1 416 306 7312 Mobile: +1 514 234 7374 CCIE (R&S,SP,Sec) - #9527 Cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Mike Christie Sent: Thursday, January 28, 2016 8:53 PM To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org Subject: Re: [Bug 111441] New: iscsi fails to attach to targets On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=111441 > > Bug ID: 111441 >Summary: iscsi fails to attach to targets >Product: IO/Storage >Version: 2.5 > Kernel Version: 4.4.0-1 > Hardware: x86-64 > OS: Linux > Tree: Mainline > Status: NEW > 4.4.0-1.el7.elrepo.x86_64 #1 I have not seen this oops before. We saw similar ones around 5 or 6 years ago, but they were due to some sysfs or block or scsi issue (I cannot remember exacty) and fixed there. Is this a distro kernel or mainline. BZ says mainline, but the kernel name in bug looks like a red hat related one. Where did you get it? I do not hit this in 4.4 mainline. Send me your kernel .config, so I can make sure I have the same options. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- You are receiving this mail because: You are the assignee for the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 111441] iscsi fails to attach to targets
https://bugzilla.kernel.org/show_bug.cgi?id=111441 --- Comment #1 from Serguei Bezverkhi --- Created attachment 202201 --> https://bugzilla.kernel.org/attachment.cgi?id=202201&action=edit Kernel config -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] SCSI: usd ida for host number management
> "Lee" == Lee Duncan writes: Lee> Update the SCSI hosts module to use ida to manage its host_no index Lee> instead of an ATOMIC integer. This means that the SCSI host number Lee> will now be reclaimable. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] LIO/SCST Merger
Nicholas A. Bellinger wrote on 01/27/2016 10:36 PM:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> Last year, during the 2015 LSF/MM summit, it has been decided that the
>> LIO/SCST merger project should proceed by sending the functionality
>> upstream that is present in SCST but not yet in LIO. This will help to
>> reduce the workload of target driver maintainers that maintain a version
>> of their target driver for both LIO and SCST (QLogic FC and FCoE target
>> drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver,
>> RDMA SRP target driver, ...). My proposal is to organize a session
>> during which the following is discussed:
>> * Which patches are already upstream in the context of the LIO/SCST
>> merger project.
>> * About which patches there is agreement but that are not yet upstream.
>> * To discuss how to proceed from here and what to address first.
>
> No, just no. If you've not been able to articulate the specifics of
> what you're talking about to the list by now, it's never going to
> happen.
>
> You'll recall last year how things unfolded at LSF. You started
> comparing data structure TMR member names of no consequence to a larger
> LSF audience, and quickly tried to pivot into a discussion about adding
> hooks to LIO fabric drivers for your own out-of-tree nastiness.
>
> I really fail to see how that helps LIO or upstream. To repeat. I'll
> not allow SCST's out-of-tree legacy requirements to limit LIO's future
> in upstream, and if you or your employer is still trying to get
> enterprise distros to listen to that nonsense behind the scenes, then
> please stop wasting everybody's time.
>
> Bart, I really want to believe you and your employer have good
> intentions for LIO. However, being one of it's largest detractors in
> the past means that you have to really put your best foot forward on
> your interaction with the LIO community.
>
> However, your inability to ask questions before acting, refusing to
> answer to all feedback on reviews for changes of substance, and not
> following the expected patch review progress without repeatably leading
> yourself and others down the wrong path really makes me start to
> question your intentions, or at least your abilities as a kernel
> contributor.
>
> Also, you've not managed to merge any of the outstanding ib_srpt fixes
> from the last year, which brings us to a grad total of 6 small patches
> since the original merge of ib_srpt in Oct 2011.
>
> # git log --author=Bart --oneline -- drivers/infiniband/ulp/srpt/
> 19f5729 IB/srpt: Fix the RDMA completion handlers
> ba92999 target: Minimize SCSI header #include directives
> 2fe6e72 ib_srpt: Remove set-but-not-used variables
> 649ee05 target: Move task tag into struct se_cmd + support 64-bit tags
> afc1660 target: Remove first argument of target_{get,put}_sess_cmd()
> ab477c1 srp-target: Retry when QP creation fails with ENOMEM
>
> That's really a terrible record.
>
> So until you're able to demonstrate publicly to me and the LIO community
> that you do have good intentions, and not trying to rehash the same
> tired old nonsense and willful ignorance, please stop throwing out these
> generic topics as a branding exercise.
>
> There are much more interesting and important topics at LSF to discuss.
While I'm generally refraining from feeding trolls, don't you think that a
person who
has contributed you one of the major drivers and continues making such important
contributions (for free!) trying to bring (eventually, after how many years?)
LIO
reliability to something you can compare to SCST, deserves a little more
respect?
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/15] megaraid_sas: Updates for scsi-next
> "Sumit" == Sumit Saxena writes: Sumit, Applied to 4.6/scsi-queue. Please make sure you put patch revision and feedback comments under the --- separator so they don't become part of the commit message. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 111441] New: iscsi fails to attach to targets
I thought you could just reply to kernel bugzilla mails and it would automatically add your reply to the bz, but I got some errors. Ccing the bug reporter here, so I do not have to make an account and go through bz. Serguei see below. I need some extra info. On 01/28/2016 07:53 PM, Mike Christie wrote: > On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=111441 >> >> Bug ID: 111441 >>Summary: iscsi fails to attach to targets >>Product: IO/Storage >>Version: 2.5 >> Kernel Version: 4.4.0-1 >> Hardware: x86-64 >> OS: Linux >> Tree: Mainline >> Status: NEW > > >> 4.4.0-1.el7.elrepo.x86_64 #1 > > I have not seen this oops before. We saw similar ones around 5 or 6 > years ago, but they were due to some sysfs or block or scsi issue (I > cannot remember exacty) and fixed there. > > Is this a distro kernel or mainline. BZ says mainline, but the kernel > name in bug looks like a red hat related one. Where did you get it? > > I do not hit this in 4.4 mainline. Send me your kernel .config, so I can > make sure I have the same options. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 111441] New: iscsi fails to attach to targets
On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=111441 > > Bug ID: 111441 >Summary: iscsi fails to attach to targets >Product: IO/Storage >Version: 2.5 > Kernel Version: 4.4.0-1 > Hardware: x86-64 > OS: Linux > Tree: Mainline > Status: NEW > 4.4.0-1.el7.elrepo.x86_64 #1 I have not seen this oops before. We saw similar ones around 5 or 6 years ago, but they were due to some sysfs or block or scsi issue (I cannot remember exacty) and fixed there. Is this a distro kernel or mainline. BZ says mainline, but the kernel name in bug looks like a red hat related one. Where did you get it? I do not hit this in 4.4 mainline. Send me your kernel .config, so I can make sure I have the same options. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Hi Laurence, > -Original Message- > From: Laurence Oberman [mailto:lober...@redhat.com] > Sent: Friday, January 29, 2016 10:25 AM > To: Seymour, Shane M > Cc: Kai Mäkisara (Kolumbus); Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kernel.org > Subject: Re: What partition should the MTMKPART argument specify? Was: > Re: st driver doesn't seem to grok LTO partitioning > > Meant to mention, still waiting for my new LTO5, also this is the first time I > am testing the DAT72. > > Shane, have you had the DAT working before this last patch, if so which patch The latest test was the first chance that I've had to test the changes. I didn't test the previous patches because I didn't have a partitionable LTO drive but I wanted to test the changes to set an explicit size for partition 0 and 1 (since it's the only partitionable drive I have) and found it didn't work with the DAT72. With a fedora user space (an old FC20 install) and a modified mt-st (to remove the negative test) compiled up I tested 4.4.0-next-20160113 (that also has some PCI patches in it for testing) with Kai's patch and it failed and I had an older kernel around (4.4.0-rc5-next-20151215) that I tested after seeing the failure and that works. Thanks Shane > > Laurence Oberman > Principal Software Maintenance Engineer > Red Hat Global Support Services > > - Original Message - > From: "Laurence Oberman" > To: "Shane M Seymour" > Cc: "Kai Mäkisara (Kolumbus)" , "Emmanuel > Florac" , "Laurence Oberman" > , linux-scsi@vger.kernel.org > Sent: Thursday, January 28, 2016 6:23:13 PM > Subject: Re: What partition should the MTMKPART argument specify? Was: > Re: st driver doesn't seem to grok LTO partitioning > > On My DAT tape with the latest patch > > > [root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level > 4 > > [root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions > > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 > bytes. > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, > medium 0, WBS 10, BLL 8 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] > Density 47, tape length: 0, drv buffer: 1 Jan 28 18:17:49 srp-server kernel: > st > 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer > writes: 1, async writes: 1, read ahead: 1 > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: > 0, fast > mteom: 0, auto lock: 0, > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no > block > limits: 0, partitions: 1, s2 log: 0 > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 > sili: 0 > nowait_filemark: 0 > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1 > Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape. > > [root@srp-server ~]# mt -f /dev/st0 mkpartition 1000 > > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 > bytes. > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, > medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] > Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: > st > 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape. > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 > 0 0 0 > 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit > Attention > [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not > ready to ready change, medium may have changed Jan 28 18:18:01 srp-server > kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, > medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] > Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: > st > 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is > 10 > bytes. > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, > psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535 Jan 28 18:18:01 > srp-server > kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 00 00 00 ff ff Jan 28 > 18:18:01 > srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, nbr_parts 0 Jan > 28 > 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two > partitions (1 = 1000 MB). > Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page > length is > 12 bytes. needs_format: 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] > PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, rec 03, units 00, sizes: 65535 > 1000 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 0a
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Meant to mention, still waiting for my new LTO5, also this is the first time I am testing the DAT72. Shane, have you had the DAT working before this last patch, if so which patch Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Laurence Oberman" To: "Shane M Seymour" Cc: "Kai Mäkisara (Kolumbus)" , "Emmanuel Florac" , "Laurence Oberman" , linux-scsi@vger.kernel.org Sent: Thursday, January 28, 2016 6:23:13 PM Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning On My DAT tape with the latest patch [root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level 4 [root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0, Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape. [root@srp-server ~]# mt -f /dev/st0 mkpartition 1000 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 0 0 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to ready change, medium may have changed Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 10 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 00 00 00 ff ff Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, nbr_parts 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two partitions (1 = 1000 MB). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length is 12 bytes. needs_format: 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, rec 03, units 00, sizes: 65535 1000 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 0a 01 01 30 03 00 00 ff ff 03 e8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 15 10 0 0 18 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Illegal Request [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Invalid field in parameter list Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partitioning of tape failed. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape. Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Shane M Seymour" To: "Kai Mäkisara (Kolumbus)" Cc: "Laurence Oberman" , "Emmanuel Florac" , "Laurence Oberman" , linux-scsi@vger.kernel.org Sent: Thursday, January 28, 2016 6:12:41 PM Subject: RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning Hi Kai, $ pwd /sys/class/scsi_tape/st1/device $ cat scsi_level 4 Thanks Shane > -Original Message- > From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi] > Sent: Friday, January 29, 2016 4:04 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kern
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
On My DAT tape with the latest patch [root@srp-server ~]# cat /sys/class/scsi_tape/st0/device/scsi_level 4 [root@srp-server ~]# mt -f /dev/st0 stsetoption can-partitions Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 0, Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 0 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] sysv: 0 nowait: 0 sili: 0 nowait_filemark: 0 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] debugging: 1 Jan 28 18:17:49 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape. [root@srp-server ~]# mt -f /dev/st0 mkpartition 1000 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Loading tape. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 0 0 0 0 0 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Unit Attention [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Not ready to ready change, medium may have changed Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block limits 1 - 16777215 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Density 47, tape length: 0, drv buffer: 1 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Block size: 0, buffer size: 4096 (1 blocks). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partition page length is 10 bytes. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, rec 03, units 00, sizes: 0 65535 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 08 01 00 10 03 00 00 00 00 ff ff Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] psd_cnt 2, max.parts 1, nbr_parts 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Formatting tape with two partitions (1 = 1000 MB). Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sent partition page length is 12 bytes. needs_format: 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] PP: max 1, add 1, xdp 1, psum 02, pofmetc 0, rec 03, units 00, sizes: 65535 1000 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] MP: 11 0a 01 01 30 03 00 00 ff ff 03 e8 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Error: 802, cmd: 15 10 0 0 18 0 Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Sense Key : Illegal Request [current] Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Add. Sense: Invalid field in parameter list Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Partitioning of tape failed. Jan 28 18:18:01 srp-server kernel: st 6:0:1:0: [st0] Rewinding tape. Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Shane M Seymour" To: "Kai Mäkisara (Kolumbus)" Cc: "Laurence Oberman" , "Emmanuel Florac" , "Laurence Oberman" , linux-scsi@vger.kernel.org Sent: Thursday, January 28, 2016 6:12:41 PM Subject: RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning Hi Kai, $ pwd /sys/class/scsi_tape/st1/device $ cat scsi_level 4 Thanks Shane > -Original Message- > From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi] > Sent: Friday, January 29, 2016 4:04 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kernel.org > Subject: Re: What partition should the MTMKPART argument specify? Was: > Re: st driver doesn't seem to grok LTO partitioning > > > > On 28.1.2016, at 9.36, Seymour, Shane M > wrote: > > > > Hi Kai, > > > > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5): > > > > # ./mt -f /dev/st1 stsetoption debug > > # ./mt -f /dev/st1 stsetoption can-partitions # ./mt -f /dev/st1 > > mkpartition 1000 > > /dev/st1: Input/output error > > > ... > > [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes. > > [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, > > po
RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Hi Kai, $ pwd /sys/class/scsi_tape/st1/device $ cat scsi_level 4 Thanks Shane > -Original Message- > From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi] > Sent: Friday, January 29, 2016 4:04 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kernel.org > Subject: Re: What partition should the MTMKPART argument specify? Was: > Re: st driver doesn't seem to grok LTO partitioning > > > > On 28.1.2016, at 9.36, Seymour, Shane M > wrote: > > > > Hi Kai, > > > > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5): > > > > # ./mt -f /dev/st1 stsetoption debug > > # ./mt -f /dev/st1 stsetoption can-partitions # ./mt -f /dev/st1 > > mkpartition 1000 > > /dev/st1: Input/output error > > > ... > > [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes. > > [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, > > pofmetc 0, rec 03, units 00, sizes: 0 65535 [ 3976.389614] st 6:0:3:0: > > [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff [ 3976.389618] st > > 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0 > ^ The problem is > here > > ... > > Using a slightly older kernel to partition the DAT72 drive works (same 3 > commands as above): > ... > > [ 351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes. > > [ 351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0 > > The old driver computes the psd_cnt from the returned page length. The > same applies to the patched driver if the SCSI level of the device < SCSI_3. > This works correctly with my drive that reports SCSI_2. So, the question is: > what SCSI level does your device report? > > Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 111441] New: iscsi fails to attach to targets
https://bugzilla.kernel.org/show_bug.cgi?id=111441 Bug ID: 111441 Summary: iscsi fails to attach to targets Product: IO/Storage Version: 2.5 Kernel Version: 4.4.0-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: SCSI Assignee: linux-scsi@vger.kernel.org Reporter: sbezv...@cisco.com Regression: No The issue is whenever iscsi tries to attach remote iscsi target, there is this traceback generated in dmesg buffer and it fails to attach. Here is the traceback and it is 100% reproducible. I would appreciate if you let me know if it is a known issue and if there is a patch to address it. [ 4693.175319] WARNING: CPU: 27 PID: 17353 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80() [ 4693.175320] sysfs: cannot create duplicate filename '/bus/scsi/devices/8:0:0:0' [ 4693.175321] Modules linked in: target_core_user target_core_pscsi target_core_file target_core_iblock binfmt_misc xt_REDIRECT nf_nat_redirect xt_nat xt_mark xt_conntrack xt_CHECKSUM iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iscsi_tcp libiscsi_tcp bnx2fc cnic uio fcoe 8021q garp mrp openvswitch nf_defrag_ipv6 bonding rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad usnic_verbs ib_core ib_addr xt_comment xt_multiport iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul aesni_intel [ 4693.175362] lrw gf128mul glue_helper ablk_helper cryptd ipmi_devintf ses enclosure sg ipmi_si 8250_fintek ipmi_msghandler joydev input_leds sb_edac iTCO_wdt iTCO_vendor_support pcspkr shpchp lpc_ich edac_core mfd_core wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs libcrc32c sd_mod crc32c_intel mgag200 megaraid_sas drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm libfcoe libfc scsi_transport_fc enic ixgbe(O) i40e vxlan ip6_udp_tunnel igb udp_tunnel ptp pps_core dca i2c_algo_bit fjes dm_mirror dm_region_hash dm_log dm_mod [last unloaded: fnic] [ 4693.175391] CPU: 27 PID: 17353 Comm: iscsiadm Tainted: GW O 4.4.0-1.el7.elrepo.x86_64 #1 [ 4693.175392] Hardware name: Cisco Systems Inc UCSC-C240-M3S/UCSC-C240-M3S, BIOS C240M3.2.0.8.0.071620152208 07/16/2015 [ 4693.175393] e6fae80d 885cff49b948 813273f0 [ 4693.175395] 885cff49b990 885cff49b980 8107c816 882c2b7e5000 [ 4693.175396] 882fa36885d0 885fa53b8d98 0001 ffef [ 4693.175398] Call Trace: [ 4693.175402] [] dump_stack+0x44/0x64 [ 4693.175405] [] warn_slowpath_common+0x86/0xc0 [ 4693.175407] [] warn_slowpath_fmt+0x5c/0x80 [ 4693.175409] [] ? kernfs_path+0x48/0x60 [ 4693.175410] [] sysfs_warn_dup+0x64/0x80 [ 4693.175412] [] sysfs_do_create_link_sd.isra.2+0xaa/0xb0 [ 4693.175414] [] sysfs_create_link+0x25/0x40 [ 4693.175417] [] bus_add_device+0x10b/0x1f0 [ 4693.175419] [] device_add+0x3b5/0x610 [ 4693.175422] [] scsi_sysfs_add_sdev+0xa5/0x290 [ 4693.175424] [] scsi_probe_and_add_lun+0xb65/0xd80 [ 4693.175427] [] ? __pm_runtime_resume+0x5c/0x70 [ 4693.175429] [] __scsi_scan_target+0xf7/0x260 [ 4693.175430] [] ? __pm_runtime_resume+0x5c/0x70 [ 4693.175432] [] scsi_scan_target+0xd7/0xf0 [ 4693.175440] [] iscsi_user_scan_session.part.14+0x105/0x140 [scsi_transport_iscsi] [ 4693.175443] [] ? iscsi_user_scan_session.part.14+0x140/0x140 [scsi_transport_iscsi] [ 4693.175446] [] iscsi_user_scan_session+0x1e/0x30 [scsi_transport_iscsi] [ 4693.175448] [] device_for_each_child+0x50/0x90 [ 4693.175451] [] iscsi_user_scan+0x3d/0x60 [scsi_transport_iscsi] [ 4693.175453] [] store_scan+0xa6/0x100 [ 4693.175456] [] ? __kmalloc+0x1b8/0x250 [ 4693.175458] [] dev_attr_store+0x18/0x30 [ 4693.175459] [] sysfs_kf_write+0x3a/0x50 [ 4693.175461] [] kernfs_fop_write+0x120/0x170 [ 4693.175464] [] __vfs_write+0x37/0x100 [ 4693.175467] [] ? selinux_file_permission+0xc3/0x110 [ 4693.175469] [] ? security_file_permission+0x3d/0xc0 [ 4693.175485] [] ? percpu_down_read+0x1f/0x50 [ 4693.175486] [] vfs_write+0xa2/0x1a0 [ 4693.175489] [] ? do_audit_syscall_entry+0x66/0x70 [ 4693.175491] [] SyS_write+0x55/0xc0 [ 4693.175493] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 4693.175495] ---[ end trace 67e92c68518cd764 ]--- [ 4693.175516] scsi 8:0:0:0: failed to add device: -17 [ 4702.252060] scsi 8:0:0:0: Direct-Access LIO-ORG IBLOCK 4.0 PQ: 0 ANSI: 5 [ 4702.252482] [ cut here ] [ 4702.252488] WARNING: CPU: 2 PID: 17390 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80() [ 4702.252489] sysfs: cannot create duplicate filename '
Re: [PATCH V1] scsi: export function scsi_scan.c:sanitize_inquiry_string
> "Don" == Don Brace writes: Don> The hpsa driver uses this function to cleanup inquiry data. Our new Don> pqi driver will also use this function. This function was copied Don> into both drivers. Don> This patch exports sanitize_inquiry_string so the hpsa and the pqi Don> drivers can use this function directly. Applied to 4.6/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] qla2xxx: Patches for scsi "misc" branch.
> "Himanshu" == Himanshu Madhani writes: Himanshu> Please apply following patches to the scsi tree, misc branch Himanshu> at your earliest convenience. Applied to 4.6/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
> On 28.1.2016, at 21.21, Laurence Oberman wrote: > > Hi Kai > > What kernel was the last patch you attached against. > It was against the latest git version from Jan 24 evening (Finnish time). It is 4.4.0 plus from 4.5 merge window. The patch applies to 3.18.25 with offsets and should apply to anything between these. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Thursday, January 28, 2016 11:22 AM > To: KY Srinivasan ; Olaf Hering > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > martin.peter...@oracle.com; h...@suse.de > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild > test > robot > > On Thu, 2016-01-28 at 19:07 +, KY Srinivasan wrote: > > > > > -Original Message- > > > From: Olaf Hering [mailto:o...@aepfle.de] > > > Sent: Thursday, January 28, 2016 7:56 AM > > > To: KY Srinivasan > > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > > de...@linuxdriverproject.org; oher...@suse.com; > > > jbottom...@parallels.com; h...@infradead.org; > > > linux-scsi@vger.kernel.org; > > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > > > martin.peter...@oracle.com; h...@suse.de > > > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported > > > by kbuild test > > > robot > > > > > > On Wed, Jan 27, K. Y. Srinivasan wrote: > > > > > > > + depends on SCSI_FC_ATTRS > > > > > > I think 'depends' instead of 'select' will cause HYPERV_STORAGE to > > > disapepar during make oldconfig if SCSI_FC_ATTRS was not set > > > before. > > > Not sure what the policy of 'depends' vs. 'select' actually is. > > > If > > > SCSI_FC_ATTRS is supposed to be a library kind of thing then > > > 'select' > > > might be the correct way. > > > > The current build issue is because the Hyper-V storage is configured > > to be built with > > the kernel while the SCSI_FC_AATRS is configured as a module. This > > patch fixes that issue. > > I too am not sure what the policy of using "depends" vs " select" is. > > James, what would be your recommendation here. > > Oh, you don't care if FC_ATTRS are enabled, but if they are you need to > exclude the case where storvsc is built in but FC_ATTRS is a module? > This is the accepted way of doing it: > > depends on m || SCSI_FC_ATTRS != m Thanks James, I will resubmit this patch with the change you have recommended. K. Y
Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Thu, 2016-01-28 at 19:07 +, KY Srinivasan wrote: > > > -Original Message- > > From: Olaf Hering [mailto:o...@aepfle.de] > > Sent: Thursday, January 28, 2016 7:56 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; > > jbottom...@parallels.com; h...@infradead.org; > > linux-scsi@vger.kernel.org; > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > > martin.peter...@oracle.com; h...@suse.de > > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported > > by kbuild test > > robot > > > > On Wed, Jan 27, K. Y. Srinivasan wrote: > > > > > + depends on SCSI_FC_ATTRS > > > > I think 'depends' instead of 'select' will cause HYPERV_STORAGE to > > disapepar during make oldconfig if SCSI_FC_ATTRS was not set > > before. > > Not sure what the policy of 'depends' vs. 'select' actually is. > > If > > SCSI_FC_ATTRS is supposed to be a library kind of thing then > > 'select' > > might be the correct way. > > The current build issue is because the Hyper-V storage is configured > to be built with > the kernel while the SCSI_FC_AATRS is configured as a module. This > patch fixes that issue. > I too am not sure what the policy of using "depends" vs " select" is. > James, what would be your recommendation here. Oh, you don't care if FC_ATTRS are enabled, but if they are you need to exclude the case where storvsc is built in but FC_ATTRS is a module? This is the accepted way of doing it: depends on m || SCSI_FC_ATTRS != m James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Hi Kai What kernel was the last patch you attached against. Thanks Laurence Oberman Principal Software Maintenance Engineer Red Hat Global Support Services - Original Message - From: "Kai Mäkisara (Kolumbus)" To: "Shane M Seymour" Cc: "Laurence Oberman" , "Emmanuel Florac" , "Laurence Oberman" , linux-scsi@vger.kernel.org Sent: Thursday, January 28, 2016 12:04:20 PM Subject: Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning > On 28.1.2016, at 9.36, Seymour, Shane M wrote: > > Hi Kai, > > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5): > > # ./mt -f /dev/st1 stsetoption debug > # ./mt -f /dev/st1 stsetoption can-partitions > # ./mt -f /dev/st1 mkpartition 1000 > /dev/st1: Input/output error > ... > [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes. > [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, > rec 03, units 00, sizes: 0 65535 > [ 3976.389614] st 6:0:3:0: [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff > [ 3976.389618] st 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0 ^ The problem is here ... > Using a slightly older kernel to partition the DAT72 drive works (same 3 > commands as above): ... > [ 351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes. > [ 351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0 The old driver computes the psd_cnt from the returned page length. The same applies to the patched driver if the SCSI level of the device < SCSI_3. This works correctly with my drive that reports SCSI_2. So, the question is: what SCSI level does your device report? Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Thursday, January 28, 2016 7:56 AM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild
> test
> robot
>
> On Wed, Jan 27, K. Y. Srinivasan wrote:
>
> > + depends on SCSI_FC_ATTRS
>
> I think 'depends' instead of 'select' will cause HYPERV_STORAGE to
> disapepar during make oldconfig if SCSI_FC_ATTRS was not set before.
> Not sure what the policy of 'depends' vs. 'select' actually is. If
> SCSI_FC_ATTRS is supposed to be a library kind of thing then 'select'
> might be the correct way.
The current build issue is because the Hyper-V storage is configured to be
built with
the kernel while the SCSI_FC_AATRS is configured as a module. This patch fixes
that issue.
I too am not sure what the policy of using "depends" vs " select" is.
James, what would be your recommendation here.
Regards,
K. Y
>
> Olaf
N�r��yb�X��ǧv�^�){.n�+{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH] add driver for DesignWare UFS Host Controller
HI, Solved it. else if (lrbp->command_type == UTP_CMD_TYPE_DEV_MANAGE || lrbp->command_type == DWC_UTRD_CMD_TYPE_UFS_STORAGE) was also needed ufshcd_transfer_req_compl(). Step by step :) Thanks. Joao On 1/28/2016 6:07 PM, Joao Pinto wrote: > Hi Akinobu, > > I managed to make the following replacement: > "lrbp->command_type = UTP_CMD_TYPE_DEV_MANAGE;" for > "lrbp->command_type = DWC_UTRD_CMD_TYPE_UFS_STORAGE;" being > DWC_UTRD_CMD_TYPE_UFS_STORAGE = 0x11 > > Now I get OCS = 0 which is good: > @ [0]:1100 > @0004 [1]:93936a6a > @0008 [2]: > @000c [3]:93936a6a > @0010 [4]:9f317400 > @0014 [5]: > @0018 [6]:00800080 > @001c [7]:01006a6a > > But now the command is not completed time left is 0 in > ufshcd_wait_for_dev_cmd() > and even after clearing the door bell the issue is not fixed. Did you ever > have > this problem? > > Joao > > On 1/28/2016 5:00 PM, Joao Pinto wrote: >> Hi Akinobu, >> Thanks for the tip! >> >> Joao >> >> On 1/28/2016 12:35 PM, Akinobu Mita wrote: >>> Hi Joao, >>> >>> 2016-01-28 2:04 GMT+09:00 Joao Pinto : - NOP_OUT is failing with OCS = 0x7 The OCS value is calculated in ufshcd_get_tr_ocs() in ufshcd.c. I made a dump of the UTRD pointer where we can check the status = 7 ([2]). UTRD at: 7007c3e0 @ [0]:2100 @0004 [1]:93936a6a @0008 [2]:0007 @000c [3]:93936a6a @0010 [4]:9f317400 @0014 [5]: @0018 [6]:00800080 @001c [7]:01006a6a Did anyone have the same problem? Any hints to overcome this issue? >>> >>> I have seen similar problem when using UFS 2.0 controller. >>> >>> The ufs driver currently doesn't set correct command type field in >>> UTP transfer request descriptor (bit 31:28 in DW0) for UFS 2.0 >>> controller. I checked that your DesignWare UFS driver handles it >>> correctly, so please try with that change. >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add driver for DesignWare UFS Host Controller
Hi Akinobu, I managed to make the following replacement: "lrbp->command_type = UTP_CMD_TYPE_DEV_MANAGE;" for "lrbp->command_type = DWC_UTRD_CMD_TYPE_UFS_STORAGE;" being DWC_UTRD_CMD_TYPE_UFS_STORAGE = 0x11 Now I get OCS = 0 which is good: @ [0]:1100 @0004 [1]:93936a6a @0008 [2]: @000c [3]:93936a6a @0010 [4]:9f317400 @0014 [5]: @0018 [6]:00800080 @001c [7]:01006a6a But now the command is not completed time left is 0 in ufshcd_wait_for_dev_cmd() and even after clearing the door bell the issue is not fixed. Did you ever have this problem? Joao On 1/28/2016 5:00 PM, Joao Pinto wrote: > Hi Akinobu, > Thanks for the tip! > > Joao > > On 1/28/2016 12:35 PM, Akinobu Mita wrote: >> Hi Joao, >> >> 2016-01-28 2:04 GMT+09:00 Joao Pinto : >>> - NOP_OUT is failing with OCS = 0x7 >>> >>> The OCS value is calculated in ufshcd_get_tr_ocs() in ufshcd.c. >>> I made a dump of the UTRD pointer where we can check the status = 7 ([2]). >>> >>> UTRD at: 7007c3e0 >>> @ [0]:2100 >>> @0004 [1]:93936a6a >>> @0008 [2]:0007 >>> @000c [3]:93936a6a >>> @0010 [4]:9f317400 >>> @0014 [5]: >>> @0018 [6]:00800080 >>> @001c [7]:01006a6a >>> >>> Did anyone have the same problem? Any hints to overcome this issue? >> >> I have seen similar problem when using UFS 2.0 controller. >> >> The ufs driver currently doesn't set correct command type field in >> UTP transfer request descriptor (bit 31:28 in DW0) for UFS 2.0 >> controller. I checked that your DesignWare UFS driver handles it >> correctly, so please try with that change. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
Le Thu, 28 Jan 2016 19:31:10 +0200 "Kai Mäkisara (Kolumbus)" écrivait: > > On 27.1.2016, at 1.35, Seymour, Shane M > > wrote: > > > > Hi Emmanuel, > > > >> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 > >> PB which leaves some time to think about it, until LTO-15 circa > >> 2036 :) > > > > There will be other issues to solve before then (by LTO-9 2 with > > compression or LTO-10 without compression and we're at LTO-7 now). > > Take tar format archives with a standard block size of 10k can take > > this much data to get to 2^32 blocks and cause the current 32bit > > block number to wrap: > > > > 43,980,465,111,040 (2^32 * 10240) > > > This is a somewhat theoretic example. In the 1990s no reasonable > person used block size below 32 kB. Now the limit is probably higher. > But, eventually we have to enlarge the block position and count > variables. You'd be surprised. In fact current LTO drive performance maxes out between 32k and 256k. Most people would use 64k. Default for LTFS is 512k. Many, many people just use tar with the default block size, not knowing any better (yay, shoeshine). > > That's probably the correct time to also look at adding support for > > more partitions. Not sure when the extended block id form of READ > > POSITION got added but it may mean only supporting the wider values > > only with tape drives that support REPORT SUPPORTED OPCODES (if > > that can indicate that it supports READ POSITION with extended > > block ids and anything else required to support block numbers > > larger than 2^32). > The current driver supports using up to ST_NBR_PARTITIONS (in the > source set to 4). Support for using partitions must be in the driver. > I am still not sure if partitioning the tape should be in the driver. As a "normal" user, I pretty much don't want to ever have to look at these atrocious SCSI reference docs :) So I'm all for as many things as possible to be exposed through the driver instead. I'm pretty confident that I'm expressing the ordinary developer/admin point of view here :) > > The 0x91 version of SPACE needs to be used as well (the 32bit > > version 0x11 Is currently used) to allow tape movement with counts > > >2^32. That requires a new ioctl call. I haven't looked at what > > >else may need to change but there's > > likely to be more. The alternate version of SPACE is from page 220 > > of the above HP LTO5 tape reference. > > > The first step is to make the internal counters 64 bits. Then the > code should be changed so that it can handle the large addresses. > Note that this is necessary for handling partition changes even if no > positioning commands are exposed to the user. The last step is to > introduce the new positioning methods. > > The new positioning methods should perhaps be defined so that both > the partition number and the block number are specified together. A > proper tape address needs both. > Sounds good. > But I think we should first fix the existing partitioning command so > that it works for current drives. Definitely :) -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/11] qla2xxx: Add support for Private link statistics counters.
Hi Johannes,
On 1/28/16, 12:59 AM, "Johannes Thumshirn" wrote:
>On Wed, Jan 27, 2016 at 12:03:33PM -0500, Himanshu Madhani wrote:
>> From: Harish Zunjarrao
>>
>> Signed-off-by: Harish Zunjarrao
>> Signed-off-by: Himanshu Madhani
>> ---
>> drivers/scsi/qla2xxx/qla_attr.c |6 ++-
>> drivers/scsi/qla2xxx/qla_bsg.c | 61
>>+++
>> drivers/scsi/qla2xxx/qla_bsg.h |1 +
>> drivers/scsi/qla2xxx/qla_dbg.c |2 +-
>> drivers/scsi/qla2xxx/qla_def.h | 32 +++-
>> drivers/scsi/qla2xxx/qla_mbx.c |3 +-
>> 6 files changed, 99 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/scsi/qla2xxx/qla_attr.c
>>b/drivers/scsi/qla2xxx/qla_attr.c
>> index fef659a..fadce04 100644
>> --- a/drivers/scsi/qla2xxx/qla_attr.c
>> +++ b/drivers/scsi/qla2xxx/qla_attr.c
>> @@ -1917,7 +1917,8 @@ qla2x00_get_fc_host_stats(struct Scsi_Host *shost)
>> if (qla2x00_reset_active(vha))
>> goto done;
>>
>> -stats = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &stats_dma);
>> +stats = dma_alloc_coherent(&ha->pdev->dev,
>> +sizeof(struct link_statistics), &stats_dma, GFP_KERNEL);
>> if (stats == NULL) {
>> ql_log(ql_log_warn, vha, 0x707d,
>> "Failed to allocate memory for stats.\n");
>> @@ -1965,7 +1966,8 @@ qla2x00_get_fc_host_stats(struct Scsi_Host *shost)
>> do_div(pfc_host_stat->seconds_since_last_reset, HZ);
>>
>> done_free:
>> -dma_pool_free(ha->s_dma_pool, stats, stats_dma);
>> +dma_free_coherent(&ha->pdev->dev, sizeof(struct link_statistics),
>> +stats, stats_dma);
>> done:
>> return pfc_host_stat;
>> }
>> diff --git a/drivers/scsi/qla2xxx/qla_bsg.c
>>b/drivers/scsi/qla2xxx/qla_bsg.c
>> index d135d6a..913fef2 100644
>> --- a/drivers/scsi/qla2xxx/qla_bsg.c
>> +++ b/drivers/scsi/qla2xxx/qla_bsg.c
>> @@ -2233,6 +2233,64 @@ qla27xx_get_bbcr_data(struct fc_bsg_job *bsg_job)
>> }
>>
>> static int
>> +qla2x00_get_priv_stats(struct fc_bsg_job *bsg_job)
>> +{
>> +struct Scsi_Host *host = bsg_job->shost;
>> +scsi_qla_host_t *vha = shost_priv(host);
>> +struct qla_hw_data *ha = vha->hw;
>> +struct scsi_qla_host *base_vha = pci_get_drvdata(ha->pdev);
>> +struct link_statistics *stats = NULL;
>> +dma_addr_t stats_dma;
>> +int rval = QLA_FUNCTION_FAILED;
>> +
>> +if (test_bit(UNLOADING, &vha->dpc_flags))
>> +goto done;
>> +
>> +if (unlikely(pci_channel_offline(ha->pdev)))
>> +goto done;
>> +
>> +if (qla2x00_reset_active(vha))
>> +goto done;
>> +
>> +if (!IS_FWI2_CAPABLE(ha))
>> +goto done;
>> +
>> +stats = dma_alloc_coherent(&ha->pdev->dev,
>> +sizeof(struct link_statistics), &stats_dma, GFP_KERNEL);
>> +if (!stats) {
>> +ql_log(ql_log_warn, vha, 0x70e2,
>> +"Failed to allocate memory for stats.\n");
>> +goto done;
>> +}
>> +
>> +memset(stats, 0, sizeof(struct link_statistics));
>> +
>> +rval = qla24xx_get_isp_stats(base_vha, stats, stats_dma);
>> +
>> +if (rval != QLA_SUCCESS)
>> +goto done_free;
>> +
>> +ql_dump_buffer(ql_dbg_user + ql_dbg_verbose, vha, 0x70e3,
>> +(uint8_t *)stats, sizeof(struct link_statistics));
>> +
>> +sg_copy_from_buffer(bsg_job->reply_payload.sg_list,
>> +bsg_job->reply_payload.sg_cnt, stats, sizeof(struct link_statistics));
>> +bsg_job->reply->reply_payload_rcv_len = sizeof(struct
>>link_statistics);
>> +
>> +bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_OK;
>> +
>> +bsg_job->reply_len = sizeof(struct fc_bsg_reply);
>> +bsg_job->reply->result = DID_OK << 16;
>> +bsg_job->job_done(bsg_job);
>> +
>> +done_free:
>> +dma_free_coherent(&ha->pdev->dev, sizeof(struct link_statistics),
>> +stats, stats_dma);
>> +done:
>> +return rval;
>> +}
>> +
>> +static int
>> qla2x00_process_vendor_specific(struct fc_bsg_job *bsg_job)
>> {
>> switch (bsg_job->request->rqst_data.h_vendor.vendor_cmd[0]) {
>> @@ -2296,6 +2354,9 @@ qla2x00_process_vendor_specific(struct fc_bsg_job
>>*bsg_job)
>> case QL_VND_GET_BBCR_DATA:
>> return qla27xx_get_bbcr_data(bsg_job);
>>
>> +case QL_VND_GET_PRIV_STATS:
>> +return qla2x00_get_priv_stats(bsg_job);
>> +
>> default:
>> return -ENOSYS;
>> }
>> diff --git a/drivers/scsi/qla2xxx/qla_bsg.h
>>b/drivers/scsi/qla2xxx/qla_bsg.h
>> index 4275177..c40dd8b 100644
>> --- a/drivers/scsi/qla2xxx/qla_bsg.h
>> +++ b/drivers/scsi/qla2xxx/qla_bsg.h
>> @@ -28,6 +28,7 @@
>> #define QL_VND_GET_FLASH_UPDATE_CAPS0x15
>> #define QL_VND_SET_FLASH_UPDATE_CAPS0x16
>> #define QL_VND_GET_BBCR_DATA0x17
>> +#define QL_VND_GET_PRIV_STATS 0x18
>>
>> /* BSG Vendor specific subcode returns */
>> #define EXT_STATUS_OK 0
>> diff --git a/drivers/scsi/qla2xxx/qla_dbg.c
>>b/drivers/scsi/qla2xxx/q
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
> On 27.1.2016, at 1.35, Seymour, Shane M wrote: > > Hi Emmanuel, > >> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB >> which leaves some time to think about it, until LTO-15 circa 2036 :) > > There will be other issues to solve before then (by LTO-9 2 with compression > or LTO-10 without compression and we're at LTO-7 now). Take tar format > archives with a standard block size of 10k can take this much data to get > to 2^32 blocks and cause the current 32bit block number to wrap: > > 43,980,465,111,040 (2^32 * 10240) > This is a somewhat theoretic example. In the 1990s no reasonable person used block size below 32 kB. Now the limit is probably higher. But, eventually we have to enlarge the block position and count variables. > After that much data has been written the SCSI-2 command READ POSITION > will not be able to show the current position correctly (which is what the st > driver uses to determine the position for an MTIOCPOS). It may be less > than that since some drives include file marks in the logical block number if > the program that produced the tape writes them out. > > That means switching to the extended block id form of READ POSITION > so we have 64bit counts for those values, see page 150: > > https://docs.oracle.com/cd/E21419_04/en/LTO5_Vol3_E5b/LTO5_Vol3_E5b.pdf > > That's going to require new ioctls like MTIOCPOS64 and other changes within > the driver to support larger types for holding some values. That will also > raise > all sorts of fun compatibility questions as well (should MTIOCPOS work at all > for such a tape drive or should it work until something overflows and return > what data it can and give an errno of -EOVERFLOW etc). > I think we should support MTIOCPOS as far as we can. There is no point to make existing software unusable for people who happen to buy a modern drive. Note also that the block number given to MTIOCPOS is long, i.e., 64 bits in the important architectures ;-) (The argument to MTSEEK is int, though.) > That's probably the correct time to also look at adding support for more > partitions. Not sure when the extended block id form of READ POSITION > got added but it may mean only supporting the wider values only with tape > drives that support REPORT SUPPORTED OPCODES (if that can indicate that > it supports READ POSITION with extended block ids and anything else > required to support block numbers larger than 2^32). > The current driver supports using up to ST_NBR_PARTITIONS (in the source set to 4). Support for using partitions must be in the driver. I am still not sure if partitioning the tape should be in the driver. > The 0x91 version of SPACE needs to be used as well (the 32bit version 0x11 > Is currently used) to allow tape movement with counts >2^32. That requires > a new ioctl call. I haven't looked at what else may need to change but there's > likely to be more. The alternate version of SPACE is from page 220 of the > above HP LTO5 tape reference. > The first step is to make the internal counters 64 bits. Then the code should be changed so that it can handle the large addresses. Note that this is necessary for handling partition changes even if no positioning commands are exposed to the user. The last step is to introduce the new positioning methods. The new positioning methods should perhaps be defined so that both the partition number and the block number are specified together. A proper tape address needs both. But I think we should first fix the existing partitioning command so that it works for current drives. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning
> On 28.1.2016, at 9.36, Seymour, Shane M wrote: > > Hi Kai, > > With the changes the I get a failure partitioning a HP DAT72 drive (DDS-5): > > # ./mt -f /dev/st1 stsetoption debug > # ./mt -f /dev/st1 stsetoption can-partitions > # ./mt -f /dev/st1 mkpartition 1000 > /dev/st1: Input/output error > ... > [ 3976.389605] st 6:0:3:0: [st1] Partition page length is 10 bytes. > [ 3976.389610] st 6:0:3:0: [st1] PP: max 1, add 0, xdp 0, psum 02, pofmetc 0, > rec 03, units 00, sizes: 0 65535 > [ 3976.389614] st 6:0:3:0: [st1] MP: 11 08 01 00 10 03 00 00 00 00 ff ff > [ 3976.389618] st 6:0:3:0: [st1] psd_cnt 2, max.parts 1, nbr_parts 0 ^ The problem is here ... > Using a slightly older kernel to partition the DAT72 drive works (same 3 > commands as above): ... > [ 351.584906] st 6:0:3:0: [st1] Partition page length is 10 bytes. > [ 351.584908] st 6:0:3:0: [st1] psd_cnt 1, max.parts 1, nbr_parts 0 The old driver computes the psd_cnt from the returned page length. The same applies to the patched driver if the SCSI level of the device < SCSI_3. This works correctly with my drive that reports SCSI_2. So, the question is: what SCSI level does your device report? Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2 1/3] target: Fix LUN_RESET active I/O handling for ACK_KREF
+ sess = cmd->se_sess;
+ if (WARN_ON_ONCE(!sess))
+ continue;
+
+ spin_lock(&sess->sess_cmd_lock);
+ rc = __target_check_io_state(cmd);
+ spin_unlock(&sess->sess_cmd_lock);
+ if (!rc) {
+ printk("LUN_RESET I/O: non-zero
kref_get_unless_zero\n");
Is this message always correct? __target_check_io_state() will return
false for commands that were completed..
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add driver for DesignWare UFS Host Controller
Hi Akinobu, Thanks for the tip! Joao On 1/28/2016 12:35 PM, Akinobu Mita wrote: > Hi Joao, > > 2016-01-28 2:04 GMT+09:00 Joao Pinto : >> - NOP_OUT is failing with OCS = 0x7 >> >> The OCS value is calculated in ufshcd_get_tr_ocs() in ufshcd.c. >> I made a dump of the UTRD pointer where we can check the status = 7 ([2]). >> >> UTRD at: 7007c3e0 >> @ [0]:2100 >> @0004 [1]:93936a6a >> @0008 [2]:0007 >> @000c [3]:93936a6a >> @0010 [4]:9f317400 >> @0014 [5]: >> @0018 [6]:00800080 >> @001c [7]:01006a6a >> >> Did anyone have the same problem? Any hints to overcome this issue? > > I have seen similar problem when using UFS 2.0 controller. > > The ufs driver currently doesn't set correct command type field in > UTP transfer request descriptor (bit 31:28 in DW0) for UFS 2.0 > controller. I checked that your DesignWare UFS driver handles it > correctly, so please try with that change. > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger
On Thu, 2016-01-28 at 18:24 +0200, Sagi Grimberg wrote: > > I'm going to downvote this topic just like last year with my PC hat > > on as I think it's a) not relevant or usefully discussable at LSF > > and b) framed the wrong way. > > I'm not sure LSF is the right platform, but I gotta say that this > thread indicates that there's bad blood going around here and it > needs to sorted out. OK, could we make this more concrete. "Bad blood" or perhaps bias against people ideas or patches is easy to allege, especially if you think it will get your patches in, and, in the current climate, easy to make stick because you can pin this on a maintainer who's simply having a bad day or is overloaded. Do you have an example of a set of patches you think have been unreasonably rejected? Probably discussing the issues before a wider audience will help solve them before you drag someone to the "right forum" (to me, those words conjure visions of pitch forks, stocks and pilliories, but that's probably because the original version of Frankenstien was on recently). James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
我的相片在
你的老朋友邀你来Q群:343257759
Re: [LSF/MM TOPIC] LIO/SCST Merger
I'm going to downvote this topic just like last year with my PC hat on as I think it's a) not relevant or usefully discussable at LSF and b) framed the wrong way. I'm not sure LSF is the right platform, but I gotta say that this thread indicates that there's bad blood going around here and it needs to sorted out. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Wed, Jan 27, K. Y. Srinivasan wrote: > + depends on SCSI_FC_ATTRS I think 'depends' instead of 'select' will cause HYPERV_STORAGE to disapepar during make oldconfig if SCSI_FC_ATTRS was not set before. Not sure what the policy of 'depends' vs. 'select' actually is. If SCSI_FC_ATTRS is supposed to be a library kind of thing then 'select' might be the correct way. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Wednesday, January 27, 2016 10:03 PM > To: KY Srinivasan ; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > martin.peter...@oracle.com; h...@suse.de > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild > test > robot > > On Wed, 2016-01-27 at 23:29 -0800, K. Y. Srinivasan wrote: > > tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2 > > f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2fli > > > nux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad71 > 08d3 > > > 2796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS > %2ftO > > z%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master > > head: 03c21cb775a313f1ff19be59c5d02df3e3526471 > > commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly > > support Fibre Channel devices > > date: 3 weeks ago > > config: x86_64-randconfig-s3-01281016 (attached as .config) > > reproduce: > > git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 > > # save the attached .config to linux build tree > > make ARCH=x86_64 > > > > All errors (new ones prefixed by >>): > > > >drivers/built-in.o: In function `storvsc_remove': > > > > storvsc_drv.c:(.text+0x213af7): undefined reference to > > > > `fc_remove_host' > >drivers/built-in.o: In function `storvsc_drv_init': > > > > storvsc_drv.c:(.init.text+0xcbcc): undefined reference to > > > > `fc_attach_transport' > > > > storvsc_drv.c:(.init.text+0xcc06): undefined reference to > > > > `fc_release_transport' > >drivers/built-in.o: In function `storvsc_drv_exit': > > > > storvsc_drv.c:(.exit.text+0x123c): undefined reference to > > > > `fc_release_transport' > > > > With this commit, the storvsc driver depends on FC atttributes. Make > > this > > dependency explicit. > > > > Signed-off-by: K. Y. Srinivasan > > Reported-by: Fengguang Wu > > --- > > drivers/scsi/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > > index 64eed87..24365c3 100644 > > --- a/drivers/scsi/Kconfig > > +++ b/drivers/scsi/Kconfig > > @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND > > config HYPERV_STORAGE > > tristate "Microsoft Hyper-V virtual storage driver" > > depends on SCSI && HYPERV > > + depends on SCSI_FC_ATTRS > > default HYPERV > > help > > Select this option to enable the Hyper-V virtual storage > > driver. > > OK, so I thought Hannes requested that you not make the hyperv driver > depend on the FC attrs and you said you would ... has this changed? Since 99% of the code would be identical, Hannes agreed that it would not be good to have a separate FC driver. Given that, this is the only option we have. Regards, K. Y > > James
[PATCH 2/2] megaraid_sas: Fix SMAP issue
Inside compat IOCTL hook of driver, driver was using wrong address of
ioc->frame.raw which leads sense_ioc_ptr to be calculated wrongly and
failing IOCTL.
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 52f3419..cc92c81 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6843,9 +6843,9 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
int i;
int error = 0;
compat_uptr_t ptr;
- unsigned long local_raw_ptr;
u32 local_sense_off;
u32 local_sense_len;
+ u32 user_sense_off;
if (clear_user(ioc, sizeof(*ioc)))
return -EFAULT;
@@ -6863,17 +6863,16 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
* sense_len is not null, so prepare the 64bit value under
* the same condition.
*/
- if (get_user(local_raw_ptr, ioc->frame.raw) ||
- get_user(local_sense_off, &ioc->sense_off) ||
- get_user(local_sense_len, &ioc->sense_len))
+ if (get_user(local_sense_off, &ioc->sense_off) ||
+ get_user(local_sense_len, &ioc->sense_len) ||
+ get_user(user_sense_off, &cioc->sense_off))
return -EFAULT;
-
if (local_sense_len) {
void __user **sense_ioc_ptr =
- (void __user **)((u8*)local_raw_ptr + local_sense_off);
+ (void __user **)((u8 *)((unsigned long)&ioc->frame.raw)
+ local_sense_off);
compat_uptr_t *sense_cioc_ptr =
- (compat_uptr_t *)(cioc->frame.raw + cioc->sense_off);
+ (compat_uptr_t *)(((unsigned long)&cioc->frame.raw) +
user_sense_off);
if (get_user(ptr, sense_cioc_ptr) ||
put_user(compat_ptr(ptr), sense_ioc_ptr))
return -EFAULT;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] megaraid_sas: Fix for IO failing post OCR in SRIOV environment
Driver assumes that VFs always have peers present whenever they have same LD
IDs. But this is not the case.
This patch handles the above mentioned by explicitly checking for a peer before
making HA/non-HA path decision.
Signed-off-by: Uday Lingala
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas.h| 13 ++---
drivers/scsi/megaraid/megaraid_sas_base.c | 6 +++--
drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 ++---
3 files changed, 39 insertions(+), 22 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index b6fdb48..4484e63 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -393,6 +393,7 @@ enum MR_EVT_ARGS {
#define SGE_BUFFER_SIZE4096
+#define MEGASAS_CLUSTER_ID_SIZE16
/*
* define constants for device list query options
*/
@@ -1227,7 +1228,8 @@ struct megasas_ctrl_info {
*/
struct {
#if defined(__BIG_ENDIAN_BITFIELD)
- u32 reserved:26;
+ u32 reserved:25;
+ u32 passive:1;
u32 premiumFeatureMismatch:1;
u32 ctrlPropIncompatible:1;
u32 fwVersionMismatch:1;
@@ -1241,11 +1243,12 @@ struct megasas_ctrl_info {
u32 fwVersionMismatch:1;
u32 ctrlPropIncompatible:1;
u32 premiumFeatureMismatch:1;
- u32 reserved:26;
+ u32 passive:1;
+ u32 reserved:25;
#endif
} cluster;
- char clusterId[16]; /*7D4h */
+ char clusterId[MEGASAS_CLUSTER_ID_SIZE]; /*0x7D4 */
struct {
u8 maxVFsSupported;/*0x7E4*/
u8 numVFsEnabled; /*0x7E5*/
@@ -2126,7 +2129,9 @@ struct megasas_instance {
char skip_heartbeat_timer_del;
u8 requestorId;
char PlasmaFW111;
- char mpio;
+ char clusterId[MEGASAS_CLUSTER_ID_SIZE];
+ u8 peerIsPresent;
+ u8 passive;
u16 throttlequeuedepth;
u8 mask_interrupts;
u16 max_chain_frame_sz;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 54922e5..52f3419 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1943,7 +1943,7 @@ void megaraid_sas_kill_hba(struct megasas_instance
*instance)
writel(MFI_STOP_ADP, &instance->reg_set->doorbell);
/* Flush */
readl(&instance->reg_set->doorbell);
- if (instance->mpio && instance->requestorId)
+ if (instance->requestorId && instance->peerIsPresent)
memset(instance->ld_ids, 0xff, MEGASAS_MAX_LD_IDS);
} else {
writel(MFI_STOP_ADP,
@@ -5182,7 +5182,9 @@ static int megasas_init_fw(struct megasas_instance
*instance)
tmp_sectors = min_t(u32, max_sectors_1, max_sectors_2);
- instance->mpio = ctrl_info->adapterOperations2.mpio;
+ instance->peerIsPresent = ctrl_info->cluster.peerIsPresent;
+ instance->passive = ctrl_info->cluster.passive;
+ memcpy(instance->clusterId, ctrl_info->clusterId,
sizeof(instance->clusterId));
instance->UnevenSpanSupport =
ctrl_info->adapterOperations2.supportUnevenSpans;
if (instance->UnevenSpanSupport) {
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index be9c3f1..d9d0029 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3325,27 +3325,37 @@ out:
return ret;
}
+/*SRIOV get other instance in cluster if any*/
+struct megasas_instance *megasas_get_peer_instance(struct megasas_instance
*instance)
+{
+ int i;
+
+ for (i = 0; i < MAX_MGMT_ADAPTERS; i++) {
+ if (megasas_mgmt_info.instance[i] &&
+ (megasas_mgmt_info.instance[i] != instance) &&
+megasas_mgmt_info.instance[i]->requestorId &&
+megasas_mgmt_info.instance[i]->peerIsPresent &&
+ (memcmp((megasas_mgmt_info.instance[i]->clusterId),
+ instance->clusterId, MEGASAS_CLUSTER_ID_SIZE) == 0))
+ return megasas_mgmt_info.instance[i];
+ }
+ return NULL;
+}
+
/* Check for a second path that is currently UP */
int megasas_check_mpio_paths(struct megasas_instance *instance,
struct scsi_cmnd *scmd)
{
- int i, j, retval = (DID_RESET << 16);
-
- if (instance->mpio && instance->requestorId) {
- for (i = 0 ; i < MAX_MGMT_ADAPTERS ; i++)
- for (j = 0 ; j < MAX_LOGICAL_DRIVES; j++)
- if (megasas_mgmt_info.instance[i] &&
-
[PATCH 0/2] megaraid_sas: few more updates for scsi-next
These two patches will be applied on top of recent resent patchset by me. I am posting these patches separately(not in the resent patchset) to avoid confusion as these are fresh(first time) submitted. Sumit Saxena (2): megaraid_sas: Fix for IO failing post OCR in SRIOV environment megaraid_sas: Fix SMAP issue drivers/scsi/megaraid/megaraid_sas.h| 13 ++--- drivers/scsi/megaraid/megaraid_sas_base.c | 19 ++--- drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 ++--- 3 files changed, 45 insertions(+), 29 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/15] megaraid_sas: driver version upgrade
Signed-off-by: Sumit Saxena --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 3e92f20..b6fdb48 100644 --- a/drivers/scsi/megaraid/megaraid_sas.h +++ b/drivers/scsi/megaraid/megaraid_sas.h @@ -35,8 +35,8 @@ /* * MegaRAID SAS Driver meta data */ -#define MEGASAS_VERSION"06.808.16.00-rc1" -#define MEGASAS_RELDATE"Oct. 8, 2015" +#define MEGASAS_VERSION"06.810.09.00-rc1" +#define MEGASAS_RELDATE"Jan. 28, 2016" /* * Device IDs -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/15] megaraid_sas: Fastpath region lock bypass
Firmware will fill per LD data to tell driver that particular LD supports
Region lock bypass or not. If yes, then
Driver will send non FP LDIO to region lock bypass FIFO. With this change in
driver, firmware will optimize certain
code to improve performance.
There are no changes in this patch from last time sent patch.
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas.h| 8 ++--
drivers/scsi/megaraid/megaraid_sas_fp.c | 2 ++
drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 --
drivers/scsi/megaraid/megaraid_sas_fusion.h | 8 +---
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 773fc54..01135be 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1528,7 +1528,9 @@ union megasas_sgl_frame {
typedef union _MFI_CAPABILITIES {
struct {
#if defined(__BIG_ENDIAN_BITFIELD)
- u32 reserved:23;
+ u32 reserved:21;
+ u32 support_fp_rlbypass:1;
+ u32 support_vfid_in_ioframe:1;
u32 support_ext_io_size:1;
u32 support_ext_queue_depth:1;
u32 security_protocol_cmds_fw:1;
@@ -1548,7 +1550,9 @@ typedef union _MFI_CAPABILITIES {
u32 security_protocol_cmds_fw:1;
u32 support_ext_queue_depth:1;
u32 support_ext_io_size:1;
- u32 reserved:23;
+ u32 support_vfid_in_ioframe:1;
+ u32 support_fp_rlbypass:1;
+ u32 reserved:21;
#endif
} mfi_capabilities;
__le32 reg;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index 741509b..e413113 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fp.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fp.c
@@ -1020,6 +1020,8 @@ MR_BuildRaidContext(struct megasas_instance *instance,
/* assume this IO needs the full row - we'll adjust if not true */
regSize = stripSize;
+ io_info->do_fp_rlbypass = raid->capability.fpBypassRegionLock;
+
/* Check if we can send this I/O via FastPath */
if (raid->capability.fpCapable) {
if (isRead)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 4b0c86c..518b488 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -666,6 +666,8 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
if (instance->max_chain_frame_sz > MEGASAS_CHAIN_FRAME_SZ_MIN)
drv_ops->mfi_capabilities.support_ext_io_size = 1;
+ drv_ops->mfi_capabilities.support_fp_rlbypass = 1;
+
/* Convert capability to LE32 */
cpu_to_le32s((u32 *)&init_frame->driver_operations.mfi_capabilities);
@@ -1710,8 +1712,8 @@ megasas_build_ldio_fusion(struct megasas_instance
*instance,
(MEGASAS_REQ_DESCRIPT_FLAGS_LD_IO
<< MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
if (fusion->adapter_type == INVADER_SERIES) {
- if (io_request->RaidContext.regLockFlags ==
- REGION_TYPE_UNUSED)
+ if (io_info.do_fp_rlbypass ||
+ (io_request->RaidContext.regLockFlags ==
REGION_TYPE_UNUSED))
cmd->request_desc->SCSIIO.RequestFlags =
(MEGASAS_REQ_DESCRIPT_FLAGS_NO_LOCK <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index a1f1c0b..db0978d 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -643,7 +643,8 @@ struct MR_SPAN_BLOCK_INFO {
struct MR_LD_RAID {
struct {
#if defined(__BIG_ENDIAN_BITFIELD)
- u32 reserved4:6;
+ u32 reserved4:5;
+ u32 fpBypassRegionLock:1;
u32 tmCapable:1;
u32 fpNonRWCapable:1;
u32 fpReadAcrossStripe:1;
@@ -667,7 +668,8 @@ struct MR_LD_RAID {
u32 fpReadAcrossStripe:1;
u32 fpNonRWCapable:1;
u32 tmCapable:1;
- u32 reserved4:6;
+ u32 fpBypassRegionLock:1;
+ u32 reserved4:5;
#endif
} capability;
__le32 reserved6;
@@ -737,7 +739,7 @@ struct IO_REQUEST_INFO {
u8 fpOkForIo;
u8 IoforUnevenSpan;
u8 start_span;
- u8 reserved;
+ u8 do_fp_rlbypass;
u64 start_row;
u8 span_arm; /* span[7:5], arm[4
Re: [PATCH] storvsc: use small sg_tablesize on x86
On Thu, 2016-01-28 at 07:48 +0100, Olaf Hering wrote: > On Wed, Jan 27, James Bottomley wrote: > > > It's not really architecture independent, is it? Just use the bit > > width config. > > Again: which one? This driver is not for mips|powerpc|score|sh. zgrep CONFIG_.*BIT /proc/config.gz [...] CONFIG_64BIT=y James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/15] megaraid_sas: Introduce module parameter for SCSI command-timeout
This patch will introduce module-parameter for SCSI command timeout value and
fix setting of resetwaitime beyond a value.
There was some comment from Tomas on last time sent patch regarding why should
driver provided scmd_timeout module parameter.
This is done for special cases where user wants to tune scmd_timeout value
during driver load time. Default value is same as before-90 secs.
There are no changes in this patch on top of last time sent patch.
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_base.c | 15 ---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index d2ea977..54922e5 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -83,7 +83,7 @@ module_param(throttlequeuedepth, int, S_IRUGO);
MODULE_PARM_DESC(throttlequeuedepth,
"Adapter queue depth when throttled due to I/O timeout. Default: 16");
-int resetwaittime = MEGASAS_RESET_WAIT_TIME;
+unsigned int resetwaittime = MEGASAS_RESET_WAIT_TIME;
module_param(resetwaittime, int, S_IRUGO);
MODULE_PARM_DESC(resetwaittime, "Wait time in seconds after I/O timeout "
"before resetting adapter. Default: 180");
@@ -100,6 +100,10 @@ unsigned int dual_qdepth_disable;
module_param(dual_qdepth_disable, int, S_IRUGO);
MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature.
Default: 0");
+unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT;
+module_param(scmd_timeout, int, S_IRUGO);
+MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), default 90s.
See megasas_reset_timer.");
+
MODULE_LICENSE("GPL");
MODULE_VERSION(MEGASAS_VERSION);
MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -1850,7 +1854,7 @@ static int megasas_slave_configure(struct scsi_device
*sdev)
* The RAID firmware may require extended timeouts.
*/
blk_queue_rq_timeout(sdev->request_queue,
- MEGASAS_DEFAULT_CMD_TIMEOUT * HZ);
+ scmd_timeout * HZ);
return 0;
}
@@ -2645,7 +2649,7 @@ blk_eh_timer_return megasas_reset_timer(struct scsi_cmnd
*scmd)
unsigned long flags;
if (time_after(jiffies, scmd->jiffies_at_alloc +
- (MEGASAS_DEFAULT_CMD_TIMEOUT * 2) * HZ)) {
+ (scmd_timeout * 2) * HZ)) {
return BLK_EH_NOT_HANDLED;
}
@@ -5254,6 +5258,11 @@ static int megasas_init_fw(struct megasas_instance
*instance)
instance->throttlequeuedepth =
MEGASAS_THROTTLE_QUEUE_DEPTH;
+ if (resetwaittime > MEGASAS_RESET_WAIT_TIME)
+ resetwaittime = MEGASAS_RESET_WAIT_TIME;
+
+ if ((scmd_timeout < 10) || (scmd_timeout > MEGASAS_DEFAULT_CMD_TIMEOUT))
+ scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT;
/* Launch SR-IOV heartbeat timer */
if (instance->requestorId) {
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 64926f7..e740e26 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -91,7 +91,7 @@ void megasas_start_timer(struct megasas_instance *instance,
struct timer_list *timer,
void *fn, unsigned long interval);
extern struct megasas_mgmt_info megasas_mgmt_info;
-extern int resetwaittime;
+extern unsigned int resetwaittime;
extern unsigned int dual_qdepth_disable;
static void megasas_free_rdpq_fusion(struct megasas_instance *instance);
static void megasas_free_reply_fusion(struct megasas_instance *instance);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/15] megaraid_sas: Reply Descriptor Post Queue(RDPQ) support
This patch will create reply queue pool for each MSI-x index and will provide
array of all reply queue base address
instead of single base address of legacy mode. Using this new interface Driver
can support higher Queue depth allocating
more reply queue as scattered DMA pool.
If array mode is not supported driver will fall back to legacy method of
allocation reply pool.
This method fall back controller queue depth to 1K max. To enable more than 1K
QD, driver expect FW to support Array mode
and scratch_pad3 should provide new queue depth value.
Using this method, Firmware should not allow downgrade (OFU) if latest driver
and latest FW report 4K QD and Array mode reply queue.
This type of FW upgrade may cause firmware fault and it should not be
supported. Upgrade of FW will work,
but queue depth of the controller will be unchanged until reboot/driver reload.
I have accomodated Tomas' comments in this patch- fix few error handling cases
inside functions-
megasas_alloc_cmdlist_fusion() and megasas_alloc_cmds_fusion(), fix typo-
disable(old- disbale)
in rdpq_enable module parameter's description, modify print to reflect RDPQ
support statement correctly.
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
---
drivers/scsi/megaraid/megaraid_sas.h| 6 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 9 +
drivers/scsi/megaraid/megaraid_sas_fusion.c | 543
drivers/scsi/megaraid/megaraid_sas_fusion.h | 12 +-
4 files changed, 331 insertions(+), 239 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 01135be..3b1ed2d 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -152,6 +152,7 @@
#define MFI_RESET_FLAGSMFI_INIT_READY| \
MFI_INIT_MFIMODE| \
MFI_INIT_ABORT
+#define MPI2_IOCINIT_MSGFLAG_RDPQ_ARRAY_MODE(0x01)
/*
* MFI frame flags
@@ -1416,6 +1417,7 @@ enum DCMD_TIMEOUT_ACTION {
#define MR_MAX_REPLY_QUEUES_EXT_OFFSET 0X003FC000
#define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
#define MR_MAX_MSIX_REG_ARRAY 16
+#define MR_RDPQ_MODE_OFFSET0X0080
/*
* register set for both 1068 and 1078 controllers
* structure extended for 1078 registers
@@ -1455,8 +1457,9 @@ struct megasas_register_set {
u32 outbound_scratch_pad ; /*00B0h*/
u32 outbound_scratch_pad_2; /*00B4h*/
+ u32 outbound_scratch_pad_3; /*00B8h*/
- u32 reserved_4[2]; /*00B8h*/
+ u32 reserved_4; /*00BCh*/
u32 inbound_low_queue_port ;/*00C0h*/
@@ -2117,6 +2120,7 @@ struct megasas_instance {
u8 mask_interrupts;
u16 max_chain_frame_sz;
u8 is_imr;
+ u8 is_rdpq;
bool dev_handle;
};
struct MR_LD_VF_MAP {
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index ea3994b..8df58c2 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -92,6 +92,10 @@ int smp_affinity_enable = 1;
module_param(smp_affinity_enable, int, S_IRUGO);
MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale
Default: enable(1)");
+int rdpq_enable = 1;
+module_param(rdpq_enable, int, S_IRUGO);
+MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue
depth enable/disable Default: disable(0)");
+
MODULE_LICENSE("GPL");
MODULE_VERSION(MEGASAS_VERSION);
MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -5080,6 +5084,9 @@ static int megasas_init_fw(struct megasas_instance
*instance)
instance->msix_vectors = ((scratch_pad_2
& MR_MAX_REPLY_QUEUES_EXT_OFFSET)
>>
MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT) + 1;
+ if (rdpq_enable)
+ instance->is_rdpq = (scratch_pad_2 &
MR_RDPQ_MODE_OFFSET) ?
+ 1 : 0;
fw_msix_count = instance->msix_vectors;
/* Save 1-15 reply post index address to local
memory
* Index 0 is already saved from reg offset
@@ -5116,6 +5123,8 @@ static int megasas_init_fw(struct megasas_instance
*instance)
dev_info(&instance->pdev->dev,
"current msix/online cpus\t: (%d/%d)\n",
instance->msix_vectors, (unsigned int)num_online_cpus());
+ dev_info(&instance->pdev->dev,
+ "RDPQ mode\t: (%s)\n", instance->is_rdpq ? "enabled" :
"disabled");
tasklet_init(&instance->isr_tasklet, instance->instancet->tasklet,
[PATCH v2 09/15] megaraid_sas: Dual Queue depth support
This patch will add support for Dual Queue depth reported by firmware.
Below are key points-
1. For iMR controllers, firmware will report two queue depths- 1. Controller
wide Queue depth 2. LDIO Queue depth(240).
Ofcourse, Controller wide Queue depth will be greater among two. Using this new
method, iMR can provide larger Queue depth(QD)
for JBOD and limited QD for Virtual Disk(VD). This feature gives benefit for
iMR product which will be used for deployment
with large number of JBOD and limited number of VD on setup.
2. megaraid_sas driver will throttle Read write LDIOs based when RW LDIOs
reaches "LDIO Queue Depth".
3. This feature of dual queue depth can enabled/disabled via module parameter.
Default behavior is: Dual Queue depth is enabled.
4. Added sysfs parameter "ldio_outstanding" for user to read LDIO outstanding
at run time.
5. There are different flavors of firmware using same driver and for specific
firmware this will be
turned on(by default) where it's really needed. For rest of firmware flavors,
this will be switched off(not supported).
I have accomodated Tomas' comments provided on last time sent patch- use
atomic_inc_return instead of using atomic_read() and
atomic_inc() separately inside function- megasas_build_and_issue_cmd_fusion().
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas.h| 9 +++
drivers/scsi/megaraid/megaraid_sas_base.c | 20 ++-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 88 ++---
3 files changed, 107 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 3b1ed2d..2a2f491 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1353,6 +1353,12 @@ enum DCMD_TIMEOUT_ACTION {
KILL_ADAPTER = 1,
IGNORE_TIMEOUT = 2,
};
+
+enum FW_BOOT_CONTEXT {
+ PROBE_CONTEXT = 0,
+ OCR_CONTEXT = 1,
+};
+
/* Frame Type */
#define IO_FRAME 0
#define PTHRU_FRAME1
@@ -2038,6 +2044,8 @@ struct megasas_instance {
u16 max_fw_cmds;
u16 max_mfi_cmds;
u16 max_scsi_cmds;
+ u16 ldio_threshold;
+ u16 cur_can_queue;
u32 max_sectors_per_req;
struct megasas_aen_event *ev;
@@ -2068,6 +2076,7 @@ struct megasas_instance {
u32 fw_support_ieee;
atomic_t fw_outstanding;
+ atomic_t ldio_outstanding;
atomic_t fw_reset_no_pci_access;
struct megasas_instance_template *instancet;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index edf8911..961c024 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -96,6 +96,10 @@ int rdpq_enable = 1;
module_param(rdpq_enable, int, S_IRUGO);
MODULE_PARM_DESC(rdpq_enable, " Allocate reply queue in chunks for large queue
depth enable/disable Default: disable(0)");
+unsigned int dual_qdepth_disable;
+module_param(dual_qdepth_disable, int, S_IRUGO);
+MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual queue depth feature.
Default: 0");
+
MODULE_LICENSE("GPL");
MODULE_VERSION(MEGASAS_VERSION);
MODULE_AUTHOR("megaraidlinux@avagotech.com");
@@ -1976,7 +1980,7 @@ megasas_check_and_restore_queue_depth(struct
megasas_instance *instance)
spin_lock_irqsave(instance->host->host_lock, flags);
instance->flag &= ~MEGASAS_FW_BUSY;
- instance->host->can_queue = instance->max_scsi_cmds;
+ instance->host->can_queue = instance->cur_can_queue;
spin_unlock_irqrestore(instance->host->host_lock, flags);
}
}
@@ -2941,6 +2945,16 @@ megasas_page_size_show(struct device *cdev,
return snprintf(buf, PAGE_SIZE, "%ld\n", (unsigned long)PAGE_SIZE - 1);
}
+static ssize_t
+megasas_ldio_outstanding_show(struct device *cdev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct Scsi_Host *shost = class_to_shost(cdev);
+ struct megasas_instance *instance = (struct megasas_instance
*)shost->hostdata;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n",
atomic_read(&instance->ldio_outstanding));
+}
+
static DEVICE_ATTR(fw_crash_buffer, S_IRUGO | S_IWUSR,
megasas_fw_crash_buffer_show, megasas_fw_crash_buffer_store);
static DEVICE_ATTR(fw_crash_buffer_size, S_IRUGO,
@@ -2949,12 +2963,15 @@ static DEVICE_ATTR(fw_crash_state, S_IRUGO | S_IWUSR,
megasas_fw_crash_state_show, megasas_fw_crash_state_store);
static DEVICE_ATTR(page_size, S_IRUGO,
megasas_page_size_show, NULL);
+static DEVICE_ATTR(ldio_outstanding, S_IRUGO,
+ megasas_ldio_outstanding_show, NULL);
struct device_attribute *megaraid_host_attrs[] = {
&dev_attr_fw_crash_buffer_size,
&dev_attr_fw_crash_buffer,
&dev_attr_fw_crash_state,
&dev_attr_page_size,
+ &dev_attr_ldio
[PATCH v2 05/15] megaraid_sas: Update device Queue depth based on interface type
This patch will update device Queue depth based on interface type(SAS, SATA..)
for sysPDs.
For Virtual disks(VDs), there will be no change in queue depth(will remain 256).
To fetch interface type(SAS or SATA or FC..) of syspD, driver will send DCMD
MR_DCMD_PD_GET_INFO per sysPD.
There are no changes in this patch from last time sent patch. There was some
feedback to use dma_alloc_coherent
instead of pci_alloc_consistent which will be handled in follow up along with
several other cases where
dma_alloc_coherent can be used.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas.h | 270 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 127 ++
2 files changed, 396 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 0fcb156..773fc54 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -215,6 +215,7 @@
#define MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS 0x01190100
#define MR_DRIVER_SET_APP_CRASHDUMP_MODE (0xF001 | 0x0600)
+#define MR_DCMD_PD_GET_INFO0x0202
/*
* Global functions
@@ -435,6 +436,257 @@ enum MR_PD_STATE {
MR_PD_STATE_SYSTEM = 0x40,
};
+union MR_PD_REF {
+ struct {
+ u16 deviceId;
+ u16 seqNum;
+ } mrPdRef;
+ u32 ref;
+};
+
+/*
+ * define the DDF Type bit structure
+ */
+union MR_PD_DDF_TYPE {
+struct {
+ union {
+ struct {
+#ifndef __BIG_ENDIAN_BITFIELD
+u16 forcedPDGUID:1;
+u16 inVD:1;
+u16 isGlobalSpare:1;
+u16 isSpare:1;
+u16 isForeign:1;
+u16 reserved:7;
+u16 intf:4;
+#else
+u16 intf:4;
+u16 reserved:7;
+u16 isForeign:1;
+u16 isSpare:1;
+u16 isGlobalSpare:1;
+u16 inVD:1;
+u16 forcedPDGUID:1;
+#endif
+} pdType;
+u16 type;
+};
+u16 reserved;
+} ddf;
+struct {
+u32reserved;
+} nonDisk;
+u32 type;
+} __packed;
+
+/*
+ * defines the progress structure
+ */
+union MR_PROGRESS {
+ struct {
+ u16 progress;
+ union {
+ u16 elapsedSecs;
+ u16 elapsedSecsForLastPercent;
+ };
+ } mrProgress;
+ u32 w;
+} __packed;
+
+/*
+ * defines the physical drive progress structure
+ */
+struct MR_PD_PROGRESS {
+ struct {
+#ifndef MFI_BIG_ENDIAN
+ u32 rbld:1;
+ u32 patrol:1;
+ u32 clear:1;
+ u32 copyBack:1;
+ u32 erase:1;
+ u32 locate:1;
+ u32 reserved:26;
+#else
+ u32 reserved:26;
+ u32 locate:1;
+ u32 erase:1;
+ u32 copyBack:1;
+ u32 clear:1;
+ u32 patrol:1;
+ u32 rbld:1;
+#endif
+ } active;
+ union MR_PROGRESS rbld;
+ union MR_PROGRESS patrol;
+ union {
+ union MR_PROGRESS clear;
+ union MR_PROGRESS erase;
+ };
+
+ struct {
+#ifndef MFI_BIG_ENDIAN
+ u32 rbld:1;
+ u32 patrol:1;
+ u32 clear:1;
+ u32 copyBack:1;
+ u32 erase:1;
+ u32 reserved:27;
+#else
+ u32 reserved:27;
+ u32 erase:1;
+ u32 copyBack:1;
+ u32 clear:1;
+ u32 patrol:1;
+ u32 rbld:1;
+#endif
+ } pause;
+
+ union MR_PROGRESS reserved[3];
+} __packed;
+
+struct MR_PD_INFO {
+ union MR_PD_REF ref;
+ u8 inquiryData[96];
+ u8 vpdPage83[64];
+ u8 notSupported;
+ u8 scsiDevType;
+
+ union {
+ u8 connectedPortBitmap;
+ u8 connectedPortNumbers;
+ };
+
+ u8 deviceSpeed;
+ u32 mediaErrCount;
+ u32 otherErrCount;
+ u32 predFailCount;
+ u32 lastPredFailEventSeqNum;
+
+ u16 fwState;
+ u8 disabledForRemoval;
+ u8 linkSpeed;
+ union MR_PD_DDF_TYPE state;
+
+ struct {
+ u8 count;
+#ifndef __BIG_ENDIAN_BITFIELD
+ u8 isPathBroken:4;
+ u8
[PATCH v2 12/15] megaraid_sas: MFI adapter's OCR changes
Optimized MFI adapters' OCR path, particularly megasas_wait_for_outstanding()
function.
Accomodated Tomas' comments provided on last time sent patch- remove redundant
checks when label- kill_hba_and_failed is being called.
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_base.c | 101 +++---
1 file changed, 50 insertions(+), 51 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 1bd5da4..d2ea977 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2455,15 +2455,19 @@ void megasas_sriov_heartbeat_handler(unsigned long
instance_addr)
*/
static int megasas_wait_for_outstanding(struct megasas_instance *instance)
{
- int i;
+ int i, sl, outstanding;
u32 reset_index;
u32 wait_time = MEGASAS_RESET_WAIT_TIME;
unsigned long flags;
struct list_head clist_local;
struct megasas_cmd *reset_cmd;
u32 fw_state;
- u8 kill_adapter_flag;
+ if (atomic_read(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR) {
+ dev_info(&instance->pdev->dev, "%s:%d HBA is killed.\n",
+ __func__, __LINE__);
+ return FAILED;
+ }
if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL) {
@@ -2520,7 +2524,7 @@ static int megasas_wait_for_outstanding(struct
megasas_instance *instance)
}
for (i = 0; i < resetwaittime; i++) {
- int outstanding = atomic_read(&instance->fw_outstanding);
+ outstanding = atomic_read(&instance->fw_outstanding);
if (!outstanding)
break;
@@ -2539,65 +2543,60 @@ static int megasas_wait_for_outstanding(struct
megasas_instance *instance)
}
i = 0;
- kill_adapter_flag = 0;
+ outstanding = atomic_read(&instance->fw_outstanding);
+ fw_state = instance->instancet->read_fw_status_reg(instance->reg_set) &
MFI_STATE_MASK;
+
+ if ((!outstanding && (fw_state == MFI_STATE_OPERATIONAL)))
+ goto no_outstanding;
+
+ if (instance->disableOnlineCtrlReset)
+ goto kill_hba_and_failed;
do {
- fw_state = instance->instancet->read_fw_status_reg(
- instance->reg_set) & MFI_STATE_MASK;
- if ((fw_state == MFI_STATE_FAULT) &&
- (instance->disableOnlineCtrlReset == 0)) {
- if (i == 3) {
- kill_adapter_flag = 2;
- break;
- }
+ if ((fw_state == MFI_STATE_FAULT) ||
atomic_read(&instance->fw_outstanding)) {
+ dev_info(&instance->pdev->dev,
+ "%s:%d waiting_for_outstanding: before issue
OCR. FW state = 0x%x, oustanding 0x%x\n",
+ __func__, __LINE__, fw_state,
atomic_read(&instance->fw_outstanding));
+ if (i == 3)
+ goto kill_hba_and_failed;
megasas_do_ocr(instance);
- kill_adapter_flag = 1;
- /* wait for 1 secs to let FW finish the pending cmds */
- msleep(1000);
+ if (atomic_read(&instance->adprecovery) ==
MEGASAS_HW_CRITICAL_ERROR) {
+ dev_info(&instance->pdev->dev, "%s:%d OCR
failed and HBA is killed.\n",
+ __func__, __LINE__);
+ return FAILED;
+ }
+ dev_info(&instance->pdev->dev, "%s:%d
waiting_for_outstanding: after issue OCR.\n",
+ __func__, __LINE__);
+
+ for (sl = 0; sl < 10; sl++)
+ msleep(500);
+
+ outstanding = atomic_read(&instance->fw_outstanding);
+
+ fw_state =
instance->instancet->read_fw_status_reg(instance->reg_set) & MFI_STATE_MASK;
+ if ((!outstanding && (fw_state ==
MFI_STATE_OPERATIONAL)))
+ goto no_outstanding;
}
i++;
} while (i <= 3);
- if (atomic_read(&instance->fw_outstanding) && !kill_adapter_flag) {
- if (instance->disableOnlineCtrlReset == 0) {
- megasas_do_ocr(instance);
+no_outstanding:
- /* wait for 5 secs to let FW finish the pending cmds */
- for (i = 0; i < wait_time; i++) {
- int outstanding =
- atomic_read(&instance->fw_outstanding);
- if (!outstanding)
- ret
[PATCH v2 10/15] megaraid_sas: IO throttling support
This patch will add capability in driver to tell firmware that it can throttle
IOs in case Controller's Queue depth is downgraded post OFU
(Online firmware upgrade). This feature will ensure firmware can be downgraded
from higher queue depth to lower queue depth without needing system reboot.
Added throttling code in IO path of driver, in case OS tries to send more IOs
than post OFU firmware's queue depth.
I have accomodated Tomas' comments provided on last time sent patch- removed
the un-necessary code of throttling of IOs against can_queue inside
function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways
does this.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas.h| 6 --
drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 2a2f491..c8d25a7 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1537,7 +1537,8 @@ union megasas_sgl_frame {
typedef union _MFI_CAPABILITIES {
struct {
#if defined(__BIG_ENDIAN_BITFIELD)
- u32 reserved:21;
+ u32 reserved:20;
+ u32 support_qd_throttling:1;
u32 support_fp_rlbypass:1;
u32 support_vfid_in_ioframe:1;
u32 support_ext_io_size:1;
@@ -1561,7 +1562,8 @@ typedef union _MFI_CAPABILITIES {
u32 support_ext_io_size:1;
u32 support_vfid_in_ioframe:1;
u32 support_fp_rlbypass:1;
- u32 reserved:21;
+ u32 support_qd_throttling:1;
+ u32 reserved:20;
#endif
} mfi_capabilities;
__le32 reg;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 6b8547c..2c4912f 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -803,6 +803,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
if (!dual_qdepth_disable)
drv_ops->mfi_capabilities.support_ext_queue_depth = 1;
+ drv_ops->mfi_capabilities.support_qd_throttling = 1;
/* Convert capability to LE32 */
cpu_to_le32s((u32 *)&init_frame->driver_operations.mfi_capabilities);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/15] megaraid_sas: Make adprecovery variable atomic
Make instance->adprecovery variable atomic and removes hba_lock spinlock while
accessing instance->adprecovery.
Tomas commented on last time sent patch asking to use u8 instead of atomic for
adprecovery. I agree that atomic_t is not required
here but this is done for not to touch legacy code of MFI adapters and replace
hba_lock with atomic_t so there are no changes
in this patch on top of last time sent patch.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas.h| 2 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 95 +++--
drivers/scsi/megaraid/megaraid_sas_fusion.c | 27
3 files changed, 50 insertions(+), 74 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index c8d25a7..3e92f20 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -2101,7 +2101,7 @@ struct megasas_instance {
u16 drv_supported_vd_count;
u16 drv_supported_pd_count;
- u8 adprecovery;
+ atomic_t adprecovery;
unsigned long last_time;
u32 mfiStatus;
u32 last_seq_num;
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 961c024..1bd5da4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -483,7 +483,7 @@ static int
megasas_check_reset_xscale(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
{
- if ((instance->adprecovery != MEGASAS_HBA_OPERATIONAL) &&
+ if ((atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL) &&
(le32_to_cpu(*instance->consumer) ==
MEGASAS_ADPRESET_INPROG_SIGN))
return 1;
@@ -619,7 +619,7 @@ static int
megasas_check_reset_ppc(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
{
- if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
+ if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
return 0;
@@ -756,7 +756,7 @@ static int
megasas_check_reset_skinny(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
{
- if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
+ if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
return 0;
@@ -950,9 +950,8 @@ static int
megasas_check_reset_gen2(struct megasas_instance *instance,
struct megasas_register_set __iomem *regs)
{
- if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) {
+ if (atomic_read(&instance->adprecovery) != MEGASAS_HBA_OPERATIONAL)
return 1;
- }
return 0;
}
@@ -998,7 +997,7 @@ megasas_issue_polled(struct megasas_instance *instance,
struct megasas_cmd *cmd)
frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS;
frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE);
- if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+ if ((atomic_read(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(&instance->pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1026,7 +1025,7 @@ megasas_issue_blocked_cmd(struct megasas_instance
*instance,
int ret = 0;
cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS;
- if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+ if ((atomic_read(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(&instance->pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1090,7 +1089,7 @@ megasas_issue_blocked_abort_cmd(struct megasas_instance
*instance,
cmd->sync_cmd = 1;
cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS;
- if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+ if ((atomic_read(&instance->adprecovery) == MEGASAS_HW_CRITICAL_ERROR)
||
(instance->instancet->issue_dcmd(instance, cmd))) {
dev_err(&instance->pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
@@ -1653,7 +1652,6 @@ static int
megasas_queue_command(struct Scsi_Host *shost, struct scsi_cmnd *scmd)
{
struct megasas_instance *instance;
- unsigned long flags;
struct MR_PRIV_DEVICE *mr_device_priv_data;
instance = (struct megasas_instance *)
@@ -1668,24 +1666,20 @@ megasas_queue_command(struct Scsi_Host *shost, struct
scsi_cmnd *scmd)
if (instance->issuepend_done == 0)
return SCSI_MLQUEUE_HOST_BUSY;
- spin_lock_irqsave(&instance->hba_lock, flags);
[PATCH v2 08/15] megaraid_sas: Code optimization build_and_issue_cmd return-type
build_and_issue_cmd should return SCSI_MLQUEUE_HOST_BUSY for few error case
instead of returning 1.
There are no changes in this patch from last time sent patch.
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_base.c | 9 ++---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 4 ++--
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 8df58c2..edf8911 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1636,7 +1636,7 @@ megasas_build_and_issue_cmd(struct megasas_instance
*instance,
return 0;
out_return_cmd:
megasas_return_cmd(instance, cmd);
- return 1;
+ return SCSI_MLQUEUE_HOST_BUSY;
}
@@ -1728,12 +1728,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct
scsi_cmnd *scmd)
break;
}
- if (instance->instancet->build_and_issue_cmd(instance, scmd)) {
- dev_err(&instance->pdev->dev, "Err returned from
build_and_issue_cmd\n");
- return SCSI_MLQUEUE_HOST_BUSY;
- }
-
- return 0;
+ return instance->instancet->build_and_issue_cmd(instance, scmd);
out_done:
scmd->scsi_done(scmd);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 1351cae..f553830 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2125,7 +2125,7 @@ megasas_build_and_issue_cmd_fusion(struct
megasas_instance *instance,
req_desc = megasas_get_request_descriptor(instance, index-1);
if (!req_desc)
- return 1;
+ return SCSI_MLQUEUE_HOST_BUSY;
req_desc->Words = 0;
cmd->request_desc = req_desc;
@@ -2134,7 +2134,7 @@ megasas_build_and_issue_cmd_fusion(struct
megasas_instance *instance,
megasas_return_cmd_fusion(instance, cmd);
dev_err(&instance->pdev->dev, "Error building command\n");
cmd->request_desc = NULL;
- return 1;
+ return SCSI_MLQUEUE_HOST_BUSY;
}
req_desc = cmd->request_desc;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/15] megaraid_sas: SPERC OCR changes
This patch will do some fixes in OCR path of SRIOV enabled series of Avago
controllers.
1)Removing late detection HB.
2)Change in the behavior if the FW found in READY/OPERAETIONAL state.
There are no changes in this patch from last time sent patch.
Signed-off-by: Uday Lingala
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 73 +++--
1 file changed, 16 insertions(+), 57 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index e740e26..be9c3f1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3462,52 +3462,7 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int
reason)
/* Let SR-IOV VF & PF sync up if there was a HB failure */
if (instance->requestorId && !reason) {
msleep(MEGASAS_OCR_SETTLE_TIME_VF);
- /* Look for a late HB update after VF settle time */
- if (abs_state == MFI_STATE_OPERATIONAL &&
- (instance->hb_host_mem->HB.fwCounter !=
-instance->hb_host_mem->HB.driverCounter)) {
- instance->hb_host_mem->HB.driverCounter
=
-
instance->hb_host_mem->HB.fwCounter;
- dev_warn(&instance->pdev->dev, "SR-IOV:"
- "Late FW heartbeat update for "
- "scsi%d.\n",
- instance->host->host_no);
- } else {
- /* In VF mode, first poll for FW ready */
- for (i = 0;
-i < (MEGASAS_RESET_WAIT_TIME * 1000);
-i += 20) {
- status_reg =
- instance->instancet->
- read_fw_status_reg(
- instance->reg_set);
- abs_state = status_reg &
- MFI_STATE_MASK;
- if (abs_state == MFI_STATE_READY) {
- dev_warn(&instance->pdev->dev,
- "SR-IOV: FW was found"
- "to be in ready state "
- "for scsi%d.\n",
- instance->host->host_no);
- break;
- }
- msleep(20);
- }
- if (abs_state != MFI_STATE_READY) {
- dev_warn(&instance->pdev->dev, "SR-IOV:
"
- "FW not in ready state after %d"
- " seconds for scsi%d, status_reg
= "
- "0x%x.\n",
- MEGASAS_RESET_WAIT_TIME,
- instance->host->host_no,
- status_reg);
- megaraid_sas_kill_hba(instance);
- instance->skip_heartbeat_timer_del = 1;
- atomic_set(&instance->adprecovery,
MEGASAS_HW_CRITICAL_ERROR);
- retval = FAILED;
- goto out;
- }
- }
+ goto transition_to_ready;
}
/* Now try to reset the chip */
@@ -3516,25 +3471,28 @@ int megasas_reset_fusion(struct Scsi_Host *shost, int
reason)
if (instance->instancet->adp_reset
(instance, instance->reg_set))
continue;
-
+transition_to_ready:
/* Wait for FW to become ready */
if (megasas_transition_to_ready(instance, 1)) {
- dev_warn(&instance->pdev->dev, "Failed to "
- "transition controller to ready "
- "for scsi%d.\n",
- instance->host->host_no);
- continue;
+ dev_warn(&instance->pdev->dev,
+ "Failed t
[PATCH v2 04/15] megaraid_sas: Task management support
This patch will add task management(TM) support for SCSI commands in
megaraid_sas driver.
Added TM functions are below-
1)Task abort
2)Target reset
Below are few key points-
1. Currently, megaraid_sas driver performs Controller reset when any IO times
out.
With these TM support added in driver, in case of IO timeout task abort and
target
reset will be tried to recover timed out IO. If both fails to recover IO, then
Controller reset will be called. If the TM request times out, fail the TM and
escalate
to the next level(Controller reset).
2. mr_device_priv_data will be allocated for all generation of controller, but
is_tm_capable
flag will never be set for older controllers (prior to Invader series) as
firmware support is not
available for T.M functionality.
3. whichever firmware is capable for TM will set is_tm_capable flag in firmware
API, which will be used
by Driver to pass TM frame to firmware or return back to OS as Failure to
escalate next level of Error handling.
Additionally, Tomas Henzl's feedback has been accomodated in this patch- return
MFI frame used for task management(TM)
in case of TM timeout and error cases.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
drivers/scsi/megaraid/megaraid_sas.h| 13 +
drivers/scsi/megaraid/megaraid_sas_base.c | 60 +++-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 474 +++-
drivers/scsi/megaraid/megaraid_sas_fusion.h | 117 ++-
4 files changed, 646 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index dcc6ff8..0fcb156 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1520,6 +1520,15 @@ union megasas_frame {
u8 raw_bytes[64];
};
+/**
+ * struct MR_PRIV_DEVICE - sdev private hostdata
+ * @is_tm_capable: firmware managed tm_capable flag
+ * @tm_busy: TM request is in progress
+ */
+struct MR_PRIV_DEVICE {
+ bool is_tm_capable;
+ bool tm_busy;
+};
struct megasas_cmd;
union megasas_evt_class_locale {
@@ -2073,4 +2082,8 @@ void megasas_return_mfi_mpt_pthr(struct megasas_instance
*instance,
int megasas_cmd_type(struct scsi_cmnd *cmd);
void megasas_setup_jbod_map(struct megasas_instance *instance);
+void megasas_update_sdev_properties(struct scsi_device *sdev);
+int megasas_reset_fusion(struct Scsi_Host *shost, int reason);
+int megasas_task_abort_fusion(struct scsi_cmnd *scmd);
+int megasas_reset_target_fusion(struct scsi_cmnd *scmd);
#endif /*LSI_MEGARAID_SAS_H */
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 380c627..57cf4e3 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -189,7 +189,6 @@ int
wait_and_poll(struct megasas_instance *instance, struct megasas_cmd *cmd,
int seconds);
void megasas_reset_reply_desc(struct megasas_instance *instance);
-int megasas_reset_fusion(struct Scsi_Host *shost, int iotimeout);
void megasas_fusion_ocr_wq(struct work_struct *work);
static int megasas_get_ld_vf_affiliation(struct megasas_instance *instance,
int initial);
@@ -1645,6 +1644,7 @@ megasas_queue_command(struct Scsi_Host *shost, struct
scsi_cmnd *scmd)
{
struct megasas_instance *instance;
unsigned long flags;
+ struct MR_PRIV_DEVICE *mr_device_priv_data;
instance = (struct megasas_instance *)
scmd->device->host->hostdata;
@@ -1681,11 +1681,24 @@ megasas_queue_command(struct Scsi_Host *shost, struct
scsi_cmnd *scmd)
return 0;
}
+ mr_device_priv_data = scmd->device->hostdata;
+ if (!mr_device_priv_data) {
+ spin_unlock_irqrestore(&instance->hba_lock, flags);
+ scmd->result = DID_NO_CONNECT << 16;
+ scmd->scsi_done(scmd);
+ return 0;
+ }
+
if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) {
spin_unlock_irqrestore(&instance->hba_lock, flags);
return SCSI_MLQUEUE_HOST_BUSY;
}
+ if (mr_device_priv_data->tm_busy) {
+ spin_unlock_irqrestore(&instance->hba_lock, flags);
+ return SCSI_MLQUEUE_DEVICE_BUSY;
+ }
+
spin_unlock_irqrestore(&instance->hba_lock, flags);
scmd->result = 0;
@@ -1736,27 +1749,39 @@ static struct megasas_instance
*megasas_lookup_instance(u16 host_no)
}
/*
-* megasas_set_dma_alignment - Set DMA alignment for PI enabled VD
+* megasas_update_sdev_properties - Update sdev structure based on controller's
FW capabilities
*
* @sdev: OS provided scsi device
*
* Returns void
*/
-static void megasas_set_dma_alignment(struct scsi_device *sdev)
+void megasas_update_sdev_properties(struct scsi_device *sdev)
{
+ u16 pd_index = 0;
u32 device_id, ld;
struct megasas_instance *inst
[PATCH v2 02/15] megaraid_sas: MFI IO timeout handling
This patch will do proper error handling for DCMD timeout and failed cases for
fusion adapters.
Below are few key design points-
1. For MFI adapters, in case of DCMD timeout(DCMD which must return SUCCESS)
driver will call kill adapter.
2. What action needs to be taken in case of DCMD timeout is decided by function
dcmd_timeout_ocr_possible().
DCMD timeout causing OCR is applicable to below DCMDs-
MR_DCMD_PD_LIST_QUERY
MR_DCMD_LD_GET_LIST
MR_DCMD_LD_LIST_QUERY
MR_DCMD_CTRL_SET_CRASH_DUMP_PARAMS
MR_DCMD_SYSTEM_PD_MAP_GET_INFO(for non pended DCMD)
MR_DCMD_LD_MAP_GET_INFO(for non pended DCMD)
3. If DCMD fails from Driver init path, there are certain DCMD which is must to
be return SUCCESS. If those DCMD fails,
driver bail out load. For optional DCMD like pd_info etc, driver continue
without executing certain functionality.
There are no changes in this patch from last time sent patch.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas.h| 22 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 372 +---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 54 ++--
3 files changed, 338 insertions(+), 110 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index ef4ff03..dcc6ff8 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -170,6 +170,7 @@
/* Driver internal */
#define DRV_DCMD_POLLED_MODE 0x1
+#define DRV_DCMD_SKIP_REFIRE 0x2
/*
* Definition for cmd_status
@@ -1093,6 +1094,11 @@ enum MR_SCSI_CMD_TYPE {
NON_READ_WRITE_SYSPDIO = 3,
};
+enum DCMD_TIMEOUT_ACTION {
+ INITIATE_OCR = 0,
+ KILL_ADAPTER = 1,
+ IGNORE_TIMEOUT = 2,
+};
/* Frame Type */
#define IO_FRAME 0
#define PTHRU_FRAME1
@@ -1139,6 +1145,7 @@ enum MR_SCSI_CMD_TYPE {
#define MFI_OB_INTR_STATUS_MASK0x0002
#define MFI_POLL_TIMEOUT_SECS 60
+#define MFI_IO_TIMEOUT_SECS180
#define MEGASAS_SRIOV_HEARTBEAT_INTERVAL_VF(5 * HZ)
#define MEGASAS_OCR_SETTLE_TIME_VF (1000 * 30)
#define MEGASAS_ROUTINE_WAIT_TIME_VF 300
@@ -1918,7 +1925,7 @@ struct megasas_instance_template {
u32 (*init_adapter)(struct megasas_instance *);
u32 (*build_and_issue_cmd) (struct megasas_instance *,
struct scsi_cmnd *);
- void (*issue_dcmd) (struct megasas_instance *instance,
+ int (*issue_dcmd)(struct megasas_instance *instance,
struct megasas_cmd *cmd);
};
@@ -2016,6 +2023,19 @@ struct megasas_mgmt_info {
int max_index;
};
+enum MEGASAS_OCR_CAUSE {
+ FW_FAULT_OCR= 0,
+ SCSIIO_TIMEOUT_OCR = 1,
+ MFI_IO_TIMEOUT_OCR = 2,
+};
+
+enum DCMD_RETURN_STATUS {
+ DCMD_SUCCESS= 0,
+ DCMD_TIMEOUT= 1,
+ DCMD_FAILED = 2,
+ DCMD_NOT_FIRED = 3,
+};
+
u8
MR_BuildRaidContext(struct megasas_instance *instance,
struct IO_REQUEST_INFO *io_info,
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9650487..380c627 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -196,11 +196,12 @@ static int megasas_get_ld_vf_affiliation(struct
megasas_instance *instance,
int megasas_check_mpio_paths(struct megasas_instance *instance,
struct scsi_cmnd *scmd);
-void
+int
megasas_issue_dcmd(struct megasas_instance *instance, struct megasas_cmd *cmd)
{
instance->instancet->fire_cmd(instance,
cmd->frame_phys_addr, 0, instance->reg_set);
+ return 0;
}
/**
@@ -983,25 +984,20 @@ extern struct megasas_instance_template
megasas_instance_template_fusion;
int
megasas_issue_polled(struct megasas_instance *instance, struct megasas_cmd
*cmd)
{
- int seconds;
struct megasas_header *frame_hdr = &cmd->frame->hdr;
- frame_hdr->cmd_status = MFI_CMD_STATUS_POLL_MODE;
+ frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS;
frame_hdr->flags |= cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE);
- /*
-* Issue the frame using inbound queue port
-*/
- instance->instancet->issue_dcmd(instance, cmd);
+ if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
+ (instance->instancet->issue_dcmd(instance, cmd))) {
+ dev_err(&instance->pdev->dev, "Failed from %s %d\n",
+ __func__, __LINE__);
+ return DCMD_NOT_FIRED;
+ }
- /*
-* Wait for cmd_status to change
-*/
- if (instance->requestorId)
- seconds = MEGASAS_ROUTINE_WAIT_TI
[PATCH v2 01/15] megaraid_sas: Do not allow PCI access during OCR
This patch will do synhronization between OCR function and AEN function using
"reset_mutex" lock.
reset_mutex will be acquire only in first half of the AEN function which issue
DCMD. Second half
of the function calls SCSI API (scsi_add_device/scsi_remove_device) should be
out of reset_mutex
to avoid deadlock between scsi_eh thread and Driver.
During chip reset(inside OCR function), there should not be any PCI access and
AEN function
(which is called in delayed context) may be firirng DCMDs(doing PCI writes)
when chip reset is
happening in parallel which will cause FW fault. This patch will solve the
problem by making
AEN thread and OCR thread mutually exclusive.
There are no changes in this patch from last time sent patch.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas.h | 2 +
drivers/scsi/megaraid/megaraid_sas_base.c | 254 ++
2 files changed, 82 insertions(+), 174 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index c0f7c8c..ef4ff03 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -1083,6 +1083,8 @@ struct megasas_ctrl_info {
#define VD_EXT_DEBUG 0
+#define SCAN_PD_CHANNEL0x1
+#define SCAN_VD_CHANNEL0x2
enum MR_SCSI_CMD_TYPE {
READ_WRITE_LDIO = 0,
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 97a1c1c..9650487 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5476,7 +5476,6 @@ static int megasas_probe_one(struct pci_dev *pdev,
spin_lock_init(&instance->hba_lock);
spin_lock_init(&instance->completion_lock);
- mutex_init(&instance->aen_mutex);
mutex_init(&instance->reset_mutex);
/*
@@ -6442,10 +6441,10 @@ static int megasas_mgmt_ioctl_aen(struct file *file,
unsigned long arg)
}
spin_unlock_irqrestore(&instance->hba_lock, flags);
- mutex_lock(&instance->aen_mutex);
+ mutex_lock(&instance->reset_mutex);
error = megasas_register_aen(instance, aen.seq_num,
aen.class_locale_word);
- mutex_unlock(&instance->aen_mutex);
+ mutex_unlock(&instance->reset_mutex);
return error;
}
@@ -6647,6 +6646,7 @@ megasas_aen_polling(struct work_struct *work)
int i, j, doscan = 0;
u32 seq_num, wait_time = MEGASAS_RESET_WAIT_TIME;
int error;
+ u8 dcmd_ret = 0;
if (!instance) {
printk(KERN_ERR "invalid instance!\n");
@@ -6659,16 +6659,7 @@ megasas_aen_polling(struct work_struct *work)
wait_time = MEGASAS_ROUTINE_WAIT_TIME_VF;
/* Don't run the event workqueue thread if OCR is running */
- for (i = 0; i < wait_time; i++) {
- if (instance->adprecovery == MEGASAS_HBA_OPERATIONAL)
- break;
- if (!(i % MEGASAS_RESET_NOTICE_INTERVAL)) {
- dev_notice(&instance->pdev->dev, "%s waiting for "
- "controller reset to finish for scsi%d\n",
- __func__, instance->host->host_no);
- }
- msleep(1000);
- }
+ mutex_lock(&instance->reset_mutex);
instance->ev = NULL;
host = instance->host;
@@ -6676,212 +6667,127 @@ megasas_aen_polling(struct work_struct *work)
megasas_decode_evt(instance);
switch (le32_to_cpu(instance->evt_detail->code)) {
- case MR_EVT_PD_INSERTED:
- if (megasas_get_pd_list(instance) == 0) {
- for (i = 0; i < MEGASAS_MAX_PD_CHANNELS; i++) {
- for (j = 0;
- j < MEGASAS_MAX_DEV_PER_CHANNEL;
- j++) {
-
- pd_index =
- (i * MEGASAS_MAX_DEV_PER_CHANNEL) + j;
-
- sdev1 = scsi_device_lookup(host, i, j, 0);
-
- if (instance->pd_list[pd_index].driveState
- == MR_PD_STATE_SYSTEM) {
- if (!sdev1)
- scsi_add_device(host, i, j, 0);
-
- if (sdev1)
- scsi_device_put(sdev1);
- }
- }
- }
- }
- doscan = 0;
- break;
+ case MR_EVT_PD_INSERTED:
case MR_EVT_PD_REMOVED:
- if (megasas_get_pd_list(instance) == 0) {
- for (i = 0; i < MEGASAS_MAX_PD_
[PATCH v2 03/15] megaraid_sas: Syncing request flags macro names with firmware
There are no changes in this patch from last time sent patch.
Signed-off-by: Sumit Saxena
Reviewed-by: Tomas Henzl
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 6 +++---
drivers/scsi/megaraid/megaraid_sas_fusion.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 6e48707..1dc4537 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -1666,7 +1666,7 @@ megasas_build_ldio_fusion(struct megasas_instance
*instance,
local_map_ptr, start_lba_lo);
io_request->Function = MPI2_FUNCTION_SCSI_IO_REQUEST;
cmd->request_desc->SCSIIO.RequestFlags =
- (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY
+ (MPI2_REQ_DESCRIPT_FLAGS_FP_IO
<< MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
if (fusion->adapter_type == INVADER_SERIES) {
if (io_request->RaidContext.regLockFlags ==
@@ -1799,7 +1799,7 @@ static void megasas_build_ld_nonrw_fusion(struct
megasas_instance *instance,
/* build request descriptor */
cmd->request_desc->SCSIIO.RequestFlags =
- (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY <<
+ (MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
cmd->request_desc->SCSIIO.DevHandle = devHandle;
@@ -1905,7 +1905,7 @@ megasas_build_syspd_fusion(struct megasas_instance
*instance,
cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
}
cmd->request_desc->SCSIIO.RequestFlags =
- (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY <<
+ (MPI2_REQ_DESCRIPT_FLAGS_FP_IO <<
MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
}
}
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.h
b/drivers/scsi/megaraid/megaraid_sas_fusion.h
index 473005c..a9e10c4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.h
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.h
@@ -176,7 +176,8 @@ enum REGION_TYPE {
#define MPI2_SCSIIO_EEDPFLAGS_CHECK_GUARD (0x0100)
#define MPI2_SCSIIO_EEDPFLAGS_INSERT_OP (0x0004)
#define MPI2_FUNCTION_SCSI_IO_REQUEST (0x00) /* SCSI IO */
-#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY (0x06)
+#define MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY (0x03)
+#define MPI2_REQ_DESCRIPT_FLAGS_FP_IO (0x06)
#define MPI2_REQ_DESCRIPT_FLAGS_SCSI_IO (0x00)
#define MPI2_SGE_FLAGS_64_BIT_ADDRESSING(0x02)
#define MPI2_SCSIIO_CONTROL_WRITE (0x0100)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/15] megaraid_sas: Updates for scsi-next
Changes between v1 and v2: -Addressed comments provided by Tomas Henzl. -Return MFI frame used for task management(TM) in case of TM timeout and error cases. -Fixed few error handling cases inside functions- megasas_alloc_cmdlist_fusion() and megasas_alloc_cmds_fusion(), fix typo- disable(old- disbale) in rdpq_enable module parameter's description, modify print to reflect RDPQ support statement correctly. -Used atomic_inc_return instead of using atomic_read() and atomic_inc() separately inside function- megasas_build_and_issue_cmd_fusion(). -Removed the un-necessary code of throttling of IOs against can_queue inside function- megasas_build_and_issue_cmd_fusion() as SCSI mid layer will anyways does this. -Removed redundant checks when label- kill_hba_and_failed is being called. -Removed one patch- *[PATCH 15/15] megaraid_sas: SPERC boot driver reorder* from v2 patchset as that was rejected. -Added one new patch for driver version upgrade. Sumit Saxena (15): megaraid_sas: Do not allow PCI access during OCR megaraid_sas: MFI IO timeout handling megaraid_sas: Syncing request flags macro names with firmware megaraid_sas: Task management support megaraid_sas: Update device Queue depth based on interface type megaraid_sas: Fastpath region lock bypass megaraid_sas: Reply Descriptor Post Queue(RDPQ) support megaraid_sas: Code optimization build_and_issue_cmd return-type megaraid_sas: Dual Queue depth support megaraid_sas: IO throttling support megaraid_sas: Make adprecovery variable atomic megaraid_sas: MFI adapter's OCR changes megaraid_sas: Introduce module parameter for SCSI command-timeout megaraid_sas: SPERC OCR changes megaraid_sas: driver version upgrade drivers/scsi/megaraid/megaraid_sas.h| 338 +++- drivers/scsi/megaraid/megaraid_sas_base.c | 1034 ++ drivers/scsi/megaraid/megaraid_sas_fp.c |2 + drivers/scsi/megaraid/megaraid_sas_fusion.c | 1244 --- drivers/scsi/megaraid/megaraid_sas_fusion.h | 136 ++- 5 files changed, 2027 insertions(+), 727 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] LIO/SCST Merger
On 01/27/16 22:37, Nicholas A. Bellinger wrote: [ ... ] Hi Nic, Since in the most recent years all my communication to you was neutral and professional in tone it is not clear to me why you wrote such a misleading and unfair e-mail. Anyway, I would like to point out that the following information is missing from your e-mail: - That last year the storage HBA vendors and Linux distributor representatives who attended my session about this topic where unanimously enthusiastic about my proposal. You were the only attendee who was not (yet?) enthusiast. - That I am working on sending the ib_srpt patches upstream you referred to in your e-mail and that a first version of that patch series has already been posted on the linux-rdma mailing list. - Although five years ago some SCST users switched to LIO, recently several LIO users switched back to SCST because the latter is still more stable and easier to configure than LIO. In other words, it is in your own interest to help the LIO patches upstream that I posted recently. - One of the reasons that the LIO core patches I'm working on are not yet upstream is because of how long it takes before you as a maintainer provide feedback. The first version of my patch to make ABORT and LUN RESET handling synchronous was posted on October 12, 2015. It took until November 15, 2015 before I received the first feedback from you for that patch. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lsf-pc] [LSF/MM TOPIC] NVMe target support
On Thu, 2016-01-28 at 07:16 -0800, Bart Van Assche wrote: > On 01/27/16 20:41, Nicholas A. Bellinger wrote: > > [ ... ] > > The folks for such a discussion would include: > > > > Christoph Hellwig, Hannes Reinecke, Dave Minturn, Sagi > > Grimberg, > > Ming Lin, Roland Dreier and Mike Christie. > > Hello Nic, > > Since the LSF/MM summit is organized by the Linux Foundation This is a misperception. LSF/MM is organised by a group of volunteers as a Linux Kernel mini summit to discuss current topics around those subsystems. > and since one of the goals of the Linux Foundation is to promote > Linux I think every company that is active in both the NVMeOF > committee and in the Linux kernel community should be invited. We use the LF to do the logistics, but it's in no way controlled by them or aligned with their member companies. The first LSF/MM was aided logistically by google, the next by Intel, then USENIX for a while and now the LF. I certainly wouldn't be in favour of turning LSF/MM into a corporate discussion forum ... that's what standards bodies are for. James > That includes but is not limited to companies like Oracle, Micron, > EMC, NetApp, HGST and also my own employer SanDisk (see e.g. > http://www.nvmexpress.org/). > > Thanks, > > Bart. > ___ > Lsf-pc mailing list > lsf...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] NVMe target support
On 01/27/16 20:41, Nicholas A. Bellinger wrote: [ ... ] The folks for such a discussion would include: Christoph Hellwig, Hannes Reinecke, Dave Minturn, Sagi Grimberg, Ming Lin, Roland Dreier and Mike Christie. Hello Nic, Since the LSF/MM summit is organized by the Linux Foundation and since one of the goals of the Linux Foundation is to promote Linux I think every company that is active in both the NVMeOF committee and in the Linux kernel community should be invited. That includes but is not limited to companies like Oracle, Micron, EMC, NetApp, HGST and also my own employer SanDisk (see e.g. http://www.nvmexpress.org/). Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[LSF/MM ATTEND] dm-multipath, nvme, (remote) pmem and friends
Hi, I'd like to attend LSF/MM 2016. I've been working on scsi rdma transports and the target stack for some time now. Lately I've been looking at nvme as well and I think I can contribute to the dm-multipath discussions in the context of nvme and blk-mq performance. If we plan to talk about nvme target then I think I can contribute to the discussion as well. In addition as an active contributor to the RDMA stack, I'm very interested in discussing the possibilities of remote access to persistent memory devices suggested by Chuck. I suspect we'll gradually see more and more applications utilizing such a model and it would be very beneficial if we can come up with something general enough for everyone to use. Cheers, Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: iscsi fails to attach to targets with kernel 4.4.0
Hello folks, I was wondering if you could take a look at the problem I have encountered while running iscsi deamon with kernel 4.4.0. I have posted this issue to LKLM.org but so far I have not seen any replies. Here is my original post: https://lkml.org/lkml/2016/1/25/572 The issue is whenever iscsi tries to attach remote iscsi target, there is this traceback generated in dmesg buffer and it fails to attach. Here is the traceback and it is 100% reproducible. I would appreciate if you let me know if it is a known issue and if there is a patch to address it. [ 4693.175319] WARNING: CPU: 27 PID: 17353 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80() [ 4693.175320] sysfs: cannot create duplicate filename '/bus/scsi/devices/8:0:0:0' [ 4693.175321] Modules linked in: target_core_user target_core_pscsi target_core_file target_core_iblock binfmt_misc xt_REDIRECT nf_nat_redirect xt_nat xt_mark xt_conntrack xt_CHECKSUM iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iscsi_tcp libiscsi_tcp bnx2fc cnic uio fcoe 8021q garp mrp openvswitch nf_defrag_ipv6 bonding rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad usnic_verbs ib_core ib_addr xt_comment xt_multiport iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul aesni_intel [ 4693.175362] lrw gf128mul glue_helper ablk_helper cryptd ipmi_devintf ses enclosure sg ipmi_si 8250_fintek ipmi_msghandler joydev input_leds sb_edac iTCO_wdt iTCO_vendor_support pcspkr shpchp lpc_ich edac_core mfd_core wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs libcrc32c sd_mod crc32c_intel mgag200 megaraid_sas drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm libfcoe libfc scsi_transport_fc enic ixgbe(O) i40e vxlan ip6_udp_tunnel igb udp_tunnel ptp pps_core dca i2c_algo_bit fjes dm_mirror dm_region_hash dm_log dm_mod [last unloaded: fnic] [ 4693.175391] CPU: 27 PID: 17353 Comm: iscsiadm Tainted: G W O 4.4.0-1.el7.elrepo.x86_64 #1 [ 4693.175392] Hardware name: Cisco Systems Inc UCSC-C240-M3S/UCSC-C240-M3S, BIOS C240M3.2.0.8.0.071620152208 07/16/2015 [ 4693.175393] e6fae80d 885cff49b948 813273f0 [ 4693.175395] 885cff49b990 885cff49b980 8107c816 882c2b7e5000 [ 4693.175396] 882fa36885d0 885fa53b8d98 0001 ffef [ 4693.175398] Call Trace: [ 4693.175402] [] dump_stack+0x44/0x64 [ 4693.175405] [] warn_slowpath_common+0x86/0xc0 [ 4693.175407] [] warn_slowpath_fmt+0x5c/0x80 [ 4693.175409] [] ? kernfs_path+0x48/0x60 [ 4693.175410] [] sysfs_warn_dup+0x64/0x80 [ 4693.175412] [] sysfs_do_create_link_sd.isra.2+0xaa/0xb0 [ 4693.175414] [] sysfs_create_link+0x25/0x40 [ 4693.175417] [] bus_add_device+0x10b/0x1f0 [ 4693.175419] [] device_add+0x3b5/0x610 [ 4693.175422] [] scsi_sysfs_add_sdev+0xa5/0x290 [ 4693.175424] [] scsi_probe_and_add_lun+0xb65/0xd80 [ 4693.175427] [] ? __pm_runtime_resume+0x5c/0x70 [ 4693.175429] [] __scsi_scan_target+0xf7/0x260 [ 4693.175430] [] ? __pm_runtime_resume+0x5c/0x70 [ 4693.175432] [] scsi_scan_target+0xd7/0xf0 [ 4693.175440] [] iscsi_user_scan_session.part.14+0x105/0x140 [scsi_transport_iscsi] [ 4693.175443] [] ? iscsi_user_scan_session.part.14+0x140/0x140 [scsi_transport_iscsi] [ 4693.175446] [] iscsi_user_scan_session+0x1e/0x30 [scsi_transport_iscsi] [ 4693.175448] [] device_for_each_child+0x50/0x90 [ 4693.175451] [] iscsi_user_scan+0x3d/0x60 [scsi_transport_iscsi] [ 4693.175453] [] store_scan+0xa6/0x100 [ 4693.175456] [] ? __kmalloc+0x1b8/0x250 [ 4693.175458] [] dev_attr_store+0x18/0x30 [ 4693.175459] [] sysfs_kf_write+0x3a/0x50 [ 4693.175461] [] kernfs_fop_write+0x120/0x170 [ 4693.175464] [] __vfs_write+0x37/0x100 [ 4693.175467] [] ? selinux_file_permission+0xc3/0x110 [ 4693.175469] [] ? security_file_permission+0x3d/0xc0 [ 4693.175485] [] ? percpu_down_read+0x1f/0x50 [ 4693.175486] [] vfs_write+0xa2/0x1a0 [ 4693.175489] [] ? do_audit_syscall_entry+0x66/0x70 [ 4693.175491] [] SyS_write+0x55/0xc0 [ 4693.175493] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 4693.175495] ---[ end trace 67e92c68518cd764 ]--- [ 4693.175516] scsi 8:0:0:0: failed to add device: -17 [ 4702.252060] scsi 8:0:0:0: Direct-Access LIO-ORG IBLOCK 4.0 PQ: 0 ANSI: 5 [ 4702.252482] [ cut here ] [ 4702.252488] WARNING: CPU: 2 PID: 17390 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80() [ 4702.252489] sysfs: cannot create duplicate filename '/bus/scsi/devices/8:0:0:0' [ 4702.252490] Modules linked in: target_core_user target_core_pscsi target_core_file target_core_iblock binfmt_misc xt_REDIRECT nf_nat_redirect xt_nat xt_mar
Re: [PATCH] add driver for DesignWare UFS Host Controller
Hi Joao, 2016-01-28 2:04 GMT+09:00 Joao Pinto : > - NOP_OUT is failing with OCS = 0x7 > > The OCS value is calculated in ufshcd_get_tr_ocs() in ufshcd.c. > I made a dump of the UTRD pointer where we can check the status = 7 ([2]). > > UTRD at: 7007c3e0 > @ [0]:2100 > @0004 [1]:93936a6a > @0008 [2]:0007 > @000c [3]:93936a6a > @0010 [4]:9f317400 > @0014 [5]: > @0018 [6]:00800080 > @001c [7]:01006a6a > > Did anyone have the same problem? Any hints to overcome this issue? I have seen similar problem when using UFS 2.0 controller. The ufs driver currently doesn't set correct command type field in UTP transfer request descriptor (bit 31:28 in DW0) for UFS 2.0 controller. I checked that your DesignWare UFS driver handles it correctly, so please try with that change. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mm: another VM_BUG_ON_PAGE(PageTail(page))
On Thu, Jan 28, 2016 at 11:55:14AM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 28, 2016 at 11:51 AM, Kirill A. Shutemov
> wrote:
> > On Thu, Jan 28, 2016 at 11:27:11AM +0100, Dmitry Vyukov wrote:
> >> Hello,
> >>
> >> The following program triggers VM_BUG_ON_PAGE(PageTail(page)):
> >>
> >> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> >> #include
> >> #include
> >> #include
> >> #include
> >>
> >> int main()
> >> {
> >> int fd;
> >>
> >> mmap((void*)0x2000, 4096, PROT_READ|PROT_WRITE,
> >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
> >> fd = open("/dev/sg1", O_RDONLY|O_SYNC|0x10);
> >> mmap((void*)0x20001000, 0x4000, PROT_READ|PROT_WRITE,
> >> MAP_PRIVATE|MAP_FIXED, fd, 0);
> >> mbind((void*)0x2000, 0x4000, 0x8002, (void*)0x20002ff8, 3660,
> >> MPOL_MF_STRICT|MPOL_MF_MOVE);
> >> return 0;
> >> }
> >
> > I don't have sg1 in my VM. I changed it to sg0 and it doesn't trigger an
> > issue: mbind() returns -EINVAL as it supposed to. Hm..
>
> I've attached my config, and here is how I start qemu:
>
> qemu-system-x86_64 -hda wheezy.img -net
> user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
> arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda debug
> earlyprintk=serial slub_debug=UZ" -enable-kvm -pidfile vm_pid -m 2G
> -numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 -smp
> sockets=2,cores=2,threads=1 -usb -usbdevice mouse -usbdevice tablet
> -soundhw all
Still no luck. :-/
Could you try patch below. I want to see what vm_flags are.
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 27d135408a22..93edf181f88a 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -548,8 +548,10 @@ retry:
goto retry;
}
- if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL))
+ if (flags & (MPOL_MF_MOVE | MPOL_MF_MOVE_ALL)) {
+ VM_BUG_ON_VMA(PageTail(page), vma);
migrate_page_add(page, qp->pagelist, flags);
+ }
}
pte_unmap_unlock(pte - 1, ptl);
cond_resched();
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/15] megaraid_sas: Introduce module parameter for SCSI command-timeout
> -Original Message- > From: Tomas Henzl [mailto:the...@redhat.com] > Sent: Tuesday, January 19, 2016 8:27 PM > To: Sumit Saxena; jbottom...@parallels.com; h...@infradead.org; > martin.peter...@oracle.com > Cc: linux-scsi@vger.kernel.org; kashyap.de...@avagotech.com > Subject: Re: [PATCH 13/15] megaraid_sas: Introduce module parameter for SCSI > command-timeout > > On 18.12.2015 14:27, Sumit Saxena wrote: > > This patch will introduce module-parameter for SCSI command timeout value > and fix setting of resetwaitime beyond a value. > > > > Signed-off-by: Kashyap Desai > > Signed-off-by: Sumit Saxena > > --- > > drivers/scsi/megaraid/megaraid_sas_base.c | 15 --- > > drivers/scsi/megaraid/megaraid_sas_fusion.c |2 +- > > 2 files changed, 13 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > > b/drivers/scsi/megaraid/megaraid_sas_base.c > > index cc843d6..316d5a0 100644 > > --- a/drivers/scsi/megaraid/megaraid_sas_base.c > > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c > > @@ -83,7 +83,7 @@ module_param(throttlequeuedepth, int, S_IRUGO); > > MODULE_PARM_DESC(throttlequeuedepth, > > "Adapter queue depth when throttled due to I/O timeout. Default: > > 16"); > > > > -int resetwaittime = MEGASAS_RESET_WAIT_TIME; > > +unsigned int resetwaittime = MEGASAS_RESET_WAIT_TIME; > > module_param(resetwaittime, int, S_IRUGO); > > MODULE_PARM_DESC(resetwaittime, "Wait time in seconds after I/O timeout > " > > "before resetting adapter. Default: 180"); @@ -100,6 +100,10 > @@ > > unsigned int dual_qdepth_disable; module_param(dual_qdepth_disable, > > int, S_IRUGO); MODULE_PARM_DESC(dual_qdepth_disable, "Disable dual > > queue depth feature. Default: 0"); > > > > +unsigned int scmd_timeout = MEGASAS_DEFAULT_CMD_TIMEOUT; > > +module_param(scmd_timeout, int, S_IRUGO); > > +MODULE_PARM_DESC(scmd_timeout, "scsi command timeout (10-90s), > > +default 90s. See megasas_reset_timer."); > > When you know that "The RAID firmware may require extended timeouts" what > do you expect when an user sets a short timeout value ? The requirement here was to have scmd_timeout be tunable at driver load time so have to add Module parameter to do so. > Other than that, I don't think that lot of tunables in a driver makes it better, from > my point of view you could remove both resetwaittime + scmd_timeout. > Okay, I don't want to stay in the way if you really need it so - > > Reviewed-by: Tomas Henzl > > Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/15] megaraid_sas: MFI adapter's OCR changes
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Tuesday, January 19, 2016 7:53 PM
> To: Sumit Saxena; jbottom...@parallels.com; h...@infradead.org;
> martin.peter...@oracle.com
> Cc: linux-scsi@vger.kernel.org; kashyap.de...@avagotech.com
> Subject: Re: [PATCH 12/15] megaraid_sas: MFI adapter's OCR changes
>
> On 18.12.2015 14:27, Sumit Saxena wrote:
> > Optimized MFI adapters' OCR path, particularly
> megasas_wait_for_outstanding() function.
> >
> > Signed-off-by: Kashyap Desai
> > Signed-off-by: Sumit Saxena
> > ---
> > drivers/scsi/megaraid/megaraid_sas_base.c | 104
> > +++--
> > 1 files changed, 54 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> > b/drivers/scsi/megaraid/megaraid_sas_base.c
> > index 5eaf6fd..cc843d6 100644
> > --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> > @@ -2456,15 +2456,19 @@ void megasas_sriov_heartbeat_handler(unsigned
> long instance_addr)
> > */
> > static int megasas_wait_for_outstanding(struct megasas_instance
> > *instance) {
> > - int i;
> > + int i, sl, outstanding;
> > u32 reset_index;
> > u32 wait_time = MEGASAS_RESET_WAIT_TIME;
> > unsigned long flags;
> > struct list_head clist_local;
> > struct megasas_cmd *reset_cmd;
> > u32 fw_state;
> > - u8 kill_adapter_flag;
> >
> > + if (atomic_read(&instance->adprecovery) ==
> MEGASAS_HW_CRITICAL_ERROR) {
> > + dev_info(&instance->pdev->dev, "%s:%d HBA is killed.\n",
> > + __func__, __LINE__);
> > + return FAILED;
> > + }
> >
> > if (atomic_read(&instance->adprecovery) !=
> MEGASAS_HBA_OPERATIONAL)
> > {
> >
> > @@ -2521,7 +2525,7 @@ static int megasas_wait_for_outstanding(struct
> megasas_instance *instance)
> > }
> >
> > for (i = 0; i < resetwaittime; i++) {
> > - int outstanding = atomic_read(&instance->fw_outstanding);
> > + outstanding = atomic_read(&instance->fw_outstanding);
> >
> > if (!outstanding)
> > break;
> > @@ -2540,65 +2544,65 @@ static int megasas_wait_for_outstanding(struct
> megasas_instance *instance)
> > }
> >
> > i = 0;
> > - kill_adapter_flag = 0;
> > + outstanding = atomic_read(&instance->fw_outstanding);
> > + fw_state =
> > +instance->instancet->read_fw_status_reg(instance->reg_set) &
> > +MFI_STATE_MASK;
> > +
> > + if ((!outstanding && (fw_state == MFI_STATE_OPERATIONAL)))
> > + goto no_outstanding;
> > +
> > + if (instance->disableOnlineCtrlReset)
> > + goto kill_hba_and_failed;
> > do {
> > - fw_state = instance->instancet->read_fw_status_reg(
> > - instance->reg_set) &
> MFI_STATE_MASK;
> > - if ((fw_state == MFI_STATE_FAULT) &&
> > - (instance->disableOnlineCtrlReset == 0)) {
> > - if (i == 3) {
> > - kill_adapter_flag = 2;
> > - break;
> > - }
> > + if ((fw_state == MFI_STATE_FAULT) ||
atomic_read(&instance-
> >fw_outstanding)) {
> > + dev_info(&instance->pdev->dev,
> > + "%s:%d waiting_for_outstanding: before
issue
> OCR. FW state = 0x%x, oustanding 0x%x\n",
> > + __func__, __LINE__, fw_state,
> atomic_read(&instance->fw_outstanding));
> > + if (i == 3)
> > + goto kill_hba_and_failed;
> > megasas_do_ocr(instance);
> > - kill_adapter_flag = 1;
> >
> > - /* wait for 1 secs to let FW finish the pending
cmds */
> > - msleep(1000);
> > + if (atomic_read(&instance->adprecovery) ==
> MEGASAS_HW_CRITICAL_ERROR) {
> > + dev_info(&instance->pdev->dev, "%s:%d OCR
> failed and HBA is killed.\n",
> > + __func__, __LINE__);
> > + return FAILED;
> > + }
> > + dev_info(&instance->pdev->dev, "%s:%d
> waiting_for_outstanding: after issue OCR.\n",
> > + __func__, __LINE__);
> > +
> > + for (sl = 0; sl < 10; sl++)
> > + msleep(500);
>
> ssleep(5); ?
>
> > +
> > + outstanding = atomic_read(&instance-
> >fw_outstanding);
> > +
> > + fw_state = instance->instancet-
> >read_fw_status_reg(instance->reg_set) & MFI_STATE_MASK;
> > + if ((!outstanding && (fw_state ==
> MFI_STATE_OPERATIONAL)))
> > + goto no_outstanding;
> > }
> > i++;
> > } while (i <= 3);
> >
> > - if (atomic_read(&instance->fw_outstanding) && !kill_adapter_flag)
{
> > - if (instance->disableOnlineCtrlReset == 0) {
> > -
Re: mm: another VM_BUG_ON_PAGE(PageTail(page))
On Thu, Jan 28, 2016 at 11:27:11AM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers VM_BUG_ON_PAGE(PageTail(page)):
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd;
>
> mmap((void*)0x2000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
> fd = open("/dev/sg1", O_RDONLY|O_SYNC|0x10);
> mmap((void*)0x20001000, 0x4000, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED, fd, 0);
> mbind((void*)0x2000, 0x4000, 0x8002, (void*)0x20002ff8, 3660,
> MPOL_MF_STRICT|MPOL_MF_MOVE);
> return 0;
> }
I don't have sg1 in my VM. I changed it to sg0 and it doesn't trigger an
issue: mbind() returns -EINVAL as it supposed to. Hm..
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mm: another VM_BUG_ON_PAGE(PageTail(page))
Hello,
The following program triggers VM_BUG_ON_PAGE(PageTail(page)):
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
int main()
{
int fd;
mmap((void*)0x2000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
fd = open("/dev/sg1", O_RDONLY|O_SYNC|0x10);
mmap((void*)0x20001000, 0x4000, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, fd, 0);
mbind((void*)0x2000, 0x4000, 0x8002, (void*)0x20002ff8, 3660,
MPOL_MF_STRICT|MPOL_MF_MOVE);
return 0;
}
page:eaf5da80 count:0 mapcount:1 mapping:dead0400
index:0x0 compound_mapcount: 0
flags: 0x1fffc00()
page dumped because: VM_BUG_ON_PAGE(PageTail(page))
[ cut here ]
kernel BUG at mm/vmscan.c:1446!
invalid opcode: [#27] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 8185 Comm: a.out Tainted: G D 4.5.0-rc1+ #300
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006146c740 ti: 88006c8f task.ti: 88006c8f
RIP: 0010:[] []
isolate_lru_page+0x4ea/0x6d0
RSP: 0018:88006c8f7a50 EFLAGS: 00010282
RAX: 88006146c740 RBX: eaf5da80 RCX:
RDX: RSI: 0001 RDI: eaf5dab8
RBP: 88006c8f7a88 R08: 0001 R09:
R10: 0002 R11: 1134edc5 R12: eaf5daa0
R13: eaf5da00 R14: eaf5da01 R15: 20004000
FS: 022ec880(0063) GS:88003ed0() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 20003000 CR3: 31d0b000 CR4: 06e0
Stack:
0001 816e4159 8800310f6018 20003000
dc00 eaf5da80 20004000 88006c8f7b10
8174efdd ea01 88006c8f7c70 88006c8f7de8
Call Trace:
[< inline >] migrate_page_add mm/mempolicy.c:966
[] queue_pages_pte_range+0x4ad/0x10b0 mm/mempolicy.c:552
[< inline >] walk_pmd_range mm/pagewalk.c:50
[< inline >] walk_pud_range mm/pagewalk.c:90
[< inline >] walk_pgd_range mm/pagewalk.c:116
[] __walk_page_range+0x653/0xcd0 mm/pagewalk.c:204
[] walk_page_range+0x134/0x300 mm/pagewalk.c:281
[] queue_pages_range+0xfb/0x130 mm/mempolicy.c:687
[] do_mbind+0x2c1/0xdc0 mm/mempolicy.c:1239
[< inline >] SYSC_mbind mm/mempolicy.c:1351
[] SyS_mbind+0x13d/0x150 mm/mempolicy.c:1333
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
Code: 89 df e8 5a 62 04 00 0f 0b e8 43 71 ed ff 4d 8d 6e ff e9 73 fb
ff ff e8 35 71 ed ff 48 c7 c6 a0 ab 79 86 48 89 df e8 36 62 04 00 <0f>
0b e8 1f 71 ed ff 4d 8d 6e ff e9 eb fb ff ff c7 45 d0 f0 ff
RIP [] isolate_lru_page+0x4ea/0x6d0 mm/vmscan.c:1446
RSP
---[ end trace 4b07319c03942d44 ]---
BUG: sleeping function called from invalid context at include/linux/sched.h:2805
in_atomic(): 1, irqs_disabled(): 0, pid: 8185, name: a.out
INFO: lockdep is turned off.
CPU: 1 PID: 8185 Comm: a.out Tainted: G D 4.5.0-rc1+ #300
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
88006c8f7548 82be118d 88006146c740
1ff9 88006c8f7570 813cb8cb
88006146c740 867387a0 0af5 88006c8f75b0
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[] ___might_sleep+0x27b/0x3a0 kernel/sched/core.c:7703
[] __might_sleep+0x90/0x1a0 kernel/sched/core.c:7665
[< inline >] threadgroup_change_begin include/linux/sched.h:2805
[] exit_signals+0x81/0x430 kernel/signal.c:2392
[] do_exit+0x23c/0x2cb0 kernel/exit.c:701
[] oops_end+0x9f/0xd0 arch/x86/kernel/dumpstack.c:250
[] die+0x46/0x60 arch/x86/kernel/dumpstack.c:316
[< inline >] do_trap_no_signal arch/x86/kernel/traps.c:205
[] do_trap+0x18f/0x380 arch/x86/kernel/traps.c:251
[] do_error_trap+0x11e/0x280 arch/x86/kernel/traps.c:290
[] do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:303
[] invalid_op+0x1e/0x30 arch/x86/entry/entry_64.S:830
[< inline >] migrate_page_add mm/mempolicy.c:966
[] queue_pages_pte_range+0x4ad/0x10b0 mm/mempolicy.c:552
[< inline >] walk_pmd_range mm/pagewalk.c:50
[< inline >] walk_pud_range mm/pagewalk.c:90
[< inline >] walk_pgd_range mm/pagewalk.c:116
[] __walk_page_range+0x653/0xcd0 mm/pagewalk.c:204
[] walk_page_range+0x134/0x300 mm/pagewalk.c:281
[] queue_pages_range+0xfb/0x130 mm/mempolicy.c:687
[] do_mbind+0x2c1/0xdc0 mm/mempolicy.c:1239
[< inline >] SYSC_mbind mm/mempolicy.c:1351
[] SyS_mbind+0x13d/0x150 mm/mempolicy.c:1333
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
note: a.out[8185] exited with preempt_count 1
On commit 92e963f50fc74041b5e9e744c330dca48e04f08d with Kirill recent fix:
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
scsi: NULL deref in sg_start_req
Hello,
The following program causes NULL deref in sg_start_req:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#ifndef SYS_memfd_create
#define SYS_memfd_create 319
#endif
int main()
{
long r[26];
syscall(SYS_mmap, 0x2000ul, 0xdee000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
r[2] = syscall(SYS_memfd_create,
"\x73\x65\x63\x75\x72\x69\x76\x69\x00", 0x3ul, 0, 0, 0, 0);
memcpy((void*)0x20dea2be, "\x2f\x64\x65\x76\x2f\x73\x67\x23", 8);
r[4] = syscall(SYS_open, "/dev/sg0", 0x2ul, 0, 0, 0);
*(uint64_t*)0x2ffe = (uint64_t)0x2000;
*(uint64_t*)0x20001006 = (uint64_t)0x4f;
*(uint64_t*)0x2000100e = (uint64_t)0x2f7c;
*(uint64_t*)0x20001016 = (uint64_t)0x84;
*(uint64_t*)0x2000101e = (uint64_t)0x20003f9e;
*(uint64_t*)0x20001026 = (uint64_t)0xe0;
*(uint64_t*)0x2000102e = (uint64_t)0x20decf72;
*(uint64_t*)0x20001036 = (uint64_t)0xc6;
syscall(SYS_pwritev, r[2], 0x2ffeul, 0x4ul, 0x0ul, 0, 0);
*(uint32_t*)0x208b1fea = (uint32_t)0x20;
*(uint32_t*)0x208b1fee = (uint32_t)0x;
*(uint64_t*)0x208b1ff2 = (uint64_t)0x0;
*(uint64_t*)0x208b1ffa = (uint64_t)0x0;
*(uint32_t*)0x208b2002 = (uint32_t)0x1;
syscall(SYS_write, r[2], 0x208b1feaul, 0x20ul, 0, 0, 0);
*(uint64_t*)0x20deb20e = (uint64_t)0x0;
syscall(SYS_sendfile, r[4], r[2], 0x20deb20eul, 0x19cbul, 0, 0);
return 0;
}
sg_write: data in/out 65499/591 bytes for SCSI command 0x0-- guessing data in;
program a.out not setting count and/or reply_len properly
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __memcpy+0x12/0x20 arch/x86/lib/memcpy_64.S:35
PGD 7ce53067 PUD 7cef8067 PMD 0
Oops: [#1] SMP
Modules linked in:
CPU: 2 PID: 2650 Comm: a.out Not tainted 4.4.0+ #59
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88007fa25cc0 ti: 88007ccf task.ti: 88007ccf
RIP: 0010:[] [] __memcpy+0x12/0x20
RSP: 0018:88007ccf3800 EFLAGS: 00010246
RAX: 88007cc2 RBX: 88007ccf38e0 RCX: 0200
RDX: RSI: RDI: 88007cc2
RBP: 88007ccf3840 R08: 88007ccf39c0 R09: 02080020
R10: R11: R12: 1000
R13: 1000 R14: 1000 R15:
FS: 012df880(0063) GS:88007fc0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 7fab8000 CR4: 06e0
Stack:
81328682 88007ccf39c0 88007cc21000 88007ccf38e0
88007fa25cc0 88007cd69a40 88007ccf3a68 88007ccf3a68
88007ccf38a0 8132a1a4 ffdb 88007ccf38a0
Call Trace:
[] copy_page_from_iter+0x274/0x370 lib/iov_iter.c:467
[< inline >] bio_copy_from_iter block/bio.c:1023
[] bio_copy_user_iov+0x2e6/0x380 block/bio.c:1221
[] blk_rq_map_user_iov+0x1e4/0x270 block/blk-map.c:111
[] blk_rq_map_user+0x4d/0x60 block/blk-map.c:154
[< inline >] sg_start_req drivers/scsi/sg.c:1766
[] sg_common_write.isra.17+0x327/0x540 drivers/scsi/sg.c:782
[] sg_write+0x1af/0x330 drivers/scsi/sg.c:685
[] __vfs_write+0x23/0xe0 fs/read_write.c:528
[] __kernel_write+0x4f/0xf0 fs/read_write.c:550
[] write_pipe_buf+0x5e/0x70 fs/splice.c:1068
[< inline >] splice_from_pipe_feed fs/splice.c:770
[] __splice_from_pipe+0xf9/0x170 fs/splice.c:895
[] splice_from_pipe+0x4c/0x70 fs/splice.c:930
[] default_file_splice_write+0x14/0x20 fs/splice.c:1080
[< inline >] do_splice_from fs/splice.c:1122
[] direct_splice_actor+0x31/0x40 fs/splice.c:1288
[] splice_direct_to_actor+0x90/0x1f0 fs/splice.c:1241
[] do_splice_direct+0x77/0xa0 fs/splice.c:1331
[] do_sendfile+0x198/0x380 fs/read_write.c:1266
[< inline >] SYSC_sendfile64 fs/read_write.c:1321
[] SyS_sendfile64+0x4a/0x90 fs/read_write.c:1313
[] entry_SYSCALL_64_fastpath+0x12/0x71
arch/x86/entry/entry_64.S:185
Code: 60 48 2b 43 50 88 43 4e 5b 5d c3 e8 b9 fc ff ff eb eb 90 90 90
90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07
48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3
RIP [] __memcpy+0x12/0x20 arch/x86/lib/memcpy_64.S:35
RSP
CR2:
---[ end trace 581bd080ffa39d79 ]---
note: a.out[7919] exited with preempt_count 1
BUG: sleeping function called from invalid context at include/linux/sched.h:2805
in_atomic(): 1, irqs_disabled(): 0, pid: 7919, name: a.out
INFO: lockdep is turned off.
CPU: 3 PID: 7919 Comm: a.out Tainted: G D 4.5.0-rc1+ #300
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880061656a90 82be118d 88006146c740
1eef 880061656ab8 813cb8cb
88006146c740 867387a0 0af5 880061656af8
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0
Re: [LSF/MM TOPIC] NVMe target support
On Thu, 2016-01-28 at 10:11 +0100, Christoph Hellwig wrote: > There is a upcoming 'NVMe over Fabrics' spec, Yes. > and it seems to be your are > using the word 'fabrics' in a different context, so you might want to > explain it in lay mans term. > I mean in the context of target_core_fabric_ops and front-end driver association with backend se_device->dev_group configfs symlinks. Specifically how NVMe target drivers will be mapping these into the existing TCM configfs layout. > If I was dictator for life I'd forbid the use of the word 'fabrics' > for any not related to textiles.. ..? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [LSF/MM TOPIC] NVMe target support
>>I'd forbid the use of the word 'fabrics' for any not related to textiles.. lol Btw, You're not dictator for life? -Original Message- From: Linux-nvme [mailto:linux-nvme-boun...@lists.infradead.org] On Behalf Of Christoph Hellwig Sent: Thursday, January 28, 2016 1:12 AM To: Nicholas A. Bellinger Cc: Minturn, Dave B; Sagi Grimberg; Roland Dreier; linux-scsi; linux-n...@lists.infradead.org; Christoph Hellwig; Mike Christie; target-devel; Hannes Reinecke; Ming Lin; lsf-pc; Christoph Hellwig Subject: Re: [LSF/MM TOPIC] NVMe target support There is a upcoming 'NVMe over Fabrics' spec, and it seems to be your are using the word 'fabrics' in a different context, so you might want to explain it in lay mans term. If I was dictator for life I'd forbid the use of the word 'fabrics' for any not related to textiles.. ___ Linux-nvme mailing list linux-n...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [mpt3sas driver 02/10] mpt3sas: Used IEEE SGL instead of MPI SGL while framing a SMP Passthrough request message.
On Thu, Jan 28, 2016 at 12:06:59PM +0530, Suganath prabu Subaramani wrote: > From: Suganath prabu Subramani > > As driver was using MPI SGL while framing the SMP Passthrough request > message due to which firmware unable to post the Reply Data in the host > memory and timeout is observed for this SMP Passthrough request message > and so unable to perform phy disable operation. Does this also do the right thing for MPT2 HBAs? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] NVMe target support
There is a upcoming 'NVMe over Fabrics' spec, and it seems to be your are using the word 'fabrics' in a different context, so you might want to explain it in lay mans term. If I was dictator for life I'd forbid the use of the word 'fabrics' for any not related to textiles.. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] NVMe target support
On Thu, 2016-01-28 at 00:52 -0800, Christoph Hellwig wrote: > I think the frame is wrong, nevermind that I doubt I'll be able to > discuss anything NVMe Fabrics related before the spec is public. Which > I doubt is in time for LSF/MM. That fine, but NVMe_OF is certainly not going to be the only fabric driver out there. So what I'd like to discuss wrt this topic is what existing common code relates to vhost-nvme, based on other's fabric driver work already out there. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] LIO/SCST Merger
Everyone calm down. I'm going to downvote this topic just like last year with my PC hat on as I think it's a) not relevant or usefully discussable at LSF and b) framed the wrong way. But let's forget about unification and think about fixing up lose ends and looking at other implementations and other preople experiences here. While I'd never want to take SCST as a whole into the kernel tree there are plenty of good idea to look at, and Bart has been trying for quite a while to merge a lot of the concepts into the in-kernel SCSI target stack and has meet an incredibly hostility. And I have the impression as lot of that is due to him beeing Bart - I've done some quite similar things where I took concepts from SCST or other implementations and opnly meet minor if any resistance. Maybe we should have a discussion about equalt treatment on the target-devel list instead? :) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/11] qla2xxx: Update driver version to 8.07.00.33-k
On Wed, Jan 27, 2016 at 12:03:38PM -0500, Himanshu Madhani wrote: > Signed-off-by: Himanshu Madhani > --- > drivers/scsi/qla2xxx/qla_version.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/qla2xxx/qla_version.h > b/drivers/scsi/qla2xxx/qla_version.h > index 6d31faa..0bc93fa 100644 > --- a/drivers/scsi/qla2xxx/qla_version.h > +++ b/drivers/scsi/qla2xxx/qla_version.h > @@ -7,7 +7,7 @@ > /* > * Driver version > */ > -#define QLA2XXX_VERSION "8.07.00.26-k" > +#define QLA2XXX_VERSION "8.07.00.33-k" > > #define QLA_DRIVER_MAJOR_VER 8 > #define QLA_DRIVER_MINOR_VER 7 > -- > 1.7.7 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/11] qla2xxx: Set relogin flag when we fail to queue login requests.
On Wed, Jan 27, 2016 at 12:03:37PM -0500, Himanshu Madhani wrote:
> From: Chad Dupuis
>
> If we fail to queue an srb for an async login we should set the
> relogin flag so it will be retried as the reason for the queuing
> failure was most likely transient. Failure to do this can lead to
> failed paths as login is never retried if the relogin flag is not
> set.
>
> Signed-off-by: Chad Dupuis
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_init.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
> index 8001c89..184b6b6 100644
> --- a/drivers/scsi/qla2xxx/qla_init.c
> +++ b/drivers/scsi/qla2xxx/qla_init.c
> @@ -157,8 +157,12 @@ qla2x00_async_login(struct scsi_qla_host *vha, fc_port_t
> *fcport,
> if (data[1] & QLA_LOGIO_LOGIN_RETRIED)
> lio->u.logio.flags |= SRB_LOGIN_RETRIED;
> rval = qla2x00_start_sp(sp);
> - if (rval != QLA_SUCCESS)
> + if (rval != QLA_SUCCESS) {
> + fcport->flags &= ~FCF_ASYNC_SENT;
> + fcport->flags |= FCF_LOGIN_NEEDED;
> + set_bit(RELOGIN_NEEDED, &vha->dpc_flags);
> goto done_free_sp;
> + }
>
> ql_dbg(ql_dbg_disc, vha, 0x2072,
> "Async-login - hdl=%x, loopid=%x portid=%02x%02x%02x "
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/11] qla2xxx: Enable T10-DIF for ISP27XX
On Wed, Jan 27, 2016 at 12:03:36PM -0500, Himanshu Madhani wrote: > Signed-off-by: Himanshu Madhani > Signed-off-by: Giridhar Malavali > --- > drivers/scsi/qla2xxx/qla_os.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c > index d94a236..fa017e9 100644 > --- a/drivers/scsi/qla2xxx/qla_os.c > +++ b/drivers/scsi/qla2xxx/qla_os.c > @@ -2217,6 +2217,7 @@ qla2x00_set_isp_flags(struct qla_hw_data *ha) > ha->device_type |= DT_ZIO_SUPPORTED; > ha->device_type |= DT_FWI2; > ha->device_type |= DT_IIDMA; > + ha->device_type |= DT_T10_PI; > ha->fw_srisc_address = RISC_START_ADDRESS_2400; > break; > case PCI_DEVICE_ID_QLOGIC_ISP2271: > @@ -2224,6 +2225,7 @@ qla2x00_set_isp_flags(struct qla_hw_data *ha) > ha->device_type |= DT_ZIO_SUPPORTED; > ha->device_type |= DT_FWI2; > ha->device_type |= DT_IIDMA; > + ha->device_type |= DT_T10_PI; > ha->fw_srisc_address = RISC_START_ADDRESS_2400; > break; > case PCI_DEVICE_ID_QLOGIC_ISP2261: > @@ -2231,6 +2233,7 @@ qla2x00_set_isp_flags(struct qla_hw_data *ha) > ha->device_type |= DT_ZIO_SUPPORTED; > ha->device_type |= DT_FWI2; > ha->device_type |= DT_IIDMA; > + ha->device_type |= DT_T10_PI; > ha->fw_srisc_address = RISC_START_ADDRESS_2400; > break; > } > -- > 1.7.7 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/11] qla2xxx: Provide mbx info in BBCR data after mbx failure
On Wed, Jan 27, 2016 at 12:03:35PM -0500, Himanshu Madhani wrote:
> From: Harish Zunjarrao
>
> Signed-off-by: Harish Zunjarrao
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_bsg.c |9 +++--
> drivers/scsi/qla2xxx/qla_bsg.h |4 +++-
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
> index 913fef2..392c147 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.c
> +++ b/drivers/scsi/qla2xxx/qla_bsg.c
> @@ -2204,8 +2204,12 @@ qla27xx_get_bbcr_data(struct fc_bsg_job *bsg_job)
> if (bbcr.status == QLA_BBCR_STATUS_ENABLED) {
> rval = qla2x00_get_adapter_id(vha, &loop_id, &al_pa,
> &area, &domain, &topo, &sw_cap);
> - if (rval != QLA_SUCCESS)
> - return -EIO;
> + if (rval != QLA_SUCCESS) {
> + bbcr.status = QLA_BBCR_STATUS_UNKNOWN;
> + bbcr.state = QLA_BBCR_STATE_OFFLINE;
> + bbcr.mbx1 = loop_id;
> + goto done;
> + }
>
> state = (vha->bbcr >> 12) & 0x1;
>
> @@ -2220,6 +2224,7 @@ qla27xx_get_bbcr_data(struct fc_bsg_job *bsg_job)
> bbcr.configured_bbscn = vha->bbcr & 0xf;
> }
>
> +done:
> sg_copy_from_buffer(bsg_job->reply_payload.sg_list,
> bsg_job->reply_payload.sg_cnt, &bbcr, sizeof(bbcr));
> bsg_job->reply->reply_payload_rcv_len = sizeof(bbcr);
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.h b/drivers/scsi/qla2xxx/qla_bsg.h
> index c40dd8b..c80192d 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.h
> +++ b/drivers/scsi/qla2xxx/qla_bsg.h
> @@ -245,6 +245,7 @@ struct qla_flash_update_caps {
> /* BB_CR Status */
> #define QLA_BBCR_STATUS_DISABLED 0
> #define QLA_BBCR_STATUS_ENABLED1
> +#define QLA_BBCR_STATUS_UNKNOWN2
>
> /* BB_CR State */
> #define QLA_BBCR_STATE_OFFLINE 0
> @@ -262,6 +263,7 @@ struct qla_bbcr_data {
> uint8_t configured_bbscn; /* 0-15 */
> uint8_t negotiated_bbscn; /* 0-15 */
> uint8_t offline_reason_code;
> - uint8_t reserved[11];
> + uint16_t mbx1; /* Port state */
> + uint8_t reserved[9];
> } __packed;
> #endif
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/11] qla2xxx: Avoid side effects when using endianizer macros.
On Wed, Jan 27, 2016 at 12:03:34PM -0500, Himanshu Madhani wrote:
> From: Joe Carnuccio
>
> Signed-off-by: Joe Carnuccio
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_attr.c |4 +-
> drivers/scsi/qla2xxx/qla_dbg.c| 141
> -
> drivers/scsi/qla2xxx/qla_init.c | 16 ++--
> drivers/scsi/qla2xxx/qla_inline.h |4 +-
> drivers/scsi/qla2xxx/qla_mbx.c| 16 ++--
> drivers/scsi/qla2xxx/qla_sup.c| 23 +++---
> 6 files changed, 106 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
> index fadce04..4dc06a13 100644
> --- a/drivers/scsi/qla2xxx/qla_attr.c
> +++ b/drivers/scsi/qla2xxx/qla_attr.c
> @@ -272,8 +272,8 @@ qla2x00_sysfs_write_nvram(struct file *filp, struct
> kobject *kobj,
>
> iter = (uint32_t *)buf;
> chksum = 0;
> - for (cnt = 0; cnt < ((count >> 2) - 1); cnt++)
> - chksum += le32_to_cpu(*iter++);
> + for (cnt = 0; cnt < ((count >> 2) - 1); cnt++, iter++)
> + chksum += le32_to_cpu(*iter);
> chksum = ~chksum + 1;
> *iter = cpu_to_le32(chksum);
> } else {
> diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
> index aa6694b..b64c504 100644
> --- a/drivers/scsi/qla2xxx/qla_dbg.c
> +++ b/drivers/scsi/qla2xxx/qla_dbg.c
> @@ -294,8 +294,8 @@ qla24xx_read_window(struct device_reg_24xx __iomem *reg,
> uint32_t iobase,
>
> WRT_REG_DWORD(®->iobase_addr, iobase);
> dmp_reg = ®->iobase_window;
> - while (count--)
> - *buf++ = htonl(RD_REG_DWORD(dmp_reg++));
> + for ( ; count--; dmp_reg++)
> + *buf++ = htonl(RD_REG_DWORD(dmp_reg));
>
> return buf;
> }
> @@ -457,8 +457,8 @@ qla2xxx_read_window(struct device_reg_2xxx __iomem *reg,
> uint32_t count,
> {
> uint16_t __iomem *dmp_reg = ®->u.isp2300.fb_cmd;
>
> - while (count--)
> - *buf++ = htons(RD_REG_WORD(dmp_reg++));
> + for ( ; count--; dmp_reg++)
> + *buf++ = htons(RD_REG_WORD(dmp_reg));
> }
>
> static inline void *
> @@ -733,16 +733,18 @@ qla2300_fw_dump(scsi_qla_host_t *vha, int
> hardware_locked)
>
> if (rval == QLA_SUCCESS) {
> dmp_reg = ®->flash_address;
> - for (cnt = 0; cnt < sizeof(fw->pbiu_reg) / 2; cnt++)
> - fw->pbiu_reg[cnt] = htons(RD_REG_WORD(dmp_reg++));
> + for (cnt = 0; cnt < sizeof(fw->pbiu_reg) / 2; cnt++, dmp_reg++)
> + fw->pbiu_reg[cnt] = htons(RD_REG_WORD(dmp_reg));
>
> dmp_reg = ®->u.isp2300.req_q_in;
> - for (cnt = 0; cnt < sizeof(fw->risc_host_reg) / 2; cnt++)
> - fw->risc_host_reg[cnt] = htons(RD_REG_WORD(dmp_reg++));
> + for (cnt = 0; cnt < sizeof(fw->risc_host_reg) / 2;
> + cnt++, dmp_reg++)
> + fw->risc_host_reg[cnt] = htons(RD_REG_WORD(dmp_reg));
>
> dmp_reg = ®->u.isp2300.mailbox0;
> - for (cnt = 0; cnt < sizeof(fw->mailbox_reg) / 2; cnt++)
> - fw->mailbox_reg[cnt] = htons(RD_REG_WORD(dmp_reg++));
> + for (cnt = 0; cnt < sizeof(fw->mailbox_reg) / 2;
> + cnt++, dmp_reg++)
> + fw->mailbox_reg[cnt] = htons(RD_REG_WORD(dmp_reg));
>
> WRT_REG_WORD(®->ctrl_status, 0x40);
> qla2xxx_read_window(reg, 32, fw->resp_dma_reg);
> @@ -752,8 +754,9 @@ qla2300_fw_dump(scsi_qla_host_t *vha, int hardware_locked)
>
> WRT_REG_WORD(®->ctrl_status, 0x00);
> dmp_reg = ®->risc_hw;
> - for (cnt = 0; cnt < sizeof(fw->risc_hdw_reg) / 2; cnt++)
> - fw->risc_hdw_reg[cnt] = htons(RD_REG_WORD(dmp_reg++));
> + for (cnt = 0; cnt < sizeof(fw->risc_hdw_reg) / 2;
> + cnt++, dmp_reg++)
> + fw->risc_hdw_reg[cnt] = htons(RD_REG_WORD(dmp_reg));
>
> WRT_REG_WORD(®->pcr, 0x2000);
> qla2xxx_read_window(reg, 16, fw->risc_gp0_reg);
> @@ -896,25 +899,25 @@ qla2100_fw_dump(scsi_qla_host_t *vha, int
> hardware_locked)
> }
> if (rval == QLA_SUCCESS) {
> dmp_reg = ®->flash_address;
> - for (cnt = 0; cnt < sizeof(fw->pbiu_reg) / 2; cnt++)
> - fw->pbiu_reg[cnt] = htons(RD_REG_WORD(dmp_reg++));
> + for (cnt = 0; cnt < sizeof(fw->pbiu_reg) / 2; cnt++, dmp_reg++)
> + fw->pbiu_reg[cnt] = htons(RD_REG_WORD(dmp_reg));
>
> dmp_reg = ®->u.isp2100.mailbox0;
> - for (cnt = 0; cnt < ha->mbx_count; cnt++) {
> + for (cnt = 0; cnt < ha->mbx_count; cnt++, dmp_reg++) {
> if (cnt == 8)
> dmp_reg = ®->u_end.isp2200.mailbox8;
>
> - fw->mailbox_reg[cnt] = htons(RD_
Re: [PATCH v2 06/11] qla2xxx: Add support for Private link statistics counters.
On Wed, Jan 27, 2016 at 12:03:33PM -0500, Himanshu Madhani wrote:
> From: Harish Zunjarrao
>
> Signed-off-by: Harish Zunjarrao
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_attr.c |6 ++-
> drivers/scsi/qla2xxx/qla_bsg.c | 61
> +++
> drivers/scsi/qla2xxx/qla_bsg.h |1 +
> drivers/scsi/qla2xxx/qla_dbg.c |2 +-
> drivers/scsi/qla2xxx/qla_def.h | 32 +++-
> drivers/scsi/qla2xxx/qla_mbx.c |3 +-
> 6 files changed, 99 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
> index fef659a..fadce04 100644
> --- a/drivers/scsi/qla2xxx/qla_attr.c
> +++ b/drivers/scsi/qla2xxx/qla_attr.c
> @@ -1917,7 +1917,8 @@ qla2x00_get_fc_host_stats(struct Scsi_Host *shost)
> if (qla2x00_reset_active(vha))
> goto done;
>
> - stats = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &stats_dma);
> + stats = dma_alloc_coherent(&ha->pdev->dev,
> + sizeof(struct link_statistics), &stats_dma, GFP_KERNEL);
> if (stats == NULL) {
> ql_log(ql_log_warn, vha, 0x707d,
> "Failed to allocate memory for stats.\n");
> @@ -1965,7 +1966,8 @@ qla2x00_get_fc_host_stats(struct Scsi_Host *shost)
> do_div(pfc_host_stat->seconds_since_last_reset, HZ);
>
> done_free:
> -dma_pool_free(ha->s_dma_pool, stats, stats_dma);
> + dma_free_coherent(&ha->pdev->dev, sizeof(struct link_statistics),
> + stats, stats_dma);
> done:
> return pfc_host_stat;
> }
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
> index d135d6a..913fef2 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.c
> +++ b/drivers/scsi/qla2xxx/qla_bsg.c
> @@ -2233,6 +2233,64 @@ qla27xx_get_bbcr_data(struct fc_bsg_job *bsg_job)
> }
>
> static int
> +qla2x00_get_priv_stats(struct fc_bsg_job *bsg_job)
> +{
> + struct Scsi_Host *host = bsg_job->shost;
> + scsi_qla_host_t *vha = shost_priv(host);
> + struct qla_hw_data *ha = vha->hw;
> + struct scsi_qla_host *base_vha = pci_get_drvdata(ha->pdev);
> + struct link_statistics *stats = NULL;
> + dma_addr_t stats_dma;
> + int rval = QLA_FUNCTION_FAILED;
> +
> + if (test_bit(UNLOADING, &vha->dpc_flags))
> + goto done;
> +
> + if (unlikely(pci_channel_offline(ha->pdev)))
> + goto done;
> +
> + if (qla2x00_reset_active(vha))
> + goto done;
> +
> + if (!IS_FWI2_CAPABLE(ha))
> + goto done;
> +
> + stats = dma_alloc_coherent(&ha->pdev->dev,
> + sizeof(struct link_statistics), &stats_dma, GFP_KERNEL);
> + if (!stats) {
> + ql_log(ql_log_warn, vha, 0x70e2,
> + "Failed to allocate memory for stats.\n");
> + goto done;
> + }
> +
> + memset(stats, 0, sizeof(struct link_statistics));
> +
> + rval = qla24xx_get_isp_stats(base_vha, stats, stats_dma);
> +
> + if (rval != QLA_SUCCESS)
> + goto done_free;
> +
> + ql_dump_buffer(ql_dbg_user + ql_dbg_verbose, vha, 0x70e3,
> + (uint8_t *)stats, sizeof(struct link_statistics));
> +
> + sg_copy_from_buffer(bsg_job->reply_payload.sg_list,
> + bsg_job->reply_payload.sg_cnt, stats, sizeof(struct link_statistics));
> + bsg_job->reply->reply_payload_rcv_len = sizeof(struct link_statistics);
> +
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_OK;
> +
> + bsg_job->reply_len = sizeof(struct fc_bsg_reply);
> + bsg_job->reply->result = DID_OK << 16;
> + bsg_job->job_done(bsg_job);
> +
> +done_free:
> + dma_free_coherent(&ha->pdev->dev, sizeof(struct link_statistics),
> + stats, stats_dma);
> +done:
> + return rval;
> +}
> +
> +static int
> qla2x00_process_vendor_specific(struct fc_bsg_job *bsg_job)
> {
> switch (bsg_job->request->rqst_data.h_vendor.vendor_cmd[0]) {
> @@ -2296,6 +2354,9 @@ qla2x00_process_vendor_specific(struct fc_bsg_job
> *bsg_job)
> case QL_VND_GET_BBCR_DATA:
> return qla27xx_get_bbcr_data(bsg_job);
>
> + case QL_VND_GET_PRIV_STATS:
> + return qla2x00_get_priv_stats(bsg_job);
> +
> default:
> return -ENOSYS;
> }
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.h b/drivers/scsi/qla2xxx/qla_bsg.h
> index 4275177..c40dd8b 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.h
> +++ b/drivers/scsi/qla2xxx/qla_bsg.h
> @@ -28,6 +28,7 @@
> #define QL_VND_GET_FLASH_UPDATE_CAPS0x15
> #define QL_VND_SET_FLASH_UPDATE_CAPS0x16
> #define QL_VND_GET_BBCR_DATA0x17
> +#define QL_VND_GET_PRIV_STATS0x18
>
> /* BSG Vendor specific subcode returns */
> #define EXT_STATUS_OK0
> diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
> index 493a3ea81..aa6694b 100644
> --- a/drivers/scsi/qla2xxx/qla_dbg.c
> +++ b/drivers/scsi/qla2xxx/qla_dbg.c
> @@ -32,7 +32,7 @@
> *
Re: [PATCH v2 04/11] qla2xxx: Add support for online flash update for ISP27XX.
On Wed, Jan 27, 2016 at 12:03:31PM -0500, Himanshu Madhani wrote:
> From: Sawan Chandak
>
> Signed-off-by: Sawan Chandak
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_attr.c | 12 -
> drivers/scsi/qla2xxx/qla_bsg.c | 80 ++
> drivers/scsi/qla2xxx/qla_bsg.h |7 +++
> drivers/scsi/qla2xxx/qla_dbg.c |2 +-
> drivers/scsi/qla2xxx/qla_def.h | 22 +
> drivers/scsi/qla2xxx/qla_fw.h | 10
> drivers/scsi/qla2xxx/qla_gbl.h |1 +
> drivers/scsi/qla2xxx/qla_init.c | 91
> +++
> drivers/scsi/qla2xxx/qla_sup.c | 47 +++-
> 9 files changed, 266 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
> index 6992ebc..fef659a 100644
> --- a/drivers/scsi/qla2xxx/qla_attr.c
> +++ b/drivers/scsi/qla2xxx/qla_attr.c
> @@ -562,6 +562,7 @@ qla2x00_sysfs_read_vpd(struct file *filp, struct kobject
> *kobj,
> struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
> struct device, kobj)));
> struct qla_hw_data *ha = vha->hw;
> + uint32_t faddr;
>
> if (unlikely(pci_channel_offline(ha->pdev)))
> return -EAGAIN;
> @@ -569,9 +570,16 @@ qla2x00_sysfs_read_vpd(struct file *filp, struct kobject
> *kobj,
> if (!capable(CAP_SYS_ADMIN))
> return -EINVAL;
>
> - if (IS_NOCACHE_VPD_TYPE(ha))
> - ha->isp_ops->read_optrom(vha, ha->vpd, ha->flt_region_vpd << 2,
> + if (IS_NOCACHE_VPD_TYPE(ha)) {
> + faddr = ha->flt_region_vpd << 2;
> +
> + if (IS_QLA27XX(ha) &&
> + qla27xx_find_valid_image(vha) == QLA27XX_SECONDARY_IMAGE)
> + faddr = ha->flt_region_vpd_sec << 2;
> +
> + ha->isp_ops->read_optrom(vha, ha->vpd, faddr,
> ha->vpd_size);
> + }
> return memory_read_from_buffer(buf, count, &off, ha->vpd, ha->vpd_size);
> }
>
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
> index c26acde..64fe17a 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.c
> +++ b/drivers/scsi/qla2xxx/qla_bsg.c
> @@ -2107,6 +2107,80 @@ qla8044_serdes_op(struct fc_bsg_job *bsg_job)
> }
>
> static int
> +qla27xx_get_flash_upd_cap(struct fc_bsg_job *bsg_job)
> +{
> + struct Scsi_Host *host = bsg_job->shost;
> + scsi_qla_host_t *vha = shost_priv(host);
> + struct qla_hw_data *ha = vha->hw;
> + struct qla_flash_update_caps cap;
> +
> + if (!(IS_QLA27XX(ha)))
> + return -EPERM;
> +
> + memset(&cap, 0, sizeof(cap));
> + cap.capabilities = (uint64_t)ha->fw_attributes_ext[1] << 48 |
> +(uint64_t)ha->fw_attributes_ext[0] << 32 |
> +(uint64_t)ha->fw_attributes_h << 16 |
> +(uint64_t)ha->fw_attributes;
> +
> + sg_copy_from_buffer(bsg_job->reply_payload.sg_list,
> + bsg_job->reply_payload.sg_cnt, &cap, sizeof(cap));
> + bsg_job->reply->reply_payload_rcv_len = sizeof(cap);
> +
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] =
> + EXT_STATUS_OK;
> +
> + bsg_job->reply_len = sizeof(struct fc_bsg_reply);
> + bsg_job->reply->result = DID_OK << 16;
> + bsg_job->job_done(bsg_job);
> + return 0;
> +}
> +
> +static int
> +qla27xx_set_flash_upd_cap(struct fc_bsg_job *bsg_job)
> +{
> + struct Scsi_Host *host = bsg_job->shost;
> + scsi_qla_host_t *vha = shost_priv(host);
> + struct qla_hw_data *ha = vha->hw;
> + uint64_t online_fw_attr = 0;
> + struct qla_flash_update_caps cap;
> +
> + if (!(IS_QLA27XX(ha)))
> + return -EPERM;
> +
> + memset(&cap, 0, sizeof(cap));
> + sg_copy_to_buffer(bsg_job->request_payload.sg_list,
> + bsg_job->request_payload.sg_cnt, &cap, sizeof(cap));
> +
> + online_fw_attr = (uint64_t)ha->fw_attributes_ext[1] << 48 |
> + (uint64_t)ha->fw_attributes_ext[0] << 32 |
> + (uint64_t)ha->fw_attributes_h << 16 |
> + (uint64_t)ha->fw_attributes;
> +
> + if (online_fw_attr != cap.capabilities) {
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] =
> + EXT_STATUS_INVALID_PARAM;
> + return -EINVAL;
> + }
> +
> + if (cap.outage_duration < MAX_LOOP_TIMEOUT) {
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] =
> + EXT_STATUS_INVALID_PARAM;
> + return -EINVAL;
> + }
> +
> + bsg_job->reply->reply_payload_rcv_len = 0;
> +
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] =
> + EXT_STATUS_OK;
> +
> + bsg_job->reply_len = sizeof(struct fc_bsg_reply);
> + bsg_job->reply->result = DID_OK << 16;
> + bsg_job->job_done(bsg_job);
> + return 0;
> +}
> +
> +static int
> qla2x00_process_vendor_specific(struct fc_bsg_job *bsg_job)
Re: [PATCH v2 05/11] qla2xxx: Add support for buffer to buffer credit value for ISP27XX.
On Wed, Jan 27, 2016 at 12:03:32PM -0500, Himanshu Madhani wrote:
> From: Sawan Chandak
>
> Signed-off-by: Sawan Chandak
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_bsg.c | 55
>
> drivers/scsi/qla2xxx/qla_bsg.h | 24 +
> drivers/scsi/qla2xxx/qla_def.h |2 +
> drivers/scsi/qla2xxx/qla_fw.h |4 ++-
> drivers/scsi/qla2xxx/qla_mbx.c |8 ++
> 5 files changed, 92 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
> index 64fe17a..d135d6a 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.c
> +++ b/drivers/scsi/qla2xxx/qla_bsg.c
> @@ -2181,6 +2181,58 @@ qla27xx_set_flash_upd_cap(struct fc_bsg_job *bsg_job)
> }
>
> static int
> +qla27xx_get_bbcr_data(struct fc_bsg_job *bsg_job)
> +{
> + struct Scsi_Host *host = bsg_job->shost;
> + scsi_qla_host_t *vha = shost_priv(host);
> + struct qla_hw_data *ha = vha->hw;
> + struct qla_bbcr_data bbcr;
> + uint16_t loop_id, topo, sw_cap;
> + uint8_t domain, area, al_pa, state;
> + int rval;
> +
> + if (!(IS_QLA27XX(ha)))
> + return -EPERM;
> +
> + memset(&bbcr, 0, sizeof(bbcr));
> +
> + if (vha->flags.bbcr_enable)
> + bbcr.status = QLA_BBCR_STATUS_ENABLED;
> + else
> + bbcr.status = QLA_BBCR_STATUS_DISABLED;
> +
> + if (bbcr.status == QLA_BBCR_STATUS_ENABLED) {
> + rval = qla2x00_get_adapter_id(vha, &loop_id, &al_pa,
> + &area, &domain, &topo, &sw_cap);
> + if (rval != QLA_SUCCESS)
> + return -EIO;
> +
> + state = (vha->bbcr >> 12) & 0x1;
> +
> + if (state) {
> + bbcr.state = QLA_BBCR_STATE_OFFLINE;
> + bbcr.offline_reason_code = QLA_BBCR_REASON_LOGIN_REJECT;
> + } else {
> + bbcr.state = QLA_BBCR_STATE_ONLINE;
> + bbcr.negotiated_bbscn = (vha->bbcr >> 8) & 0xf;
> + }
> +
> + bbcr.configured_bbscn = vha->bbcr & 0xf;
> + }
> +
> + sg_copy_from_buffer(bsg_job->reply_payload.sg_list,
> + bsg_job->reply_payload.sg_cnt, &bbcr, sizeof(bbcr));
> + bsg_job->reply->reply_payload_rcv_len = sizeof(bbcr);
> +
> + bsg_job->reply->reply_data.vendor_reply.vendor_rsp[0] = EXT_STATUS_OK;
> +
> + bsg_job->reply_len = sizeof(struct fc_bsg_reply);
> + bsg_job->reply->result = DID_OK << 16;
> + bsg_job->job_done(bsg_job);
> + return 0;
> +}
> +
> +static int
> qla2x00_process_vendor_specific(struct fc_bsg_job *bsg_job)
> {
> switch (bsg_job->request->rqst_data.h_vendor.vendor_cmd[0]) {
> @@ -2241,6 +2293,9 @@ qla2x00_process_vendor_specific(struct fc_bsg_job
> *bsg_job)
> case QL_VND_SET_FLASH_UPDATE_CAPS:
> return qla27xx_set_flash_upd_cap(bsg_job);
>
> + case QL_VND_GET_BBCR_DATA:
> + return qla27xx_get_bbcr_data(bsg_job);
> +
> default:
> return -ENOSYS;
> }
> diff --git a/drivers/scsi/qla2xxx/qla_bsg.h b/drivers/scsi/qla2xxx/qla_bsg.h
> index 6c45bf4..4275177 100644
> --- a/drivers/scsi/qla2xxx/qla_bsg.h
> +++ b/drivers/scsi/qla2xxx/qla_bsg.h
> @@ -27,6 +27,7 @@
> #define QL_VND_SERDES_OP_EX 0x14
> #define QL_VND_GET_FLASH_UPDATE_CAPS0x15
> #define QL_VND_SET_FLASH_UPDATE_CAPS0x16
> +#define QL_VND_GET_BBCR_DATA0x17
>
> /* BSG Vendor specific subcode returns */
> #define EXT_STATUS_OK0
> @@ -239,4 +240,27 @@ struct qla_flash_update_caps {
> uint32_t outage_duration;
> uint8_t reserved[20];
> } __packed;
> +
> +/* BB_CR Status */
> +#define QLA_BBCR_STATUS_DISABLED 0
> +#define QLA_BBCR_STATUS_ENABLED1
> +
> +/* BB_CR State */
> +#define QLA_BBCR_STATE_OFFLINE 0
> +#define QLA_BBCR_STATE_ONLINE 1
> +
> +/* BB_CR Offline Reason Code */
> +#define QLA_BBCR_REASON_PORT_SPEED 1
> +#define QLA_BBCR_REASON_PEER_PORT 2
> +#define QLA_BBCR_REASON_SWITCH 3
> +#define QLA_BBCR_REASON_LOGIN_REJECT 4
> +
> +struct qla_bbcr_data {
> + uint8_t status; /* 1 - enabled, 0 - Disabled */
> + uint8_t state; /* 1 - online, 0 - offline */
> + uint8_t configured_bbscn; /* 0-15 */
> + uint8_t negotiated_bbscn; /* 0-15 */
> + uint8_t offline_reason_code;
> + uint8_t reserved[11];
> +} __packed;
> #endif
> diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
> index 987480f..c4bd62a 100644
> --- a/drivers/scsi/qla2xxx/qla_def.h
> +++ b/drivers/scsi/qla2xxx/qla_def.h
> @@ -3583,6 +3583,7 @@ typedef struct scsi_qla_host {
> uint32_tdelete_progress:1;
>
> uint32_tfw_tgt_reported:1;
> + uint32_tbbcr_enable:1;
> } flags;
>
> atomic_tloop_state;
> @@ -3715,6 +3716,7 @@ typede
Re: [LSF/MM TOPIC] NVMe target support
I think the frame is wrong, nevermind that I doubt I'll be able to discuss anything NVMe Fabrics related before the spec is public. Which I doubt is in time for LSF/MM. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/11] qla2xxx: Allow fw to hold status before sending ABTS response.
On Wed, Jan 27, 2016 at 12:03:30PM -0500, Himanshu Madhani wrote:
> Set bit 12 of additional firmware options 3 to let firmware
> hold status IOCB until ABTS response is received from Target.
>
> Signed-off-by: Himanshu Madhani
> Signed-off-by: Giridhar Malavali
> ---
> drivers/scsi/qla2xxx/qla_gbl.h |1 +
> drivers/scsi/qla2xxx/qla_init.c | 11 ++-
> drivers/scsi/qla2xxx/qla_os.c |7 +++
> 3 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
> index 0103e46..1bfdcdf 100644
> --- a/drivers/scsi/qla2xxx/qla_gbl.h
> +++ b/drivers/scsi/qla2xxx/qla_gbl.h
> @@ -121,6 +121,7 @@ extern int ql2xmdcapmask;
> extern int ql2xmdenable;
> extern int ql2xexlogins;
> extern int ql2xexchoffld;
> +extern int ql2xfwholdabts;
>
> extern int qla2x00_loop_reset(scsi_qla_host_t *);
> extern void qla2x00_abort_all_cmds(scsi_qla_host_t *, int);
> diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
> index a663ff6..cf487b9 100644
> --- a/drivers/scsi/qla2xxx/qla_init.c
> +++ b/drivers/scsi/qla2xxx/qla_init.c
> @@ -2062,6 +2062,10 @@ qla24xx_update_fw_options(scsi_qla_host_t *vha)
> if (IS_P3P_TYPE(ha))
> return;
>
> + /* Hold status IOCBs until ABTS response received. */
> + if (ql2xfwholdabts)
> + ha->fw_options[3] |= BIT_12;
> +
> /* Update Serial Link options. */
> if ((le16_to_cpu(ha->fw_seriallink_options24[0]) & BIT_0) == 0)
> return;
> @@ -6410,12 +6414,17 @@ qla81xx_update_fw_options(scsi_qla_host_t *vha)
> {
> struct qla_hw_data *ha = vha->hw;
>
> + /* Hold status IOCBs until ABTS response received. */
> + if (ql2xfwholdabts)
> + ha->fw_options[3] |= BIT_12;
> +
> if (!ql2xetsenable)
> - return;
> + goto out;
>
> /* Enable ETS Burst. */
> memset(ha->fw_options, 0, sizeof(ha->fw_options));
> ha->fw_options[2] |= BIT_9;
> +out:
> qla2x00_set_fw_options(vha, ha->fw_options);
> }
>
> diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
> index f1788db..d94a236 100644
> --- a/drivers/scsi/qla2xxx/qla_os.c
> +++ b/drivers/scsi/qla2xxx/qla_os.c
> @@ -233,6 +233,13 @@ MODULE_PARM_DESC(ql2xexchoffld,
>"Number of exchanges to offload. "
>"0 (Default)- Disabled.");
>
> +int ql2xfwholdabts = 0;
> +module_param(ql2xfwholdabts, int, S_IRUGO);
> +MODULE_PARM_DESC(ql2xfwholdabts,
> + "Allow FW to hold status IOCB until ABTS rsp received. "
> + "0 (Default) Do not set fw option. "
> + "1 - Set fw option to hold ABTS.");
> +
> /*
> * SCSI host template entry points
> */
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] qla2xxx: Remove unneeded link offline message.
On Wed, Jan 27, 2016 at 12:03:28PM -0500, Himanshu Madhani wrote:
> From: Chad Dupuis
>
> Signed-off-by: Chad Dupuis
> Signed-off-by: Himanshu Madhani
> ---
> drivers/scsi/qla2xxx/qla_dbg.c |1 +
> drivers/scsi/qla2xxx/qla_isr.c |4
> 2 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
> index cd0d94e..9e714cc 100644
> --- a/drivers/scsi/qla2xxx/qla_dbg.c
> +++ b/drivers/scsi/qla2xxx/qla_dbg.c
> @@ -27,6 +27,7 @@
> * | || 0x303a
> |
> * | DPC Thread | 0x4023 | 0x4002,0x4013 |
> * | Async Events | 0x5089 | 0x502b-0x502f |
> + * | || 0x505e |
> * | || 0x5084,0x5075
> |
> * | || 0x503d,0x5044 |
> * | || 0x507b,0x505f
> |
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index d4d65eb..edd97de 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -934,10 +934,6 @@ skip_rio:
> break;
>
> global_port_update:
> - /* Port unavailable. */
> - ql_log(ql_log_warn, vha, 0x505e,
> - "Link is offline.\n");
> -
> if (atomic_read(&vha->loop_state) != LOOP_DOWN) {
> atomic_set(&vha->loop_state, LOOP_DOWN);
> atomic_set(&vha->loop_down_timer,
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/11] qla2xxx: Seed init-cb login timeout from nvram exclusively.
On Wed, Jan 27, 2016 at 12:03:29PM -0500, Himanshu Madhani wrote: > From: Joe Carnuccio > > Signed-off-by: Joe Carnuccio > Signed-off-by: Himanshu Madhani > --- > drivers/scsi/qla2xxx/qla_init.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c > index 52a8765..a663ff6 100644 > --- a/drivers/scsi/qla2xxx/qla_init.c > +++ b/drivers/scsi/qla2xxx/qla_init.c > @@ -2844,7 +2844,6 @@ qla2x00_nvram_config(scsi_qla_host_t *vha) > if (nv->login_timeout < 4) > nv->login_timeout = 4; > ha->login_timeout = nv->login_timeout; > - icb->login_timeout = nv->login_timeout; > > /* Set minimum RATOV to 100 tenths of a second. */ > ha->r_a_tov = 100; > @@ -5274,7 +5273,6 @@ qla24xx_nvram_config(scsi_qla_host_t *vha) > if (le16_to_cpu(nv->login_timeout) < 4) > nv->login_timeout = cpu_to_le16(4); > ha->login_timeout = le16_to_cpu(nv->login_timeout); > - icb->login_timeout = nv->login_timeout; > > /* Set minimum RATOV to 100 tenths of a second. */ > ha->r_a_tov = 100; > @@ -6231,7 +6229,6 @@ qla81xx_nvram_config(scsi_qla_host_t *vha) > if (le16_to_cpu(nv->login_timeout) < 4) > nv->login_timeout = cpu_to_le16(4); > ha->login_timeout = le16_to_cpu(nv->login_timeout); > - icb->login_timeout = nv->login_timeout; > > /* Set minimum RATOV to 100 tenths of a second. */ > ha->r_a_tov = 100; > -- > 1.7.7 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html You really should be a bit more verbose in your commit messages... Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/15] megaraid_sas: Make adprecovery variable atomic
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Tuesday, January 19, 2016 7:23 PM
> To: Sumit Saxena; jbottom...@parallels.com; h...@infradead.org;
> martin.peter...@oracle.com
> Cc: linux-scsi@vger.kernel.org; kashyap.de...@avagotech.com
> Subject: Re: [PATCH 11/15] megaraid_sas: Make adprecovery variable
atomic
>
> On 18.12.2015 14:27, Sumit Saxena wrote:
> > Make instance->adprecovery variable atomic and removes hba_lock
spinlock
> while accessing instance->adprecovery.
>
> adprecovery is a 8bit int, you don't do any arithmetic with it, the
newly set
> values do not depend on previous values - I think that an atomic
variable is not
> needed.
I agree that this adprecovery can be made uint8_t but the purpose of
making "adprecovery" atomic was to remove "hba_lock" while reading and
setting adprecovery. hba_lock around reading/setting adprecovery was added
when OCR was implemented for MFI adapters. Here is the old patch which had
done this- http://www.spinics.net/lists/linux-scsi/msg43496.html
The reason of adding "hba_lock" around reading/setting adprecovery is
unknown so the intent was to keep the flow of original code same and make
it less costly by making adprecovery atomic instead of using "hba_lock" .
MFI adapters' support is EOL and we may not get test coverage if we do
major changes in MFI adapters' code path so keep this less riskier this
approach of making variable atomic was adopted.
>
> -tm
>
> >
> > Signed-off-by: Sumit Saxena
> > Signed-off-by: Kashyap Desai
> > ---
> > drivers/scsi/megaraid/megaraid_sas.h|2 +-
> > drivers/scsi/megaraid/megaraid_sas_base.c | 95
++-
> > drivers/scsi/megaraid/megaraid_sas_fusion.c | 27
> > 3 files changed, 50 insertions(+), 74 deletions(-)
> >
> > diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> > b/drivers/scsi/megaraid/megaraid_sas.h
> > index 9d2b3da..ac19d53 100644
> > --- a/drivers/scsi/megaraid/megaraid_sas.h
> > +++ b/drivers/scsi/megaraid/megaraid_sas.h
> > @@ -2101,7 +2101,7 @@ struct megasas_instance {
> > u16 drv_supported_vd_count;
> > u16 drv_supported_pd_count;
> >
> > - u8 adprecovery;
> > + atomic_t adprecovery;
> > unsigned long last_time;
> > u32 mfiStatus;
> > u32 last_seq_num;'
> > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> > b/drivers/scsi/megaraid/megaraid_sas_base.c
> > index edc26fb..5eaf6fd 100644
> > --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> > @@ -483,7 +483,7 @@ static int
> > megasas_check_reset_xscale(struct megasas_instance *instance,
> > struct megasas_register_set __iomem *regs) {
> > - if ((instance->adprecovery != MEGASAS_HBA_OPERATIONAL) &&
> > + if ((atomic_read(&instance->adprecovery) !=
> MEGASAS_HBA_OPERATIONAL)
> > +&&
> > (le32_to_cpu(*instance->consumer) ==
> > MEGASAS_ADPRESET_INPROG_SIGN))
> > return 1;
> > @@ -619,7 +619,7 @@ static int
> > megasas_check_reset_ppc(struct megasas_instance *instance,
> > struct megasas_register_set __iomem *regs) {
> > - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
> > + if (atomic_read(&instance->adprecovery) !=
> MEGASAS_HBA_OPERATIONAL)
> > return 1;
> >
> > return 0;
> > @@ -756,7 +756,7 @@ static int
> > megasas_check_reset_skinny(struct megasas_instance *instance,
> > struct megasas_register_set __iomem *regs)
{
> > - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL)
> > + if (atomic_read(&instance->adprecovery) !=
> MEGASAS_HBA_OPERATIONAL)
> > return 1;
> >
> > return 0;
> > @@ -950,9 +950,8 @@ static int
> > megasas_check_reset_gen2(struct megasas_instance *instance,
> > struct megasas_register_set __iomem *regs) {
> > - if (instance->adprecovery != MEGASAS_HBA_OPERATIONAL) {
> > + if (atomic_read(&instance->adprecovery) !=
> MEGASAS_HBA_OPERATIONAL)
> > return 1;
> > - }
> >
> > return 0;
> > }
> > @@ -998,7 +997,7 @@ megasas_issue_polled(struct megasas_instance
> *instance, struct megasas_cmd *cmd)
> > frame_hdr->cmd_status = MFI_STAT_INVALID_STATUS;
> > frame_hdr->flags |=
> cpu_to_le16(MFI_FRAME_DONT_POST_IN_REPLY_QUEUE);
> >
> > - if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
> > + if ((atomic_read(&instance->adprecovery) ==
> > +MEGASAS_HW_CRITICAL_ERROR) ||
> > (instance->instancet->issue_dcmd(instance, cmd))) {
> > dev_err(&instance->pdev->dev, "Failed from %s %d\n",
> > __func__, __LINE__);
> > @@ -1026,7 +1025,7 @@ megasas_issue_blocked_cmd(struct
> megasas_instance *instance,
> > int ret = 0;
> > cmd->cmd_status_drv = MFI_STAT_INVALID_STATUS;
> >
> > - if ((instance->adprecovery == MEGASAS_HW_CRITICAL_ERROR) ||
> > + if ((atomic_read(&instance->adprecovery) ==
> > +MEGASAS_HW_CRITICAL_ERROR) ||
> >
Re: [PATCH V2 2/2] scsi: storvsc: Use the specified target ID in device lookup
On Wed, Jan 27, 2016 at 06:22:45PM -0800, K. Y. Srinivasan wrote:
> The current code assumes that there is only one target in device lookup.
> Fix this bug. This will alow us to correctly handle hot reomoval of LUNs.
>
> Signed-off-by: K. Y. Srinivasan
> Reviewed-by: Alex Ng
> Tested-by: Vivek Yadav
> ---
> V2: Made lun and target_id unsigned 8 bit entities - Hannes Reinecke
>
>
> drivers/scsi/storvsc_drv.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 622f64a..132b168 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -478,19 +478,18 @@ struct hv_host_device {
> struct storvsc_scan_work {
> struct work_struct work;
> struct Scsi_Host *host;
> - uint lun;
> + u8 lun;
> + u8 tgt_id;
> };
>
> static void storvsc_device_scan(struct work_struct *work)
> {
> struct storvsc_scan_work *wrk;
> - uint lun;
> struct scsi_device *sdev;
>
> wrk = container_of(work, struct storvsc_scan_work, work);
> - lun = wrk->lun;
>
> - sdev = scsi_device_lookup(wrk->host, 0, 0, lun);
> + sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun);
> if (!sdev)
> goto done;
> scsi_rescan_device(&sdev->sdev_gendev);
> @@ -541,7 +540,7 @@ static void storvsc_remove_lun(struct work_struct *work)
> if (!scsi_host_get(wrk->host))
> goto done;
>
> - sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun);
> + sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun);
>
> if (sdev) {
> scsi_remove_device(sdev);
> @@ -941,6 +940,7 @@ static void storvsc_handle_error(struct vmscsi_request
> *vm_srb,
>
> wrk->host = host;
> wrk->lun = vm_srb->lun;
> + wrk->tgt_id = vm_srb->target_id;
> INIT_WORK(&wrk->work, process_err_fn);
> schedule_work(&wrk->work);
> }
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] scsi: storvsc: Install the storvsc specific timeout handler for FC devices
On Wed, Jan 27, 2016 at 06:22:44PM -0800, K. Y. Srinivasan wrote: > The default timeout routine used for FC transport is not > suitable for FC devices managed by storvsc since FC devices > managed by storvsc driver do not have an rport associated > with them. Use the time out handler used for SCSI devices > for FC devices as well. > > Signed-off-by: K. Y. Srinivasan > Reviewed-by: Alex Ng > Tested-by: Vivek Yadav > --- > drivers/scsi/storvsc_drv.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > index 41c115c..622f64a 100644 > --- a/drivers/scsi/storvsc_drv.c > +++ b/drivers/scsi/storvsc_drv.c > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > > /* > * All wire protocol details (storage protocol between the guest and the > host) > @@ -1770,6 +1771,11 @@ static int __init storvsc_drv_init(void) > fc_transport_template = fc_attach_transport(&fc_transport_functions); > if (!fc_transport_template) > return -ENODEV; > + > + /* > + * Install Hyper-V specific timeout handler. > + */ > + fc_transport_template->eh_timed_out = storvsc_eh_timed_out; > #endif > > ret = vmbus_driver_register(&storvsc_drv); > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
