From: Brian King <brking@linux.vnet.ibm.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
James.Bottomley@suse.de, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 3/3] tcm ibmvscsis driver
Date: Tue, 22 Mar 2011 07:53:08 -0500 [thread overview]
Message-ID: <4D889BB4.4010102@linux.vnet.ibm.com> (raw)
In-Reply-To: <1300747720.21880.95.camel@haakon2.linux-iscsi.org>
On 03/21/2011 05:48 PM, Nicholas A. Bellinger wrote:
> On Mon, 2011-03-21 at 17:31 -0500, Brian King wrote:
>> Just hit another potential issue. I was mapping / unmapping disks a couple times,
>> so that might have helped trigger the issue. I had a file backed disk mapped
>> to a vscsi lun, then unmapped it, mapped a ramdisk lun, then switched back to
>> the filebacked lun after running into issues with the ramdisk lun and saw this:
>>
>>
>
> By mapping/unmapping here do you mean unlinking+linking the Port/LUNs
> w/o removing the active VIO I_T Nexus, or actually rmdir'ing the whole
> $VIO_TARGET_FULLPATH/tpgt_1/ struct config_group..?
I just did an rm -r $VIO_TARGET_FULLPATH/tpgt_1/lun/lun_0
>
>> Mar 21 16:25:57 jn30a-lp4 kernel: unexpected fifo state
>> Mar 21 16:25:57 jn30a-lp4 kernel: ------------[ cut here ]------------
>> Mar 21 16:25:57 jn30a-lp4 kernel: WARNING: at drivers/scsi/libsrp.c:162
>> Mar 21 16:25:57 jn30a-lp4 kernel: Modules linked in: target_core_pscsi target_core_file target_core_iblock ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables ipv6 fuse loop dm_mod ibmvscsis libsrp scsi_tgt target_core_mod ses enclosure sg ibmveth configfs ext3 jbd mbcache sd_mod crc_t10dif ipr libata scsi_mod
>> Mar 21 16:25:57 jn30a-lp4 kernel: NIP: d0000000047e0b38 LR: d0000000047e0b34 CTR: 0000000000000000
>> Mar 21 16:25:57 jn30a-lp4 kernel: REGS: c00000033f4ef860 TRAP: 0700 Not tainted (2.6.38-0.7-ppc64-06439-g5bab188-dirty)
>> Mar 21 16:25:57 jn30a-lp4 kernel: MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24002024 XER: 20000001
>> Mar 21 16:25:57 jn30a-lp4 kernel: TASK = c00000033f2b39e0[58] 'kworker/4:1' THREAD: c00000033f4ec000 CPU: 4
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR00: d0000000047e0b34 c00000033f4efae0 d0000000047e9768 0000000000000018
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR04: 0000000000000000 0000000000000004 0000000000000000 c000000000f86610
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR08: c000000000f86b20 c0000000008b38b8 000000000007ffff 0000000000000001
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR12: 0000000028002082 c00000000f190a00 0000000000000000 0000000002b80610
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR16: 0000000001a3fc60 0000000002b80d08 0000000001a3fc70 0000000002c81870
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR20: 0000000002b805c8 0000000002c81888 0000000002c81910 0000000000000000
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR24: 0000000000000000 0000000000000000 0000000000000000 c00000033f1bacc0
>> Mar 21 16:25:57 jn30a-lp4 kernel: GPR28: 0000000000000001 0000000000000000 d0000000047e9778 d0000000047e1ba8
>> Mar 21 16:25:57 jn30a-lp4 kernel: NIP [d0000000047e0b38] .srp_iu_get+0x118/0x130 [libsrp]
>> Mar 21 16:25:57 jn30a-lp4 kernel: LR [d0000000047e0b34] .srp_iu_get+0x114/0x130 [libsrp]
>> Mar 21 16:25:57 jn30a-lp4 kernel: Call Trace:
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efae0] [d0000000047e0b34] .srp_iu_get+0x114/0x130 [libsrp] (unreliable)
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efb90] [d0000000048f0d6c] .process_crq+0xcc/0x5b8 [ibmvscsis]
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efc50] [d0000000048f183c] .handle_crq+0x224/0xa60 [ibmvscsis]
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efd60] [c0000000000c2120] .process_one_work+0x198/0x518
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efe10] [c0000000000c297c] .worker_thread+0x1f4/0x518
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4efed0] [c0000000000cb4c4] .kthread+0xb4/0xc0
>> Mar 21 16:25:57 jn30a-lp4 kernel: [c00000033f4eff90] [c00000000001e864] .kernel_thread+0x54/0x70
>> Mar 21 16:25:57 jn30a-lp4 kernel: Instruction dump:
>> Mar 21 16:25:57 jn30a-lp4 kernel: e8010010 eb41ffd0 7c0803a6 eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8
>> Mar 21 16:25:57 jn30a-lp4 kernel: 4e800020 e87e8058 48000739 e8410028 <0fe00000> 38000001 38600000 981f0000
>> Mar 21 16:25:57 jn30a-lp4 kernel: ---[ end trace ec6b6139d888a732 ]---
>> Mar 21 16:25:57 jn30a-lp4 kernel: Error getting IU from pool
>> Mar 21 16:25:57 jn30a-lp4 kernel: Error getting IU from pool
>> Mar 21 16:25:57 jn30a-lp4 kernel: Error getting IU from pool
>> Mar 21 16:25:57 jn30a-lp4 kernel: Error getting IU from pool
>>
>
> If we are talking about the latter case I think my last patch should
> address this with active I_T Nexus I/O and ibmvscsis_drop_tpg(), but I
> will followup a bit more and send out a proper patch this evening for
> Tomo to comment..
>
>> I'm also seeing disktest complain on the client about commands taking longer than 120 seconds
>> on occasion, which may play into the performance issue I mentioned in my previous mail.
>>
>
> Mmmm, please verify with RAMDISK_MCP backends as well, as by default
> FILEIO has O_SYNC enabled.. This does seem strange for LTP disktest
> however..
How do I specify RAMDISK_MCP? I don't see an option in tcm_node.
Thanks,
Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
next prev parent reply other threads:[~2011-03-22 12:53 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-10 12:21 [PATCH 0/3] ibmvscsis driver rewrite FUJITA Tomonori
2011-02-10 12:21 ` [PATCH 1/3] libsrp: add srp_data_length helper function FUJITA Tomonori
2011-02-10 12:21 ` [PATCH 2/3] libsrp: fix dma_unmap_sg FUJITA Tomonori
2011-02-10 12:21 ` [PATCH 3/3] tcm ibmvscsis driver FUJITA Tomonori
2011-02-10 19:03 ` Nicholas A. Bellinger
2011-02-14 1:36 ` FUJITA Tomonori
2011-02-14 3:26 ` FUJITA Tomonori
2011-02-14 9:01 ` Nicholas A. Bellinger
2011-02-14 9:29 ` FUJITA Tomonori
2011-02-14 9:27 ` Nicholas A. Bellinger
2011-02-14 9:46 ` FUJITA Tomonori
2011-02-14 9:51 ` Nicholas A. Bellinger
2011-02-10 19:15 ` Brian King
2011-02-10 19:38 ` Nicholas A. Bellinger
2011-02-11 21:13 ` Brian King
2011-02-12 20:27 ` James Bottomley
2011-03-07 4:41 ` FUJITA Tomonori
2011-03-07 6:17 ` Nicholas A. Bellinger
2011-03-07 6:24 ` FUJITA Tomonori
2011-03-07 6:55 ` Nicholas A. Bellinger
2011-03-07 14:40 ` James Bottomley
2011-03-18 16:57 ` James Bottomley
2011-03-18 20:58 ` Brian King
2011-03-18 22:09 ` Nicholas A. Bellinger
2011-03-19 14:32 ` James Bottomley
2011-03-21 1:09 ` FUJITA Tomonori
2011-03-21 12:56 ` Brian King
2011-03-21 21:01 ` Brian King
2011-03-21 21:01 ` Nicholas A. Bellinger
2011-03-21 21:24 ` Brian King
2011-03-21 22:29 ` Nicholas A. Bellinger
2011-03-21 23:20 ` FUJITA Tomonori
2011-03-21 23:50 ` Nicholas A. Bellinger
2011-03-21 23:55 ` FUJITA Tomonori
2011-03-22 0:26 ` Nicholas A. Bellinger
2011-03-22 0:32 ` FUJITA Tomonori
2011-03-22 2:28 ` Nicholas A. Bellinger
2011-03-22 3:26 ` FUJITA Tomonori
2011-03-21 21:05 ` James Bottomley
2011-03-21 22:37 ` Brian King
2011-03-21 22:22 ` Brian King
2011-03-21 22:31 ` Brian King
2011-03-21 22:48 ` Nicholas A. Bellinger
2011-03-22 12:53 ` Brian King [this message]
2011-03-22 22:06 ` Nicholas A. Bellinger
2011-03-22 22:49 ` FUJITA Tomonori
2011-03-23 1:35 ` Nicholas A. Bellinger
2011-03-23 5:12 ` FUJITA Tomonori
2011-03-23 8:26 ` Nicholas A. Bellinger
2011-03-23 8:48 ` FUJITA Tomonori
2011-03-23 10:00 ` Nicholas A. Bellinger
2011-03-23 12:04 ` FUJITA Tomonori
2011-03-23 21:17 ` Nicholas A. Bellinger
2011-03-24 1:54 ` FUJITA Tomonori
2011-03-24 7:29 ` Nicholas A. Bellinger
2011-03-23 15:19 ` Brian King
2011-03-23 20:34 ` Nicholas A. Bellinger
2011-03-25 14:33 ` Brian King
2011-03-25 20:13 ` Nicholas A. Bellinger
2011-03-21 22:34 ` Nicholas A. Bellinger
2011-03-21 23:06 ` FUJITA Tomonori
2011-03-21 23:13 ` Nicholas A. Bellinger
2011-03-21 23:22 ` FUJITA Tomonori
2011-03-22 0:03 ` Nicholas A. Bellinger
2011-03-21 23:30 ` FUJITA Tomonori
2011-02-14 1:42 ` FUJITA Tomonori
2011-02-14 1:42 ` FUJITA Tomonori
2011-02-14 7:16 ` Bart Van Assche
2011-02-14 9:11 ` FUJITA Tomonori
2011-02-14 9:18 ` Nicholas A. Bellinger
2011-02-14 9:19 ` Nicholas A. Bellinger
2011-02-14 9:31 ` FUJITA Tomonori
2011-02-14 9:29 ` Nicholas A. Bellinger
2011-02-14 11:50 ` Bart Van Assche
2011-02-15 3:42 ` FUJITA Tomonori
2011-02-15 19:20 ` Bart Van Assche
2011-02-15 23:21 ` FUJITA Tomonori
2011-02-10 18:34 ` [PATCH 0/3] ibmvscsis driver rewrite Nicholas A. Bellinger
2011-02-14 1:36 ` FUJITA Tomonori
2011-02-14 8:48 ` Nicholas A. Bellinger
[not found] ` <4D53DE96.2020502@suse.de>
[not found] ` <1297363312.18212.153.camel@haakon2.linux-iscsi.org>
2011-02-10 21:22 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D889BB4.4010102@linux.vnet.ibm.com \
--to=brking@linux.vnet.ibm.com \
--cc=James.Bottomley@suse.de \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.