[ofa-general] using SDP for block device traffic: several problems
Amir Vadai
amirv at mellanox.co.il
Thu Jul 9 09:28:26 PDT 2009
Lars Hi,
I'v found the bug.
a fix patch is attached.
I will commit it after the weekend (In Israel weekend is Friday-Saturday).
- Amir
On 07/08/2009 01:17 PM, Lars Ellenberg wrote:
> On Wed, Jul 08, 2009 at 11:12:15AM +0300, Amir Vadai wrote:
>
>> Lars Hi,
>>
>> I opened a bug in our bugzilla (https://bugs.openfabrics.org/show_bug.cgi?id=1672).
>>
>> I couldn't reproduce it on my setup: SLES 10SP2, stock kernel, same ofed git version.
>> will try now to install 2.6.27 kernel and check again.
>>
> With a "normal" kernel config, I needed to do full load bi-directional
> network traffic on IPoIB as well as SDP, multiple stream sockets,
> to eventually actually trigger it after a few minutes
> (several hundered MegaByte per second).
>
> with the "debug" kernel config,
> I was able to reproduce with only one socket,
> within milliseconds.
>
> my .config is attached.
>
>
>> BTW, what type of servers do you use? Are they low/high end server?
>>
> This is the second cluster that show this bug. I first experienced it
> when using SDP sockets from within kernel space.
> I was able to reproduce in userland,
> which I thought might make it easier for you to reproduce.
>
> The current test cluster is a slightly aged 2U supermicro dual quadcore,
> 4GB ram, and proved to be very reliable hardware in all test up to now.
> it may be a little slow on interrupts.
>
> tail of /proc/cpuinfo:
> processor : 7
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
> stepping : 7
> cpu MHz : 1599.984
> cache size : 4096 KB
> physical id : 1
> siblings : 4
> core id : 3
> cpu cores : 4
> apicid : 7
> initial apicid : 7
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl pni
> monitor ds_cpl vmx tm2 ssse3 cx16 xtpr dca lahf_lm
> bogomips : 3201.35
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> the IB setup is direct link, lspci says:
> 09:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX IB QDR, PCIe 2.0 5GT/s] (rev a0)
>
>
> because using IPoIB does work just fine, I don't think we have issues
> with IB setup, or the hardware in general.
> only when using SDP it is broken, "forgets" bytes, or corrupts data.
>
> what I do "different" than the (assumed to be) typical SDP user is:
> sending large-ish messages at once (up to ~32 kB), possibly unaligned.
>
> which apparently is a mode that SDP has not excercised much yet,
> otherwise the recently fixed page leak would have been noticed by
> someone much earlier.
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data_integrity_bug.patch
Type: text/x-patch
Size: 563 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090709/c9a2e835/attachment.bin>
More information about the general
mailing list