Hi, Hannes:
On 07/12/2013 06:27 PM, Hannes Reinecke wrote:
On 07/12/2013 12:00 PM, Ren Mingxin wrote:
On 07/12/2013 02:09 PM, Hannes Reinecke wrote:
On 07/12/2013 06:14 AM, Ren Mingxin wrote:
On 07/01/2013 10:24 PM, Hannes Reinecke wrote:
With the original SCSI EH I got:
# time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 142.652 s, 118 kB/s
real 2m22.657s
user 0m0.013s
sys 0m0.145s
With this patchset I got:
# time dd if=/dev/zero of=/dev/dm-2 bs=4k count=4k oflag=direct
4096+0 records in
4096+0 records out
16777216 bytes (17 MB) copied, 52.1579 s, 322 kB/s
real 0m52.163s
user 0m0.012s
sys 0m0.145s
Test was to disable RSCN on the target port, disable the
target port, and then start the 'dd' command as indicated.
Do you mean disabling RSCN/port is enough? I'm afraid I couldn't
reproduce the problem by your steps. Both with and without your
patchset are the same 'dd' result: 27s. Please let me know where I
neglected or mistook:
1) I made a dm-multipath target 'dm-0' whose grouping policy was
failover;
2) Disable RSCN/port via brocade fc switch:
SW300:root> portcfg rscnsupr 15 --enable; portDisable 15
3) Start the 'dd' command:
# time dd if=/dev/zero of=/dev/dm-0 bs=4k count=4k oflag=direct
dd: writing `/dev/sde': Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 27.8588 s, 0.0 kB/s
real 0m27.860s
user 0m0.001s
sys 0m0.000s
You are aware that you have to disable RSCNs on the _target_ port,
right?
Disabling RSCNs on the _initiator_ ports is a well-tested case, and
the one which actually makes sense (and is even implemented in
QLogic switches).
Disabling RSCNs for the _target_ port, OTOH, has a very questionable
nature (hence QLogic switches don't even allow you to do this).
You're right. By disabling RSCNs on target port, I've reproduced this
problem. Thank you so much. But I've encountered the bug I said
before. I'll test again with your new patchset once you send.
Could you check with the attached patch? That should convert it to
delayed_work and avoid this issue.
Unfortunately, the login prompt couldn't be entered in and BUGs were
printed ceaselessly while os booting with this patch. The BUGs are
like below:
BUG: scheduling while atomic: swapper/0/0/0x10000100
Modules linked in: mptsas(F+) mptscsih(F) mptbase(F) scsi_transport_sas(F)
CPU: 0 PID: 0 Comm: swapper/0 Tainted: GF 3.10.0hannes+ #10
Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB-8GDIMM-CN, BIOS PRIMEQUEST
1000 Series BIOS Version 1.39 11/16/2012
0000000000000000 ffff88047ee03b68 ffffffff8153ada4 ffff88047ee03b78
ffffffff8107389d ffff88047ee03c08 ffffffff8153ca26 ffffffff81a01fd8
0000000000012d00 ffffffff81a00010 0000000000012d00 0000000000012d00
Call Trace:
<IRQ> [<ffffffff8153ada4>] dump_stack+0x19/0x1d
[<ffffffff8107389d>] __schedule_bug+0x4d/0x60
[<ffffffff8153ca26>] __schedule+0x646/0x6f0
[<ffffffff8107749a>] __cond_resched+0x2a/0x40
[<ffffffff8153cb60>] _cond_resched+0x30/0x40
[<ffffffff8105fecc>] start_flush_work+0x2c/0x140
[<ffffffff8105fffa>] flush_work+0x1a/0x40
[<ffffffff8105fb39>] ? try_to_grab_pending+0x109/0x190
[<ffffffff8106027e>] __cancel_work_timer+0x7e/0x110
[<ffffffff81060323>] cancel_delayed_work_sync+0x13/0x20
[<ffffffff81374ec5>] scsi_put_command+0x65/0xa0
[<ffffffff8137d5aa>] scsi_next_command+0x3a/0x60
[<ffffffff8137dedb>] scsi_end_request+0xab/0xb0
[<ffffffff8137e1ef>] scsi_io_completion+0x9f/0x670
[<ffffffff813744e4>] scsi_finish_command+0xd4/0x140
[<ffffffff8137e927>] scsi_softirq_done+0x147/0x170
[<ffffffff81239534>] blk_done_softirq+0x74/0x90
[<ffffffff81049a4f>] __do_softirq+0xef/0x260
[<ffffffff81049cb5>] irq_exit+0xb5/0xc0
[<ffffffff81548406>] do_IRQ+0x66/0xe0
[<ffffffff8153e5ea>] common_interrupt+0x6a/0x6a
<EOI> [<ffffffff8109b5f2>] ? clockevents_notify+0x52/0x150
[<ffffffff8142dce3>] ? cpuidle_enter_state+0x53/0xd0
[<ffffffff8142dcdf>] ? cpuidle_enter_state+0x4f/0xd0
[<ffffffff8142e10f>] cpuidle_idle_call+0xcf/0x160
[<ffffffff8100ab1e>] arch_cpu_idle+0xe/0x30
[<ffffffff81093275>] cpu_idle_loop+0x65/0x1f0
[<ffffffff81093470>] cpu_startup_entry+0x70/0x80
[<ffffffff81529427>] rest_init+0x77/0x80
[<ffffffff81b0e1bb>] start_kernel+0x41a/0x427
[<ffffffff81b0dbbf>] ? repair_env_string+0x5b/0x5b
[<ffffffff81b0d5a1>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81b0d6d2>] x86_64_start_kernel+0x12f/0x136
If there is any info I havn't expatiated, please let me know.
Thanks,
Ren
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
