Re: [PATCH 4/5] target: user: Fix sense data handling

Mike, On 7/11/17 02:26, Mike Christie wrote: > On 07/10/2017 12:36 AM, Damien Le Moal wrote: >> Nicholas, Mike, >> >> On 7/7/17 15:05, Nicholas A. Bellinger wrote: >>> Everything including MNC's #1-6 and your #1-2 be pushed to >>> target-pending/for-next shortly. >>> >>> Please use this as your

Re: [PATCH v2 0/4] scsi_dh_alua: fix stuck I/O after unavailable/standby states

On 07/10/2017 07:47 PM, Mauricio Faria de Oliveira wrote: This patchset addresses that problem, and adds a few improvements to the logging of PG state changes. Here are some kernel log snippets with the patchset, if that helps. The 2 port groups temporarily gone into unavailable state, and

[PATCH v2 2/4] scsi: scsi_dh_alua: print changes to RTPG state of all PGs

Currently, alua_rtpg() can change the 'state' and 'preferred' values for the current port group _and_ of other port groups. However, it reports that _only_ for the current port group. This might cause uncertainty and confusion when going through the kernel logs for analyzing/debugging

[PATCH v2 1/4] scsi: scsi_dh_alua: allow I/O in target port unavailable and standby states

According to SPC-4 (5.15.2.4.5 Unavailable state), the unavailable state may (or may not) transition to other states (e.g., microcode downloading or hardware error, which may be temporary or permanent). But, scsi_dh_alua currently fails I/O requests early on once that state occurs (in

[PATCH v2 3/4] scsi: scsi_dh_alua: do not print RTPG state if it remains unavailable/standby

Path checkers will check paths of a port group in unavailable/standby state more frequently (as they are 'failed') - possibly for a long or indefinite period of time, and/or for a large number of paths. That might flood the kernel log with scsi_dh_alua RTPG state messages, due to the recheck

[PATCH v2 4/4] scsi: scsi_dh_alua: add sdev_dbg() to track alua_rtpg_work()

Insert sdev_dbg() calls in the function path which may queue alua_rtpg_work() past initialization, for debugging purposes: - alua_activate() - alua_check_sense() - alua_rtpg_queue() Signed-off-by: Mauricio Faria de Oliveira ---

[PATCH v2 0/4] scsi_dh_alua: fix stuck I/O after unavailable/standby states

Currently, scsi_dh_alua fails I/O requests early on once ALUA state unavailable/standby occur, which prevents path checkers to actually check if I/O still fails or now works. Then I/O requests are blocked indefinitely due to queue_if_no_path but the underlying individual paths are fully

RE: device support in hpsa, was: Re: OOPS from cciss_ioctl in 4.12+git

So, adding adding hpsa_allow_any=1 did not work... When you added the 0x40800e11, did you add it to both tables? /* define the PCI info for the cards we can control */ static const struct pci_device_id hpsa_pci_device_id[] = { {PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_CISSB, 0x0E11,

Re: [PATCH 4/5] target: user: Fix sense data handling

On 07/10/2017 12:36 AM, Damien Le Moal wrote: > Nicholas, Mike, > > On 7/7/17 15:05, Nicholas A. Bellinger wrote: >> Everything including MNC's #1-6 and your #1-2 be pushed to >> target-pending/for-next shortly. >> >> Please use this as your base for testing. :) > > I ran tests this morning

Re: [PATCH] scsi: default to scsi-mq

On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote: > Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq I/O > path now that we had plenty of testing, and have I/O schedulers for > blk-mq. The module option to disable the blk-mq path is kept around > for now. > >

Re: device support in hpsa, was: Re: OOPS from cciss_ioctl in 4.12+git

> On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote: > > What happens when hpsa_allow_any=1 with the Smart Array 64xx > > It should probe. > > But only if it has a HP vendor ID as far as I can tell. We'd > still need to add the compaq ids so that these controllers get > probed.

Re: [PATCH v2 07/15] megaraid_sas: Check valid aen class range to avoid kernel panic

On 5.7.2017 14:00, Shivasharan S wrote: > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl tomash

Re: [PATCH v2 06/15] megaraid_sas: Fix endianness issues in DCMD handling

On 5.7.2017 14:00, Shivasharan S wrote: > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl tomash

Re: [PATCH v2 05/15] megaraid_sas: Do not re-fire shutdown DCMD after OCR

On 5.7.2017 14:00, Shivasharan S wrote: > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl tomash

Re: [PATCH v2 04/15] megaraid_sas: Call megasas_complete_cmd_dpc_fusion every 1 second while there are pending commands

On 5.7.2017 14:00, Shivasharan S wrote: > Fix - megasas_wait_for_outstanding_fusion checks for pending commands every > 1second. But megasas_complete_cmd_dpc_fusion is only called every 5seconds. > If the commands are already completed by firmware, there is an additional > delay of 5seconds before

Re: [PATCH v2 03/15] megaraid_sas: Use synchronize_irq in target reset case

On 5.7.2017 14:00, Shivasharan S wrote: > Similar to task abort case, use synchronize_irq API in target reset case. > Also, remove redundant call to megasas_complete_cmd_dpc_fusion > after calling megasas_sync_irqs in task abort case. > > Signed-off-by: Kashyap Desai >

Re: [PATCH v2 02/15] megaraid_sas: set minimum value of resetwaittime to be 1 secs

On 5.7.2017 14:00, Shivasharan S wrote: > Setting resetwaittime to 0 during a FW fault will result in driver > not calling the OCR. > > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke

Re: [PATCH v2 01/15] megaraid_sas: mismatch of allocated MFI frame size and length exposed in MFI MPT pass through command

On 5.7.2017 14:00, Shivasharan S wrote: > Fix - Driver allocated 256 byte MFI frames bytes but while sending MFI > frame (embedded inside chain frame of MPT frame) to firmware, driver > sets the length as 4k. This results in DMA read error messages during > boot. > > Signed-off-by: Kashyap

Re: [PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

Douglas, > Has there been any progress with getting this patch accepted? > It has been merged already. It's in linux-next, commit 62e62ffd95539b9220894a7900a619e0f3ef4756 https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/62e62ffd95539b9220894a7900a619e0f3ef4756

Re: [PATCH v2 09/15] megaraid_sas: use vmalloc for crash dump buffers and driver's local RAID map

On 5.7.2017 14:00, Shivasharan S wrote: > Signed-off-by: Kashyap Desai > Signed-off-by: Shivasharan S > Reviewed-by: Hannes Reinecke > --- > drivers/scsi/megaraid/megaraid_sas.h| 1 - >

Re: [PATCH] ses: do not add a device to an enclosure if enclosure_add_links() fails.

On 06/27/2017 07:50 AM, Douglas Miller wrote: On 06/27/2017 04:53 AM, Maurizio Lombardi wrote: The enclosure_add_device() function should fail if it can't create the relevant sysfs links. Signed-off-by: Maurizio Lombardi --- drivers/misc/enclosure.c | 14 ++

[PATCH] scsi: qla2xxx: Off by one in qlt_ctio_to_cmd()

There are "req->num_outstanding_cmds" elements in the req->outstanding_cmds[] array so the > here should be >=. Signed-off-by: Dan Carpenter diff --git a/drivers/scsi/qla2xxx/qla_target.c b/drivers/scsi/qla2xxx/qla_target.c index 6e4794367e0b..ecd1a95511f9 100644 ---

[PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

Now libsas hotplug work is static, every sas event type has its own static work, LLDD driver queue the hotplug work into shost->work_q. If LLDD driver burst post lots hotplug events to libsas, the hotplug events may pending in the workqueue like shost->work_q new work[PORTE_BYTES_DMAED] -->

[PATCH v3 6/7] libsas: add wait-complete support to sync discovery event

Introduce a sync flag to tag discovery event whether need to sync execute, per-event wait-complete ensure sync. Signed-off-by: Yijing Wang CC: John Garry CC: Johannes Thumshirn CC: Ewan Milne CC: Christoph

[PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event

Sometimes, we want sync libsas probe or destruct in sas discovery work, like when libsas revalidate domain. We need to split probe and destruct work from the scsi host workqueue. Signed-off-by: Yijing Wang CC: John Garry CC: Johannes Thumshirn

[PATCH v3 4/7] libsas: add sas event wait-complete support

Introduce wait-complete for libsas sas event processing, execute sas port create/destruct in sync. Signed-off-by: Yijing Wang CC: John Garry CC: Johannes Thumshirn CC: Ewan Milne CC: Christoph Hellwig

[PATCH v3 3/7] libsas: Use new workqueue to run sas event

Now all libsas works are queued to scsi host workqueue, include sas event work post by LLDD and sas discovery work, and a sas hotplug flow may be divided into several works, e.g libsas receive a PORTE_BYTES_DMAED event, now we process it as following steps: sas_form_port --- run in work in shot

[PATCH v3 2/7] libsas: remove unused port_gone_completion

No one uses the port_gone_completion in struct asd_sas_port, clean it out. Signed-off-by: Yijing Wang --- include/scsi/libsas.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h index c41328d..628f48b 100644 ---

[PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev

Disco mutex was introudced to prevent domain rediscovery competing with ata error handling(87c8331). If we have already hold the lock in sas_revalidate_domain and sync executing probe, deadlock caused, because, sas_probe_sata() also need hold disco_mutex. Since disco mutex use to prevent

[PATCH v3 0/7] Enhance libsas hotplug feature

This patchset is based Johannes's patch "scsi: sas: scsi_queue_work can fail, so make callers aware" Now the libsas hotplug has some issues, Dan Williams report a similar bug here before https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The issues we have found 1. if LLDD