RE: [RFC-v3.10.y 5/8] iser-target: Parallelize CM connection establishment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 1/23/2015 1:20 AM, Chris Moore wrote:
> <SNIP>
> >>>> Mmmm, good point.
> >>>>
> >>>> Your call if patch #5 + #6 should be dropped here..
> >>>>
> >>>
> >>> These would be the first candidates to drop if I see a noticeable
> >>> regression.
> >>>
> >>
> >> <nod>
> >>
> >>> Just wandering, if we get RH to get the target stack (or at least
> >>> the iscsit + isert) stacks to kernel 3.19, is this really necessary?
> >>>
> >>
> >> If it's a just multi-login performance improvement, vs. a functional
> >> correctness change, then probably not.
> >>
> >
> > Speaking of RH - RHEL 7.1 doesn't handle cable pulls and lost
> > connections very well.  I was just trying to figure out what to do about that,
> since the fixes are in 3.19, when Nic's 3.10 patches
> > showed up on the list.   At first glance it looks like these patches will fix the
> issues, but I
> > haven't tried them yet.  If they do, it would be great if we can get RH to pick
> these up in RHEL 7.1.
> >
> 
> So I am trying to get this pile tested, but I can't even boot the kernel in a VM
> due to an early panic (see stack trace below). This happens even before I
> applied any of the isert patches.
> 
> Unfortunately I'm short on physical stations to test this stuff.
> 
> Chris, Are you also on this?
> 
> CC'ing G-KH
> 
> Sagi.
> 
> Trace:
> tlb_flushall_shift: 5
> 
> Freeing SMP alternatives: 20k freed
> 
> ACPI: Core revision 20130328
> 
> ACPI: All ACPI Tables successfully acquired
> 
> ftrace: allocating 21972 entries in 86 pages
> 
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> smpboot: CPU0: Intel Xeon E312xx (Sandy Bridge) (fam: 06, model: 2a,
> stepping: 01)
> Performance Events:
> general protection fault: 0000 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.65+ #1 Hardware name:
> Red Hat KVM, BIOS 0.5.1 01/01/2007
> task: ffff88003e20f500 ti: ffff88003e220000 task.ti: ffff88003e220000
> RIP: 0010:[<ffffffff81b13f97>]  [<ffffffff81b13f97>]
> intel_pmu_init+0x2fc/0x7f9
> RSP: 0000:ffff88003e221e38  EFLAGS: 00000202
> RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000345
> RDX: 0000000000000003 RSI: 0000000000000730 RDI: 0000ffffffffffff
> RBP: ffff88003e221e48 R08: 0000000000000000 R09: 0000000000000007
> R10: 0000000000000002 R11: ffffffff81ae19e0 R12: ffffffff81b1326c
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffff88003fc00000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffff880001eaa000 CR3: 0000000001a0b000 CR4: 00000000000406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Stack:
>   0000000000000000 0000000000000000 ffff88003e221e68 ffffffff81b1329a
>   0000000000000000 ffffffff81b1326c ffff88003e221e98 ffffffff810002c2
>   ffffffff81c9f380 0000000000000000 0000000000000000 0000000000000000 Call
> Trace:
>   [<ffffffff81b1329a>] init_hw_perf_events+0x2e/0x2e9
>   [<ffffffff81b1326c>] ? merge_attr+0x8e/0x8e
>   [<ffffffff810002c2>] do_one_initcall+0xf2/0x1a0
>   [<ffffffff81b0bad8>] kernel_init_freeable+0x1dc/0x279
>   [<ffffffff815216c0>] ? rest_init+0x80/0x80
>   [<ffffffff815216ce>] kernel_init+0xe/0xf0
>   [<ffffffff8153ef5c>] ret_from_fork+0x7c/0xb0
>   [<ffffffff815216c0>] ? rest_init+0x80/0x80
> Code: da fc ff 44 89 0d f2 da fc ff 89 0d a4 db fc ff 7e 2b 83 e2 1f b8
> 03 00 00 00 b9 45 03 00 00 83 fa 02 0f 4f c2 89 05 b9 da fc ff <0f> 32
> 48 c1 e2 20 89 c0 48 09 c2 48 89 15 4f db fc ff e8 92 2c RIP  [<ffffffff81b13f97>]
> intel_pmu_init+0x2fc/0x7f9
>   RSP <ffff88003e221e38>
> ---[ end trace d29acbcb340d0b00 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

I haven't tried testing these against the latest 3.10.  I tried applying them to the RHEL 7.1 Snap3
kernel but they wouldn't apply cleanly - too many other changes to 3.10 haven't been picked
up yet by RH.

I applied all the changes by hand to RHEL 7.1 and had no problems with booting, but
the first time I try to login from the initiator I get a hang on the target.  

I need to build a 3.10 system anyway to try to figure out what it's going to take to make RHEL 7.1
work, so I can probably pull 3.10.65, apply the batch, and see how it does.  I'll let you know
what I find out.

Chris

��.n��������+%������w��{.n����j�����{ay�ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��





[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux