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
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
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
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
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
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
---
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
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,
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
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.
>
>
> 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.
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
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
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
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
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
>
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
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
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
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 -
>
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 ++
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
---
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] -->
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
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
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
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
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
---
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
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
30 matches
Mail list logo