Dan Carpenter | 8 Feb 19:21 2016
Picon

re: megaraid_sas: Task management support

Hello Sumit Saxena,

The patch 31796fa184ee: "megaraid_sas: Task management support" from
Jan 28, 2016, leads to the following static checker warning:

	drivers/scsi/megaraid/megaraid_sas_base.c:1788 megasas_update_sdev_properties()
	warn: if statement not indented

drivers/scsi/megaraid/megaraid_sas_base.c
  1781          } else {
  1782                  device_id = ((sdev->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL)
  1783                                          + sdev->id;
  1784                  local_map_ptr = fusion->ld_drv_map[(instance->map_id & 1)];
  1785                  ld = MR_TargetIdToLdGet(device_id, local_map_ptr);
  1786                  raid = MR_LdRaidGet(ld, local_map_ptr);
  1787  
  1788                  if (raid->capability.ldPiMode == MR_PROT_INFO_TYPE_CONTROLLER)
  1789                  blk_queue_update_dma_alignment(sdev->request_queue, 0x7);

It looks like the code is correct but the patch just deleted a tab
accidentally.

  1790                  mr_device_priv_data->is_tm_capable =
  1791                          raid->capability.tmCapable;
  1792          }

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
(Continue reading)

Douglas Gilbert | 8 Feb 18:33 2016
Picon

T10 adds locally assigned UUID designation descriptor

Recently, in draft spc5r08, T10 added a locally assigned RFC 4122
UUID *** designation descriptor. That descriptor can now be
returned for VPD page 0x83 (device identification) amongst others.
It can be used anywhere SCSI needs a unique identifier expanding
the previous set of preferred identifiers: EUI, NAA and SCSI_name
(iSCSI).

In the soon to be released sg3_utils version 1.42 the new UUID
designation descriptor is decoded including Hannes' --export
option found in sg_inq, for example:

# sg_inq --export /dev/sg0
   ...
   SCSI_IDENT_LUN_UUID=11223344-5566-7788-aabb-ccddeeffffee

Perhaps some udev work is needed to incorporate this new identifier.

Doug Gilbert

** see  https://en.wikipedia.org/wiki/Universally_unique_identifier
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Suganath prabu Subramani | 8 Feb 17:43 2016

[mpt3sas driver V1 6/10] mpt3sas: Added smp_affinity_enable module parameter.

Module parameter to enable/disable configuring
affinity hint for msix vector.
SMP affinity feature can be enabled/disabled by setting
module parameter "smp_affinity_enable" to 1/0.
By default this feature is enabled. (smp_affinity_enable = 1 enabled).

Signed-off-by: Suganath prabu Subramani <suganath-prabu.subramani <at> avagotech.com>
Signed-off-by: Chaitra P B <chaitra.basappa <at> avagotech.com>
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 31838d9a..582ba4b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
 <at>  <at>  -83,6 +83,10  <at>  <at>  static int msix_disable = -1;
 module_param(msix_disable, int, 0);
 MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts (default=0)");

+static 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)");
+
 static int max_msix_vectors = -1;
 module_param(max_msix_vectors, int, 0);
 MODULE_PARM_DESC(max_msix_vectors,
 <at>  <at>  -1812,8 +1816,10  <at>  <at>  _base_free_irq(struct MPT3SAS_ADAPTER *ioc)

 	list_for_each_entry_safe(reply_q, next, &ioc->reply_queue_list, list) {
(Continue reading)

Hannes Reinecke | 8 Feb 15:34 2016
Picon

[PATCH 00/23] ALUA device handler update, part II

as promised here is now the second part of my ALUA device handler update.
This contains a major rework of the ALUA device handler as execution is
moved onto a workqueue. This has the advantage that we avoid having to
do multiple calls to the same LUN (as happens frequently when failing
over a LUN with several paths) and finally retries are handled correctly.
As some arrays are only capable of handling one STPG at a time I've added
a blacklist flag which then uses a singlethreaded workqueue, thereby
effectively synchronize STPG handling.
Thanks to Bart for this suggestion.

As usual, comments and reviews are welcome.

Changes to v4:
- use kfree_rcu() as suggested by hch
- Use 'IS_ERR' instead of 'PTR_ERR' when checking for validity
  of a pointer
- Simplify pg assignment as suggested by hch
- Use separate WARN_ON statements a suggested by hch
- Fixes to avoid I/O stall on failover

Changes to v3:
- Use scsi_device flag for blacklisting as suggested by hch
- Add Arrays for synchronous ALUA handling
- Move synchronize_rcu() into release_port_group()
- Add remaining reviewed tags

Changes to v2:
- Use a SCSI blacklist flag instead of a hardware handler parameter
  for switching to synchronous ALUA handling
- Move scsi_get_device_flags{,_keyed} to scsi_devinfo.h
(Continue reading)

Ms Ayala | 7 Feb 22:28 2016
Picon

Very Urgent,response needed.

Hi,

I am Ms. Ayala; I am getting in touch with you regarding an extremely
important and urgent matter.If you would oblige me the opportunity,I shall
provide you with details upon your response.Please respond to: msayalabrnaca101 <at> 163.com

Faithfully,
Ms. Ayala Bracha
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nicholas A. Bellinger | 7 Feb 04:17 2016

[PATCH-v4 0/5] Fix LUN_RESET active I/O + TMR handling

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

Hi folks,

Here is -v4 series to address the set of of LUN_RESET
active I/O + TMR se_cmd->cmd_kref < 0 bugs as reported
recently by Quinn & Co.  This can occur during active
I/O remote port TMR LUN_RESET with multi-port LIO
configurations.

To address this bug, we add a __target_check_io_state()
common handler for ABORT_TASK + LUN_RESET I/O abort
cases, and move the remaining se_cmd SGL page + release
into target_free_cmd_mem() to now be called directly
from final target_release_cmd_kref() callback.

It also adds a target_wait_free_cmd() helper and makes
transport_generic_free_cmd() aware of CMD_T_ABORTED
status during concurrent session disconnects, and
introduces CMD_T_FABRIC_STOP bit to signal this special
case.

Currently this series is running atop v4.5-rc1 + v3.14.y,
and with iscsi-target ports is able to survive active
I/O remote-port LUN resets, plus remote-port LUN_RESET
with concurrent simulated session disconnects.

At this point the changes are stable with iscsi-target
ports, and as Himanshu + Co can verify with tcm_qla2xxx
should be considered ready to merge for -rc4.
(Continue reading)

bugzilla-daemon | 6 Feb 02:20 2016

[Bug 71021] WARNING: CPU: 0 PID: 5517 at /build/buildd/linux-3.13.0/fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()

https://bugzilla.kernel.org/show_bug.cgi?id=71021

Yijing Wang <wangyijing <at> huawei.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wangyijing <at> huawei.com

--- Comment #4 from Yijing Wang <wangyijing <at> huawei.com> ---
I also found the same issue when remove my disk in my platform, I think the
code logic is incorrect, this call trace would appear every disk remove. I
found  Dan Williams posted a fix patch, but it was not merged to kernel.

https://www.mail-archive.com/linux-scsi <at> vger.kernel.org/msg39187.html

Following is my call trace:

WARNING: CPU: 2 PID: 6 at fs/sysfs/group.c:224 sysfs_remove_group+0x9c/0xa0()
sysfs group (power)ffff800000a2dbe8 not found for kobject '0:0:1:0'
Modules linked in:
CPU: 2 PID: 6 Comm: kworker/u64:0 Not tainted 4.1.6+ #157
Hardware name: Hisilicon PhosphorV660 Development Board (DT)
Workqueue: scsi_wq_0 sas_destruct_devices
Call trace:
[<ffff800000089918>] dump_backtrace+0x0/0x124
[<ffff800000089a4c>] show_stack+0x10/0x1c
[<ffff8000006ecd10>] dump_stack+0x78/0x98
[<ffff80000009fc38>] warn_slowpath_common+0x98/0xd0
[<ffff80000009fcbc>] warn_slowpath_fmt+0x4c/0x58
[<ffff8000001fc190>] sysfs_remove_group+0x98/0xa0
(Continue reading)

Interfax Online | 5 Feb 21:00 2016
Picon

You have received fax, document 000208651

A new fax document for you.

You can find your fax document in the attachment.

Resolution:       600 DPI
From:             Stanley Wallace
Filename:         task_000208651.doc
Scan time:        57 seconds
Date of scan:     Fri, 5 Feb 2016 04:48:30 +0300
Pages sent:       4
Filesize:         206 Kb

Thank you for using Interfax!

Attachment (task_000208651.zip): application/zip, 2239 bytes
bugzilla-daemon | 5 Feb 18:01 2016

[Bug 71021] WARNING: CPU: 0 PID: 5517 at /build/buildd/linux-3.13.0/fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()

https://bugzilla.kernel.org/show_bug.cgi?id=71021

--- Comment #3 from Dāvis <davispuh <at> gmail.com> ---
This still happens with 4.4.0
When removing disk

kernel: /mnt/Linux/linux/drivers/scsi/mvsas/mv_sas.c 1913:phy3 Removed Device
kernel: ------------[ cut here ]------------
kernel: WARNING: CPU: 3 PID: 16820 at /mnt/Linux/linux/fs/sysfs/group.c:237
sysfs_remove_group+0x8b/0x90()
kernel: sysfs group ffffffff818a3b60 not found for kobject 'end_device-7:7'
kernel: Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast
xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4
xt_conntrack ip_set nfnetlink ebtable_bro
kernel:  snd_usbmidi_lib videobuf2_v4l2 snd_rawmidi snd_seq_device mousedev
gf128mul input_leds joydev led_class glue_helper snd_hda_codec_hdmi
snd_hda_codec_realtek videobuf2_core r8169 v4l2_commo
kernel:  libsas libahci scsi_transport_sas syscopyarea sysfillrect sysimgblt
fb_sys_fops drm libata usbcore usb_common scsi_mod i2c_core wmi i8042 serio
button ip_tables x_tables [last unloaded: dr
kernel: CPU: 3 PID: 16820 Comm: kworker/u16:8 Tainted: P        W  O   
4.4.0-ARCH-dirty #1
kernel: Hardware name: Gigabyte Technology Co., Ltd.
GA-990FXA-UD3/GA-990FXA-UD3, BIOS FFe 11/08/2013
kernel: Workqueue: scsi_wq_7 sas_destruct_devices [libsas]
kernel:  0000000000000000 00000000ad666a1d ffff8801d3103c50 ffffffff812bf949
kernel:  ffff8801d3103c98 ffff8801d3103c88 ffffffff810764f2 0000000000000000
kernel:  ffffffff818a3b60 ffff88021cb30410 ffff8800cd642828 ffff8800cd6427f8
kernel: Call Trace:
kernel:  [<ffffffff812bf949>] dump_stack+0x4b/0x72
(Continue reading)

wangyijing | 5 Feb 10:20 2016

Question for Patch"libsas: fix "sysfs group not found" warnings at port teardown time"

Hi Dan and Praveen,
   I found a patch titled "libsas: fix "sysfs group not found" warnings at port teardown time" by google,
https://www.mail-archive.com/linux-scsi <at> vger.kernel.org/msg39187.html

I found the same warning calltrace in my platform, but I didn't find the patch changes in the latest kernel 4.5-rc2.
So is this issue still in kernel ?

I think your patch could fix this issue we found, but I'm worried about another problem.

Now when unplug a disk

LLDD report a event loss_of_singal
    sas_deform_port
	sas_unregister_domain_devices
		sas_unregister_dev
			sas_discover_event(dev->port, DISCE_DESTRUCT);
	sas_port_delete
	phy->port = NULL;

and after your patch changes

LLDD report a event loss_of_singal
	sas_deform_port
		sas_unregister_domain_devices
			sas_unregister_dev
				sas_discover_event(dev->port, DISCE_DESTRUCT);
	phy->port = NULL;

...
	sas_destruct_devices
(Continue reading)

wangyijing | 5 Feb 08:05 2016

Warning Calltrace when hotplug sas disk

Hi list, I tried to hotplug disk in my machine, but when I hot remove the disk, I found some warning calltrace.

When we try to unplug a disk,

The lldd report a loss_of_singal event to sas, so

sas_deform_port
	sas_unregister_domain_devices
		sas_unregister_dev
			queue the destruct to scsi work queue
	sas_port_delete
		device_del(port)  //port device is parent of phy and end device, so in this case, we first delete the
parent kobj then to delete the children device.
..
sas_destruct_devices
	sas_rphy_delete
		...

It seems caused by delete the parent device before the children devices. This is my personal idea, if anyone
could comment on this, I will be appreciate very much, thanks.

WARNING: CPU: 2 PID: 6 at fs/sysfs/group.c:224 sysfs_remove_group+0xa0/0xa4()
kobj ffff8013e8389410 sysfs group (power)ffff800000a2dbe8 not found for kobject '0:0:1:0'
Modules linked in:
CPU: 2 PID: 6 Comm: kworker/u64:0 Not tainted 4.1.6+ #160
Hardware name: Hisilicon PhosphorV660 Development Board (DT)
Workqueue: scsi_wq_0 sas_destruct_devices
Call trace:
[<ffff800000089918>] dump_backtrace+0x0/0x124
[<ffff800000089a4c>] show_stack+0x10/0x1c
(Continue reading)


Gmane