Re: 4.15.14 crash with iscsi target and dvd
On Sat, 2018-03-31 at 18:12 -0400, Wakko Warner wrote: > Richard Weinberger wrote: > > On Sat, Mar 31, 2018 at 3:59 AM, Wakko Warner wrote: > > > I reported this before but noone responded. > > > > Because you're sending only to LKML. > > CC'ing storage folks. > > Thank you. I wasn't sure who I needed to send it to. Hello Wakko, Can you share the output of lsscsi? I would like to know whether or not you are using a (S)ATA CDROM. Thanks, Bart.
Re: 4.15.14 crash with iscsi target and dvd
Richard Weinberger wrote: > On Sat, Mar 31, 2018 at 3:59 AM, Wakko Warner wrote: > > I reported this before but noone responded. > > Because you're sending only to LKML. > CC'ing storage folks. Thank you. I wasn't sure who I needed to send it to.
Re: 4.15.14 crash with iscsi target and dvd
On Sat, Mar 31, 2018 at 3:59 AM, Wakko Warner wrote: > I reported this before but noone responded. Because you're sending only to LKML. CC'ing storage folks. > I have an iscsi target setup with /dev/sr[012] using pscsi. On the > initiator, I mount only 1 disc. Then I issue find -type f | xargs cat > > /dev/null Then after a few seconds, I get 2 oops and the system has to be > hard reset. > > I noticed if I cat /dev/sr1 from the initiator, it doesn't crash. I was > also able to burn without crashing. > > Here's the OOPS: > [2692.733468] WARNING: CPU: 8 PID: 0 at > /usr/src/linux/dist/4.15.14-nobklcd/drivers/scsi/scsi_lib.c:1068 > scsi_init_io+0x111/0x1a0 [scsi_mod] > [2692.734154] Modules linked in: dm_thin_pool dm_persistent_data > dm_bio_prison dm_bufio raid456 async_raid6_recov async_memcpy async_pq > async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod dm_crypt > algif_skcipher af_alg dm_mod dax ext4 crc16 mbcache jbd2 af_packet > iscsi_target_mod tcm_loop vhost_scsi vhost target_core_file > target_core_iblock target_core_pscsi target_core_mod nfsd exportfs dummy > bridge stp llc ib_iser rdma_cm iw_cm ib_cm ib_core ipv6 iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi netconsole configfs sr_mod cdrom > adt7475 hwmon_vid sd_mod sg coretemp x86_pkg_temp_thermal kvm_intel kvm > irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc > snd_hda_codec_realtek snd_hda_codec_generic nouveau video led_class > drm_kms_helper cfbfillrect syscopyarea cfbimgblt > [2692.737388] sysfillrect sysimgblt snd_hda_intel fb_sys_fops cfbcopyarea > snd_hda_codec ttm snd_hda_core snd_pcm_oss drm snd_mixer_oss agpgart snd_pcm > igb snd_timer snd aesni_intel soundcore hwmon aes_x86_64 i2c_algo_bit ahci > mpt3sas crypto_simd i2c_core libahci glue_helper mptsas raid_class libata > mptscsih scsi_transport_sas mptbase scsi_mod wmi button unix > [2692.737388] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 4.15.14 #1 > [2692.737388] Hardware name: Dell Inc. Precision T5610/0WN7Y6, BIOS A16 > 02/05/2018 > [2692.737388] RIP: 0010:scsi_init_io+0x111/0x1a0 [scsi_mod] > [2692.737388] RSP: 0018:8806b7a03d78 EFLAGS: 00010046 > [2692.737388] RAX: RBX: 8806aa4a9c00 RCX: > > [2692.737388] RDX: RSI: 8806aa4a9c00 RDI: > 8806aa4a9d48 > [2692.737388] RBP: 8806aa4a9d48 R08: R09: > 8806aa4a9d80 > [2692.737388] R10: 8806ab949088 R11: R12: > 8806b29bb000 > [2692.737388] R13: R14: 8806b29bb000 R15: > 8806ac4f6950 > [2692.737388] FS: () GS:8806b7a0() > knlGS: > [2692.737388] CS: 0010 DS: ES: CR0: 80050033 > [2692.737388] CR2: 7f1359a8b756 CR3: 01c09003 CR4: > 001606e0 > [2692.737388] Call Trace: > [2692.737388] > [2692.737388] ? scsi_setup_cmnd+0xb3/0x140 [scsi_mod] > [2692.737388] ? scsi_prep_fn+0x53/0x130 [scsi_mod] > [2692.737388] ? blk_peek_request+0x136/0x220 > [2692.737388] ? scsi_request_fn+0x2b/0x510 [scsi_mod] > [2692.737388] ? __blk_run_queue+0x34/0x50 > [2692.737388] ? blk_run_queue+0x26/0x40 > [2692.737388] ? scsi_run_queue+0x229/0x2b0 [scsi_mod] > [2692.737388] ? scsi_io_completion+0x3ce/0x5a0 [scsi_mod] > [2692.737388] ? blk_done_softirq+0x67/0x80 > [2692.737388] ? __do_softirq+0xdb/0x1dd > [2692.737388] ? irq_exit+0xa3/0xb0 > [2692.737388] ? do_IRQ+0x45/0xc0 > [2692.737388] ? common_interrupt+0x77/0x77 > [2692.737388] > [2692.737388] ? cpuidle_enter_state+0x124/0x200 > [2692.737388] ? cpuidle_enter_state+0x119/0x200 > [2692.737388] ? do_idle+0xdc/0x180 > [2692.737388] ? cpu_startup_entry+0x14/0x20 > [2692.737388] ? secondary_startup_64+0xa5/0xb0 > [2692.737388] Code: 8b 7b 30 e8 d2 6b 20 e1 49 8b 17 4c 89 ff 89 c6 89 44 24 > 04 e8 81 81 22 e1 85 c0 41 89 c4 74 55 41 bc 02 00 00 00 e9 39 ff ff ff <0f> > 0b 41 bc 01 00 00 00 e9 2c ff ff ff 48 8b 3d 6b dc 00 00 be > [2692.737388] ---[ end trace 9801970f9b249e10 ]--- > [2692.737388] [ cut here ] > [2692.737388] kernel BUG at > /usr/src/linux/dist/4.15.14-nobklcd/block/blk-core.c:3235! > [2692.737388] invalid opcode: [#1] PREEMPT SMP > [2692.737388] Modules linked in: dm_thin_pool dm_persistent_data > dm_bio_prison dm_bufio raid456 async_raid6_recov async_memcpy async_pq > async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod dm_crypt > algif_skcipher af_alg dm_mod dax ext4 crc16 mbcache jbd2 af_packet > iscsi_target_mod tcm_loop vhost_scsi vhost target_core_file > target_core_iblock target_core_pscsi target_core_mod nfsd exportfs dummy > bridge stp llc ib_iser rdma_cm iw_cm ib_cm ib_core ipv6 iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi netconsole configfs sr_mod cdrom > adt7475 hwmon_vid sd_mod sg coretemp x86_pkg_temp_thermal kvm_intel kvm > irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc
Re: Multi-Actuator SAS HDD First Look
On 2018-03-30 04:01 PM, Bart Van Assche wrote: On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote: Yes I will be there to discuss the multi-LUN approach. I wanted to get these interface details out so we could have some background and perhaps folks would come with ideas. I don't have much more to put out, but I will certainly answer questions - either on this list or directly. Hello Tim, As far as I know the Linux SCSI stack does not yet support any SCSI devices for which a single SCSI command affects multiple (two in this case) LUNs. Adding such support may take significant work. There will also be the disadvantage that most SCSI core contributors do not have access to a multi- actuator device and hence that their changes may break support for multi- actuator devices. Hmmm, INQUIRY (3PC bit) and REPORT LUNS seem to be counter examples to Bart's assertion. Plus there are a more that tell you about things outside the addressed LU, for example the SCSI Ports VPD page tells you about other SCSI ports hence other LUs) on the current device. From Tim's command list: Device level 0x0, 0x1: okay 0x4 (Format unit): yikes, that could be a nasty surprise, accessing a file system on the other LU and getting an error "Not ready, format in progress"!! 0x12: standard INQUIRY okay, VPD pages not so much LU id different; relative port id, different; target port id different (at the least) 0x1b (SSU): storage LUs need to know this model, otherwise the logic on each LU could get into a duel: "I want it spun up; no, I want it spun down ..." 0x35, 0x37, 0x3b, 0x3c: okay 0x48 (sanitize): similar to Format unit above 0x91,0x4c,0x4d: okay MODE SENSE/SELECT(6,10): depends on page, block descriptor needs to be partially device level (since LB size may be changed by FU which is device level) rest of device level: okay or (I) don't know 0xf7: READ UDS DATA, that's interesting, but proprietary I guess Perhaps you could add a rider on FU and SAN: they get rejected unless the other storage LU is in (logical) spun down state. LU specific --- all okay, I hoping READ(6,10,12,16,32) and their WRITE cousins will be there also :-) Plus the TMF: LU reset Device or LU all okay I'm intrigued by your 3 LU model. My wish list for that: LUN 0 would be processor device type (0x3) so it wouldn't confuse the OS (Linux) that it held storage (READ CAPACITY is mandatory for PDT 0x0 and cannot represent a 0 block LU) and you could pick and choose which SCSI commands to implement on it. LUN 0 TUR could report what the spindle was really doing, SSU could do precisely what it is told (and SSU on LUNs 1 and 2 would be an "and" for spin down and an "or" for spin up). I've got several boxes full of SAS cables and only one cable that I can think of that lets me get to the secondary SAS port. So on LUN 0 you could have a proprietary (unless T10 takes it on board) mode page to enable the user to say which ports that LUNs 1 and 2 where accessible on. Obviously LUN 0 would need to be accessible on both ports. [A non-accessible LUN would still respond to INQUIRY but with a first byte of 07f: PDT=0x1f (unknown) and PQ=3 which implies it is there but inaccessible via the current port.] A processor PDT opens up the possibility of putting a copy manager on LUN 0. Think offloaded (from main machine's perspective) backups and restores where LUN 1 or 2 is the source or destination. Enough dreaming. Doug Gilbert
Re: [PATCH 13/25] tcm_qla2xxx: Do not allow aborted cmd to advance.
On Sun, 2017-05-21 at 21:45 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2017-05-19 at 14:53 -0700, Himanshu Madhani wrote:
> > From: Quinn Tran
> >
> > In case of hardware queue full, commands can loop between
> > TCM stack and tcm_qla2xx shim layers for retry. While command
> > is waiting for retry, task mgmt can get ahead and abort the
> > cmmand that encountered queue full condition. Fix this by
> > dropping the command, if task mgmt has already started the
> > command free process.
> >
> > Cc:
> > Signed-off-by: Quinn Tran
> > Signed-off-by: Himanshu Madhani
> > ---
> > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
> > b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
> > index 7443e4efa3ae..07f8ad001bcb 100644
> > --- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
> > +++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
> > @@ -686,6 +686,20 @@ static int tcm_qla2xxx_queue_status(struct
> > se_cmd *se_cmd)
> > struct qla_tgt_cmd, se_cmd);
> > int xmit_type = QLA_TGT_XMIT_STATUS;
> >
> > + if (cmd->aborted) {
> > + /*
> > + * Cmd can loop during Q-full.
> > tcm_qla2xxx_aborted_task
> > + * can get ahead of this cmd.
> > tcm_qla2xxx_aborted_task
> > + * already kick start the free.
> > + */
> > + pr_debug(
> > + "queue_data_in aborted cmd[%p] refcount %d
> > transport_state %x, t_state %x, se_cmd_flags %x\n",
> > + cmd, kref_read(&cmd->se_cmd.cmd_kref),
> > + cmd->se_cmd.transport_state, cmd-
> > >se_cmd.t_state,
> > + cmd->se_cmd.se_cmd_flags);
> > + return 0;
> > + }
> > +
> > cmd->bufflen = se_cmd->data_length;
> > cmd->sg = NULL;
> > cmd->sg_cnt = 0;
>
> As your comment above mentions, there is a known issue in target-core
> when queue-full occurs repeatably and a se_cmd descriptor is
> explicitly
> stopped via session shutdown, TMR ABORT_TASK / LUN_RESET or
> otherwise.
>
> We hit this scenario a while back in iser-target with iw_cxgb hw,
> which
> due to a separate bug was constantly triggering queue-full under load
> to
> uncover this same case.
>
> So I'm still considering the different approaches to address this in
> target-core proper, but don't have a problem with merging this as-is
> as
> it won't logically conflict with any of those changes.
>
> That said:
>
> Acked-by: Nicholas Bellinger
>
Indeed the queue-full issue has been there for quite a while in the
core.
Affects ISER, SRP and F/C (tcm_qla2xxx)
Re: [PATCH] Patch to replace DEFINE_SEMAPHORE with DEFINE_BINARY_SEMAPHORE
On Sat, Mar 31, 2018 at 07:16:21PM +0530, Wasim Nazir wrote: > This message contains confidential information and is intended only for the > individual(s) named. If you are not the intended recipient, you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this mail and attached file/s is strictly > prohibited. Please notify the sender immediately and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secured or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. This footer is not compatible with patches submitted to the kernel, sorry. email is now deleted. greg k-h
Re: Multi-Actuator SAS HDD First Look
On 03/30/2018 08:07 PM, Tim Walker wrote: > Hello- > > Concerning how we are currently allocating commands to LUNs or the > device as a whole, here is a list based on the current two LUN model. > This model has LUN0 & LUN1, both reporting 1/2 the total storage. Our > definition of "device based" is that it ignores the LUN field and > executes the command on the entire device. In other words, sending a > device based command to LUN1 will also act on LUN0. "LUN-based" > commands affect only the LUN they're addressed to. I'm soliciting > feedback and suggestions, as well as subject matter experts to point > out pain points and incompatibilities. Thank you for your input. > Uh. You will have fun pushing that past T-10 ... > These commands ignore the LUN field and affect all LUNs on the device: > 0x00: TEST UNIT READY. Applies to entire device. The drive will return > a GOOD status only if both LUNs can service medium access commands. Please, don't. TEST UNIT READY is the _only_ command at SPC level allowing us to check the state of the LUN. Moving that up the device (ie target) level is leaving us with no idea about the status of the actual LUN. > 0x01: REZERO. Applies to entire device. The command will force the > seek to LBA 0 on both LUNs. The thermal compensation and other actions > are also taken at both LUNs (actuators)." Why? Is there any necessity that a REZERO of one LUN has a dependency on the other? > 0x04: FORMAT UNIT. Applies to entire device. The format parameters are > applied to both LUN's. The format operation is done in parallel on the > two LUN's. Format with defect list is not supported for the Dual LUN > drive." Again, why? Just for performance reasons? That surely can be done by issuing a FORMAT UNIT command asynchonously to both devices ... > 0x12: INQUIRY. Applies to entire device. The same information is > returned for the Inquiry command regardless of LUN setting. Each LUN > has different identifier. Strongly against it. INQUIRY is _THE_ prime identifer of the LUN, Both LUNs might return the same INQUIRY data, at the very least page 0x93 of the VPD data _NEEDS_ to be different both both LUNs. Please keep it at LUN level. > 0x1B: START STOP UNIT. Applies to entire device. The command will > apply to both actuators - it will cause both actuators to be either > spin down or spin-up depending on the command options. If the command > fails on either actuator check condition is returned. Already discussed. Probably no other way around it. > 0x35: SYNCRONIZE CACHE. Applies to entire device. This will be a > device command and only support the option to flush the entire cache. > The drive does not support the flush of a particular LBA range only. Fine with that; most HBAs have the same limitation. > 0x37: READ DEFECT DATA (10). Applies to entire device. Device based > defect list is returned - this will include the defects from both the > LUNs. The heads are sequentially numbered across both LUNs. Hmm. Again, why? > 0x3B: WRITE BUFFER (10) Download. Applies to entire device. This is a > device based command - as part of the download the code on both the > LUN's will be updated. About to be expected. Okay. > 0x3B: WRITE BUFFER (10) other than download. Applies to entire device. > Other than download Device based command - there is only one common > buffer for the two LUNs. See above. Okay. > 0x3C: READ BUFFER (10). Applies to entire device. Device based command > - there is only one common buffer for the two LUNs. Might be worthwhile adding a new option to READ/WRITE BUFFER (eg using one of the bits before the 'MODE' field), specifying that this command applies to all LUNs on this device. > 0x48 0x01: SANITIZE overwrite. Applies to entire device. Treated as a > device level command - sanitize operation performed on both LUNs when > command received.> 0x48 0x03: SANITIZE security erase. Applies to entire > device. Treated > as a device level command - sanitize operation performed on both LUNs > when command received. > 0x48 0x1F: SANITIZE exit failure mode. Applies to entire device. Emphatically no. That would allow one application on one LUN erasing the contents of the other LUN, which might be in use by a completely different application. > 0x91: SYNCRONIZE CACHE (16). Applies to entire device. Same as Sync Cache. > 0x4C: LOG SELECT (10). Applies to entire device. One global set of log > pages for both LUNs. Any LBA information is stored as an internal LBA > value, i.e. LUN1 LBAs start at LUN0 last_LBA + 1. > 0x4D: LOG SENSE (10). Applies to entire device. One global set of log > pages for both LUNs. Any LBA information is stored as an internal LBA > value, i.e. LUN1 LBAs start at LUN0 last_LBA + 1. > 0x55: MODE SELECT (10). Applies to entire device. Same as Mode select. > 0x5A: MODE SENSE (10). Applies to entire device. Same as Mode sense. > 0x9E 0x17: GET PHYSICAL ELEMENT STATUS. Applies to entire device. > 0x9E 0x18: REMOVE ELEMENT AND TRUNCATE. Applies to entire device. > 0
Re: Multi-Actuator SAS HDD First Look
On 03/30/2018 03:07 PM, Tim Walker wrote: > Hi Doug- > > Currently, the dual actuator firmware safely spins the drive down if > either LUN receives the START STOP UNIT command. In other words, if > LUN1 receives the command, it will flush any dirty data from LUN1l and > LUN0, then spin down, taking both LUN1 & LUN0 off line. Alternatively, > we've had input that either: > a) Both LUNs must receive the START STOP UNIT command before the drive > will spin down, OR > b) Move the storage to LUN1 & LUN2, keeping LUN0 (with no storage) for > device specific commands such as START STOP UNIT that do not directly > access the media. > That will get interesting when suspending the device; physical interactions between independent LUNs are always tricky. And I don't even want to imagine the implications when assigning each LUN to individual VM guests; shutting down one VM will also interfere with the other VM ... shudder. Actually I would propose to have a 'management' LUN at LUN0, who could handle all the device-wide commands (eg things like START STOP UNIT, firmware update, or even SMART commands), and ignoring them for the remaining LUNs. I guess that would make the whole setup easier to handle. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 11/15] mpt3sas: Report Firmware Package Version from HBA Driver.
Hi Chaitra,
I love your patch! Perhaps something to improve:
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on next-20180329]
[cannot apply to scsi/for-next v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chaitra-P-B/mpt3sas-Enhancements-and-Defect-fixes/20180331-123801
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/scsi/mpt3sas/mpt3sas_base.c:3878:32: sparse: incorrect type in
>> assignment (different base types) @@expected restricted __le32
>> [usertype] ImageSize @@got unsigned long [unsrestricted __le32
>> [usertype] ImageSize @@
drivers/scsi/mpt3sas/mpt3sas_base.c:3878:32:expected restricted __le32
[usertype] ImageSize
drivers/scsi/mpt3sas/mpt3sas_base.c:3878:32:got unsigned long [unsigned]
[assigned] [usertype] data_length
>> drivers/scsi/mpt3sas/mpt3sas_base.c:3903:63: sparse: incorrect type in
>> assignment (different base types) @@expected restricted __le32
>> [usertype] Word @@got unsignrestricted __le32 [usertype] Word @@
drivers/scsi/mpt3sas/mpt3sas_base.c:3903:63:expected restricted __le32
[usertype] Word
drivers/scsi/mpt3sas/mpt3sas_base.c:3903:63:got unsigned int [unsigned]
[usertype]
drivers/scsi/mpt3sas/mpt3sas_base.c:3906:41: sparse: restricted __le32
degrades to integer
drivers/scsi/mpt3sas/mpt3sas_base.c:3906:41: sparse: restricted __le32
degrades to integer
drivers/scsi/mpt3sas/mpt3sas_base.c:3906:41: sparse: restricted __le32
degrades to integer
drivers/scsi/mpt3sas/mpt3sas_base.c:3906:41: sparse: restricted __le32
degrades to integer
vim +3878 drivers/scsi/mpt3sas/mpt3sas_base.c
3826
3827 /**
3828 * _base_display_fwpkg_version - sends FWUpload request to pull FWPkg
3829 * version from FW Image Header.
3830 * @ioc: per adapter object
3831 *
3832 * Returns 0 for success, non-zero for failure.
3833 */
3834 static int
3835 _base_display_fwpkg_version(struct MPT3SAS_ADAPTER *ioc)
3836 {
3837 Mpi2FWImageHeader_t *FWImgHdr;
3838 Mpi25FWUploadRequest_t *mpi_request;
3839 Mpi2FWUploadReply_t mpi_reply;
3840 int r = 0;
3841 void *fwpkg_data = NULL;
3842 dma_addr_t fwpkg_data_dma;
3843 u16 smid, ioc_status;
3844 size_t data_length;
3845
3846 dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
3847 __func__));
3848
3849 if (ioc->base_cmds.status & MPT3_CMD_PENDING) {
3850 pr_err(MPT3SAS_FMT "%s: internal command already in
use\n",
3851 ioc->name, __func__);
3852 return -EAGAIN;
3853 }
3854
3855 data_length = sizeof(Mpi2FWImageHeader_t);
3856 fwpkg_data = pci_alloc_consistent(ioc->pdev, data_length,
3857 &fwpkg_data_dma);
3858 if (!fwpkg_data) {
3859 pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
3860 ioc->name, __FILE__, __LINE__,
__func__);
3861 return -ENOMEM;
3862 }
3863
3864 smid = mpt3sas_base_get_smid(ioc, ioc->base_cb_idx);
3865 if (!smid) {
3866 pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n",
3867 ioc->name, __func__);
3868 r = -EAGAIN;
3869 goto out;
3870 }
3871
3872 ioc->base_cmds.status = MPT3_CMD_PENDING;
3873 mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
3874 ioc->base_cmds.smid = smid;
3875 memset(mpi_request, 0, sizeof(Mpi25FWUploadRequest_t));
3876 mpi_request->Function = MPI2_FUNCTION_FW_UPLOAD;
3877 mpi_request->ImageType = MPI2_FW_UPLOAD_ITYPE_FW_FLASH;
> 3878 mpi_request->ImageSize = data_length;
3879 ioc->build_sg(ioc, &mpi_request->SGL, 0, 0, fwpkg_data_dma,
3880 data_length);
3881 init_completion(&ioc->base_cmds.done);
3882 mpt3sas_base_put_smid_default(ioc, smid);
3883 /* Wait for 15 seconds */
3884 wait_for_completion_timeout(&ioc->base_cmds.done,
3885 FW_IMG_HDR_READ_TIMEOUT*HZ);
3886 pr_info(MPT3SAS_FMT "%s: complete\n",
3887 ioc->name, __func__);
3888
