Re: [PATCH 00/20] smartpqi updates
Hi Brace, In this patch series, do you have fixed and verified the timeout issue? https://patchwork.kernel.org/patch/10637797/ Thanks, - Alex Don Brace 于2018年12月8日周六 上午6:28写道： > > These patches are based on Linus's tree > > The changes are: > > - smartpqi-add-support-for-PQI-Config-Table-handshake > . add support for get/set controller features. > - smartpqi-add-retries-for-device-resets > . re-attempt device reset. > - smartpqi-add-no_write_same-for-logical-volumes > . turn off WRITE SAME for logical volumes. > - smartpqi-correct-host-serial-num-for-ssa > . update host serial number > - smartpqi-turn-off-lun-data-caching-for-ptraid > . get fresh lun list from RBODS. > - smartpqi-refactor-sending-controller-raid-requests > . condense commonly used code. > - smartpqi-add-sysfs-attributes > . add in driver attributes. > - smartpqi-add-h3c-ssid > . add support for more controllers. > - smartpqi-fix-disk-name-mount-point > . correct sysfs attribute for unique ids. > - smartpqi-wake-up-drives-after-os-resumes-from-suspend > . have OS start up disks after resume. > - smartpqi-enhance-numa-node-detection > . set pci device to correct NUMA node. > - smartpqi-add-support-for-huawei-controllers > . add support for more controllers. > - smartpqi-check-for-null-device-pointers > . wait for all outstanding I/O to complete before removing a volume > - smartpqi-allow-for-larger-raid-maps > . correct rare case for very large volume configurations. > - smartpqi-do-not-offline-disks-for-transient-did-no-connect-conditions > . remove call to scsi_device_set_state > - smartpqi-correct-volume-status > . correct rare case for volume deletion during a scan operation. > - smartpqi-correct-lun-reset-issues > . clear scsi cmd result after a reset. > - smartpqi-add-module-param-to-disable-irq-affinity > . allow some customers to change IRQ affinity. > - smartpqi-add-smp_utils-support > . add support for smp_utils. > - smartpqi-bump-driver-version > > --- > > Ajish Koshy (2): > smartpqi: add support for huawei controllers > smartpqi: allow for larger raid maps > > Dave Carroll (7): > smartpqi: add no_write_same for logical volumes > smartpqi: turn off lun data caching for ptraid > smartpqi: refactor sending controller raid requests > smartpqi: add sysfs attributes > smartpqi: wake up drives after os resumes from suspend > smartpqi: do not offline disks for transient did no connect conditions > smartpqi: correct volume status > > Don Brace (3): > smartpqi: add module param to disable irq affinity > smartpqi: add smp_utils support > smartpqi: bump driver version > > Kevin Barnett (2): > smartpqi: add support for PQI Config Table handshake > smartpqi: correct lun reset issues > > Mahesh Rajashekhara (3): > Add retries for device reset > smartpqi: correct host serial num for ssa > smartpqi: check for null device pointers > > Murthy Bhat (2): > smartpqi: add h3c ssid > smartpqi: fix disk name mount point > > Sagar Biradar (1): > smartpqi: enhance numa node detection > > > drivers/scsi/smartpqi/smartpqi.h | 144 +++ > drivers/scsi/smartpqi/smartpqi_init.c | 992 > > drivers/scsi/smartpqi/smartpqi_sas_transport.c | 164 > 3 files changed, 1131 insertions(+), 169 deletions(-) > > -- > Signature -- Thanks and Best Regards, Feng Li(Alex)
Re: [Qemu-devel] virtio-console downgrade the virtio-pci-blk performance
Add Amit Shah.
After some tests, we found:
- the virtio serial port number is inversely proportional to the iSCSI
virtio-blk-pci performance.
If we set the virio-serial ports to 2("), the performance downgrade
is minimal.
- use local disk/ram disk as virtio-blk-pci disk, the performance
downgrade is still obvious.
Could anyone give some help about this issue?
Feng Li 于2018年10月1日周一 下午10:58写道：
>
> Hi Dave,
> My comments are in-line.
>
> Dr. David Alan Gilbert 于2018年10月1日周一 下午7:41写道：
> >
> > * Feng Li (lifeng1...@gmail.com) wrote:
> > > Hi,
> > > I found an obvious performance downgrade when virtio-console combined
> > > with virtio-pci-blk.
> > >
> > > This phenomenon exists in nearly all Qemu versions and all Linux
> > > (CentOS7, Fedora 28, Ubuntu 18.04) distros.
> > >
> > > This is a disk cmd:
> > > -drive
> > > file=iscsi://127.0.0.1:3260/iqn.2016-02.com.test:system:fl-iscsi/1,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
> > > -device
> > > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
> > >
> > > If I add "-device
> > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 ", the virtio
> > > disk 4k iops (randread/randwrite) would downgrade from 60k to 40k.
> > >
> > > In VM, if I rmmod virtio-console, the performance will back to normal.
> > >
> > > Any idea about this issue?
> > >
> > > I don't know this is a qemu issue or kernel issue.
> >
> > It sounds odd; can you provide more details on:
> > a) The benchmark you're using.
> I'm using fio, the config is:
> [global]
> ioengine=libaio
> iodepth=128
> runtime=120
> time_based
> direct=1
>
> [randread]
> stonewall
> bs=4k
> filename=/dev/vdb
> rw=randread
>
> > b) the host and the guest config (number of cpus etc)
> The qemu cmd is : /usr/libexec/qemu-kvm --device virtio-balloon -m 16G
> --enable-kvm -cpu host -smp 8
> or qemu-system-x86_64 --device virtio-balloon -m 16G --enable-kvm -cpu
> host -smp 8
>
> The result is the same.
>
> > c) Why are you running it with iscsi back to the same host - why not
> > just simplify the test back to a simple file?
> >
>
> Because my ISCSI target could supply a high IOPS performance.
> If using a slow disk, the performance downgrade would be not so obvious.
> It's easy to be seen, you could try it.
>
>
> > Dave
> >
> > >
> > > Thanks in advance.
> > > --
> > > Thanks and Best Regards,
> > > Alex
> > >
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
>
>
> --
> Thanks and Best Regards,
> Feng Li(Alex)
--
Thanks and Best Regards,
Feng Li(Alex)
Re: [PATCH] iscsi-target: fix panic when add the second TCP connection to iSCSI session
Hi Sumit, I have tested and the oops is disappeared. Could you double check if you have patched successfully? This stack is still the same. The place is 0x01f8. gdb> p (int)&((struct iscsi_session*)0)->se_sess $3 = 0x1f8 2016-07-14 17:59 GMT+08:00 Sumit Rai <sumit@calsoftinc.com>: > Thanks for the patch Feng, I have tested this patch and below panic has also > disappeared. > (initially reported at > http://article.gmane.org/gmane.linux.scsi.target.devel/12735). > > dmesg > = > [ 862.784477] BUG: unable to handle kernel NULL pointer dereference at > 01f8 > [ 862.784486] IP: [] iscsi_target_login_thread+0x724/0xfa0 > [iscsi_target_mod] > [ 862.784570] PGD 0 > [ 862.784572] Oops: [#1] SMP > [ 862.784575] Modules linked in: target_core_user uio tcm_fc libfc ib_srpt > tcm_usb_gadget > libcomposite udc_core tcm_loop vhost_scsi vhost iscsi_target_mod tcm_qla2xxx > qla2xxx > scsi_transport_fc target_core_file target_core_iblock target_core_pscsi > target_core_mod > configfs pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) > vmw_vsock_vmci_transport vsock vmhgfs(OE) coretemp kvm_intel kvm binfmt_misc > irqbypass > crct10dif_pclmul crc32_pclmul aesni_intel vmw_balloon aes_x86_64 lrw gf128mul > glue_helper > ablk_helper cryptd joydev input_leds serio_raw i2c_piix4 vmw_vmci shpchp > 8250_fintek mac_hid > ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp > libiscsi_tcp libiscsi > scsi_transport_iscsi parport_pc ppdev lp parport autofs4 hid_generic usbhid > hid vmwgfx ttm psmouse > drm_kms_helper syscopyarea > [ 862.784609] sysfillrect sysimgblt mptspi mptscsih fb_sys_fops drm ahci > libahci e1000 mptbase > scsi_transport_spi pata_acpi floppy fjes > [ 862.784618] CPU: 0 PID: 9241 Comm: iscsi_np Tainted: G OE > 4.4.0-24-generic #43-Ubuntu > [ 862.784620] Hardware name: VMware, Inc. VMware Virtual Platform/440BX > Desktop Reference Platform, > BIOS 6.00 05/20/2014 > [ 862.784622] task: 8800759d1b80 ti: 880075a0 task.ti: > 880075a0 > [ 862.784624] RIP: 0010:[] [] > iscsi_target_login_thread+0x724/0xfa0 [iscsi_target_mod] > [ 862.784632] RSP: 0018:880075a03e40 EFLAGS: 00010246 > [ 862.784633] RAX: RBX: 880075a52800 RCX: > 00037726 > [ 862.784635] RDX: 00037725 RSI: 88007b619fe0 RDI: > 880033bce800 > [ 862.784636] RBP: 880075a03ec0 R08: 00019fe0 R09: > c06067c6 > [ 862.784637] R10: ea0001d1d880 R11: 654d687475410032 R12: > 880074763140 > [ 862.784638] R13: 880075a52820 R14: 880075a528d8 R15: > 880033bce800 > [ 862.784640] FS: () GS:88007b60() > knlGS: > [ 862.784641] CS: 0010 DS: ES: CR0: 8005003b > [ 862.784642] CR2: 01f8 CR3: 72f8e000 CR4: > 000406f0 > [ 862.784716] Stack: > [ 862.784719] 880075e87080 88003526f358 8800799cc420 > 8800 > [ 862.784721] 880079cd0100 880075a52828 00ff88003526ee00 > 880075a528d8 > [ 862.784723] 8800759d1b80 880075a52800 58f0fa77 > 880075a0aac0 > [ 862.784725] Call Trace: > [ 862.784736] [] ? > iscsi_target_login_sess_out+0x240/0x240 [iscsi_target_mod] > [ 862.784782] [] kthread+0xd8/0xf0 > [ 862.784786] [] ? kthread_create_on_node+0x1e0/0x1e0 > [ 862.784789] [] ret_from_fork+0x3f/0x70 > [ 862.784791] [] ? kthread_create_on_node+0x1e0/0x1e0 > [ 862.784792] Code: 00 00 4c 89 e2 4c 89 fe 48 89 df e8 c7 19 00 00 85 c0 0f > 88 32 01 00 00 0f b6 45 b7 4c 89 ff 41 88 44 24 09 > 49 8b 87 48 05 00 00 <4c> 8b b0 f8 01 00 00 49 8b 87 10 05 00 00 ff 90 98 00 > 00 00 41 > [ 862.784811] RIP [] > iscsi_target_login_thread+0x724/0xfa0 [iscsi_target_mod] > [ 862.784819] RSP > [ 862.784820] CR2: 01f8 > [ 862.784823] ---[ end trace 7e41630f165c8027 ]--- > > Regards, > Sumit Rai >> On Jul 12, 2016, at 8:46 AM, Feng Li <lifeng1...@gmail.com> wrote: >> >> Add ls...@suse.com >> >> 2016-07-11 22:23 GMT+08:00 冯力 <lifeng1...@gmail.com>: >>> This problem exists at least from v3.16. >>> The upstream kernel still exists this issue. >>> >>> I have tested my patch and the following panic is disappeared. >>> >>> Thanks, >>> - Alex >>> >>> #dmesg >>> >>> [ 1160.788676] sd 16:0:0:0: [sde] Attached SCSI disk >>> [ 1383.962626] target_core_get_fabric() failed for usb_gadget >>> [ 1404.788910] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x1b, >>> sending CHECK_CONDI
Re: [PATCH] iscsi-target: fix panic when add the second TCP connection to iSCSI session
Add ls...@suse.com 2016-07-11 22:23 GMT+08:00 冯力 <lifeng1...@gmail.com>: > This problem exists at least from v3.16. > The upstream kernel still exists this issue. > > I have tested my patch and the following panic is disappeared. > > Thanks, > - Alex > > #dmesg > > [ 1160.788676] sd 16:0:0:0: [sde] Attached SCSI disk > [ 1383.962626] target_core_get_fabric() failed for usb_gadget > [ 1404.788910] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x1b, > sending CHECK_CONDITION. > [ 1404.858451] BUG: unable to handle kernel NULL pointer dereference > at 01f8 > [ 1404.858911] IP: [] > iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod] > [ 1404.859746] PGD 230c29067 PUD 232060067 PMD 0 > [ 1404.859963] Oops: [#1] SMP > [ 1404.860154] Modules linked in: crc32c_generic tcm_loop tcm_qla2xxx > qla2xxx iscsi_target_mod ib_srpt vhost_scsi vhost tcm_fc libfc > scsi_transport_fc scsi_tgt target_core_file target_core_iblock > target_core_pscsi target_core_mod configfs nbd > vmw_vsock_vmci_transport vsock bridge stp llc vmhgfs(O) snd_ens1371 > snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd > vmw_balloon evdev soundcore ac97_bus gameport ppdev pcspkr sg psmouse > serio_raw parport_pc vmwgfx parport battery ttm drm_kms_helper drm > i2c_piix4 shpchp i2c_core vmw_vmci processor thermal_sys ac button > binfmt_misc md_mod ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core > ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi > hid_generic usbhid hid ext4 crc16 mbcache jbd2 sd_mod crc_t10dif > crct10dif_generic crct10dif_common ata_generic > [ 1404.861278] mptspi scsi_transport_spi mptscsih ata_piix uhci_hcd > ehci_pci ehci_hcd mptbase libata usbcore e1000 usb_common scsi_mod > sunrpc dm_mirror dm_region_hash dm_log dm_mod autofs4 > [ 1404.861742] CPU: 2 PID: 1865 Comm: iscsi_np Tainted: G O > 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-1 > [ 1404.861868] Hardware name: VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 > [ 1404.862033] task: 880234c849a0 ti: 8800b9c2 task.ti: > 8800b9c2 > [ 1404.862114] RIP: 0010:[] [] > iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod] > [ 1404.862233] RSP: 0018:8800b9c23e60 EFLAGS: 00010246 > [ 1404.862282] RAX: RBX: 88023125b800 RCX: > 8802b4d8d000 > [ 1404.862344] RDX: 002d RSI: fe01 RDI: > 880233ef1800 > [ 1404.862406] RBP: 8800b9651a00 R08: d5a073de R09: > 88023487e6c0 > [ 1404.862585] R10: ead0c2e5 R11: d039ef6a R12: > 88023125b854 > [ 1404.865580] R13: 88023125b908 R14: 880233ef1800 R15: > 880234c849a0 > [ 1404.867732] FS: 7fba67e2fb80() GS:88023e64() > knlGS: > [ 1404.869772] CS: 0010 DS: ES: CR0: 8005003b > [ 1404.871850] CR2: 01f8 CR3: 000230ffa000 CR4: > 07e0 > [ 1404.874271] Stack: > [ 1404.877492] 88023125b908 00ff880234c849a0 88023125b858 > 88023481f400 > [ 1404.880162] 81510d00 880230768000 8800b9c23fd8 > 00012f00 > [ 1404.883545] 880234c849a0 880233e9da40 88023125b800 > a05edeb0 > [ 1404.885865] Call Trace: > [ 1404.888384] [] ? __schedule+0x250/0x700 > [ 1404.890619] [] ? > iscsi_target_login_sess_out+0x240/0x240 [iscsi_target_mod] > [ 1404.892668] [] ? kthread+0xbd/0xe0 > [ 1404.894646] [] ? kthread_create_on_node+0x180/0x180 > [ 1404.896553] [] ? ret_from_fork+0x58/0x90 > [ 1404.898556] [] ? kthread_create_on_node+0x180/0x180 > [ 1404.900597] Code: 09 00 00 48 89 ea 4c 89 f6 48 89 df e8 52 1b 00 > 00 85 c0 0f 88 82 02 00 00 0f b6 44 24 0f 4c 89 f7 88 45 09 49 8b 86 > d8 04 00 00 <4c> 8b a8 f8 01 00 00 49 8b 86 a0 04 00 00 ff 90 98 00 00 > 00 41 > [ 1404.906962] RIP [] > iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod] > [ 1404.908962] RSP > [ 1404.910940] CR2: 01f8 > [ 1404.917670] ---[ end trace d29d8c681ab2bdfb ]--- > [ 1419.859690] iSCSI Login timeout on Network Portal 10.182.70.69:3260 > [ 1479.832056] iSCSI Login timeout on Network Portal 10.182.70.68:3260 > [ 1479.835739] iSCSI Login negotiation failed. > [ 1549.332632] iSCSI Login timeout on Network Portal 10.182.70.68:3260 > [ 1549.338432] iSCSI Login negotiation failed. > [ 1564.358423] iSCSI Login timeout on Network Portal 10.182.70.68:3260 > [ 1564.362443] iSCSI Login negotiation failed. > > 2016-07-12 6:15 GMT+08:00 Feng Li <li.f...@oracle.com>: >> From: Feng Li <lifeng1...@gmail.com> >> >> In MC/S scenario, the conn->sess has been set NULL in >> iscsi_login_non_zero_tsih_s1 when the se
[PATCH] iscsi-target: fix panic when add the second TCP connection to iSCSI session
From: Feng Li <lifeng1...@gmail.com>
In MC/S scenario, the conn->sess has been set NULL in
iscsi_login_non_zero_tsih_s1 when the second connection comes here,
then kernel panic.
The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
we should check whether it's NULL before calling.
Signed-off-by: Feng Li <lifeng1...@gmail.com>
---
drivers/target/iscsi/iscsi_target_login.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_login.c
b/drivers/target/iscsi/iscsi_target_login.c
index b5212f0..adf419f 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -1371,8 +1371,9 @@ static int __iscsi_target_login_thread(struct iscsi_np
*np)
}
login->zero_tsih = zero_tsih;
- conn->sess->se_sess->sup_prot_ops =
- conn->conn_transport->iscsit_get_sup_prot_ops(conn);
+ if (conn->sess)
+ conn->sess->se_sess->sup_prot_ops =
+ conn->conn_transport->iscsit_get_sup_prot_ops(conn);
tpg = conn->tpg;
if (!tpg) {
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
