On 01/24/2014 09:34 AM, Desai, Kashyap wrote: > > >> -----Original Message----- >> From: Hannes Reinecke [mailto:hare@xxxxxxx] >> Sent: Friday, January 24, 2014 1:54 PM >> To: Desai, Kashyap; James Bottomley >> Cc: linux-scsi@xxxxxxxxxxxxxxx; Adam Radford; Saxena, Sumit >> Subject: Re: [PATCH 1/6] megaraid_sas: Do not wait forever >> >> On 01/24/2014 08:46 AM, Desai, Kashyap wrote: >>> Hannes: >>> >>> We have already worked on "wait_event" usage in >> "megasas_issue_blocked_cmd". >>> That code will be posted by LSI once we received test result from >> LSI Q/A team. >>> >>> If you see the current OCR code in Linux Driver we do "re-send the IOCTL >> command". >>> MR product does not want IOCTL timeout due to some reason. That is why >>> even if FW faulted, Driver will do OCR and re-send all existing >> <Management commands> >>> (IOCTL comes under management commands). >>> >>> Just for info. (see below snippet in OCR code) >>> >>> /* Re-fire management commands */ >>> for (j = 0 ; j < instance->max_fw_cmds; j++) { >>> cmd_fusion = fusion->cmd_list[j]; >>> if (cmd_fusion->sync_cmd_idx != (u32)ULONG_MAX) { >>> cmd_mfi = instance->cmd_list[cmd_fusion- >>> sync_cmd_idx]; >>> if (cmd_mfi->frame->dcmd.opcode == >> MR_DCMD_LD_MAP_GET_INFO) { >>> megasas_return_cmd(instance, cmd_mfi); >>> >>> megasas_return_cmd_fusion(instance, cmd_fusion); >>> >>> >>> >>> Current <MR> Driver is not designed to add <timeout> for DCMD and IOCTL >> path. >>> [ I added timeout only for limited DCMDs, which are harmless to >> continue after timeout ] >>> >>> As of now, you can skip this patch and we will be submitting patch to fix >> similar issue. >>> But note, we cannot add complete "wait_event_timeout" due to day-1 >>> design, but will try to cover wait_event_timout for some valid cases. >>> >> Ouch. >> >> The reason I sent this patch is that I've got an Intel box here, which blocks >> megaraid_sas initialisation when the IOMMU is turned on: >> >> [ 21.867264] megasas: io_request_frames ffff880800f50000 >> [ 21.867363] megasas: init frame 00000000fff57000 >> [ 22.223234] megasas: frame status 00 >> [ 22.223235] megasas: IOC Init cmd success >> [ 22.223282] megasas: ld map ffff88080b600000 >> [ 22.223289] megasas: issue dcmd 05 opcode 300e101 >> [ 22.244184] dmar: DRHD: handling fault status reg 2 >> [ 22.244186] dmar: DMAR:[DMA Read] Request device [06:00.0] fault >> addr 6980000 >> [ 22.244186] DMAR:[fault reason 06] PTE Read access is not set >> [ 22.247223] megasas: frame status 00 >> [ 22.247231] megasas: issue dcmd 05 opcode 300e101 >> [ 22.247231] megasas: INIT adapter done >> [ 22.247237] megasas: pd list ffff88080cfd0000 size 8192 >> [ 22.247237] megasas: issue dcmd 05 opcode 2010100 >> [ 22.253516] dmar: DRHD: handling fault status reg 102 >> [ 22.253518] dmar: DMAR:[DMA Write] Request device [06:00.0] fault >> addr e3f0000 >> [ 22.253518] DMAR:[fault reason 05] PTE Write access is not set >> [ 22.253521] dmar: DMAR:[DMA Write] Request device [06:00.0] fault >> addr e3f0000 >> [ 22.253521] DMAR:[fault reason 05] PTE Write access is not set >> [ 22.253523] dmar: DMAR:[DMA Write] Request device [06:00.0] fault >> addr e3f0000 >> >> [ Some more DMAR messages snipped ] >> >> [ 22.273199] dmar: DRHD: handling fault status reg 2 >> [ 22.273201] dmar: DMAR:[DMA Read] Request device [06:00.0] fault >> addr 6cef000 >> [ 22.273201] DMAR:[fault reason 06] PTE Read access is not set >> >> [ .. ] >> >> [ 94.222456] megasas: frame status ff >> [ 94.240946] megasas: failed to get PD list >> >> (I've inserted some debugging messages :-) >> >> This is really weird. The 'write' faults do correspond with the number of >> (megaraid) commands, reserved at the initial step. >> (This is a 'Fury' card, btw). > > Fury card has iMR FW and we have seen issue with iMR FW if IOMMU is ON, but not like driver load failure. > Is your OS driver behind Fury ? What is a Raid type used on your setup ? > It's SLES12 (alpha), basically plain 3.13 > Which system you are using ? > Pre-production hardware, admittedly. So it _might_ be a BIOS issue. >> What is more puzzling is that the INIT command and the initial LD List >> command goes through, but the PD List command gets blocked. >> >> Incidentally, this is not consistent; occasionally even the LD List command >> gets blocked, and the DMAR messages occur earlier. > > LD command use megasas_issue_polled which is already timeout based mechanism. > Below are list of DCMD command which use infinite timeout. > > megasas_get_seq_num > megasas_flush_cache > megasas_shutdown_controller > megasas_mgmt_fw_ioctl > > > We can convert all DCMD except IOCTL with timeout value. For you " megasas_get_seq_num" > might be hang in FW. It cannot be " megasas_get_ld_list". > Ahh. Okay, will try be modify megasas_get_seq_num() and see if that works. Cheers, Hannes P.S.: I've also send an earlier patch named 'megaraid_sas: disable controller reset for PPC' to linux-scsi. Care to review it, too? Thanks. -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
