Hello,
I'm trying to get SR-IOV working under Xen (4.2). It almost works except
memory bug. This is easily reproducible just in Dom0.
I have Connect-X3 card with the latest firmware. OFED 2.0-3 drivers. I tried
3.2 kernel from Debian, 3.10 kernel from Debian and vanila 3.11.5 kernel. All
are the
On 10/21/2013 7:57 AM, Lukas Hejtmanek wrote:
Hello,
I'm trying to get SR-IOV working under Xen (4.2). It almost works except
memory bug. This is easily reproducible just in Dom0.
I have Connect-X3 card with the latest firmware. OFED 2.0-3 drivers. I tried
3.2 kernel from Debian, 3.10 kernel f
>>> On 21.10.13 at 13:57, Lukas Hejtmanek wrote:
> I'm trying to get SR-IOV working under Xen (4.2). It almost works except
> memory bug. This is easily reproducible just in Dom0.
So without any SR-IOV then, I suppose?
> [23502.645455] mlx4_core :06:00.0: mlx4_ib: Port 1 logical link is up
>>> On 21.10.13 at 14:59, konrad wilk wrote:
> It is a bug in the drivers I believe. The issue is that the mapping
> created for the second mmap
> call is done without VM_IO and on an PFN that is RAM (and not the BAR).
So while putting together the reply that I had sent to Lukas a
minute ago I
On 10/21/2013 9:18 AM, Jan Beulich wrote:
On 21.10.13 at 14:59, konrad wilk wrote:
It is a bug in the drivers I believe. The issue is that the mapping
created for the second mmap
call is done without VM_IO and on an PFN that is RAM (and not the BAR).
So while putting together the reply that I
On 10/21/2013 9:39 AM, konrad wilk wrote:
On 10/21/2013 9:18 AM, Jan Beulich wrote:
On 21.10.13 at 14:59, konrad wilk wrote:
It is a bug in the drivers I believe. The issue is that the mapping
created for the second mmap
call is done without VM_IO and on an PFN that is RAM (and not the BAR).
On Mon, Oct 21, 2013 at 09:39:33AM -0400, konrad wilk wrote:
> Anyhow, one easy thing to figure out is to get the lspci -v output
> from the InfiniBand card
> to see where its BARs are, and also the start of the kernel. You
> should see an E820 map (please also boot with
> "debug" on the Linux comm
>>> On 21.10.13 at 16:06, Lukas Hejtmanek wrote:
> here is lspci from the card and its virtual functions.
>
> 06:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
> Subsystem: Mellanox Technologies Device 0017
> Control: I/O- Mem+ BusMaster+ SpecCycle- Mem
On Mon, Oct 21, 2013 at 04:06:07PM +0200, Lukas Hejtmanek wrote:
> On Mon, Oct 21, 2013 at 09:39:33AM -0400, konrad wilk wrote:
> > Anyhow, one easy thing to figure out is to get the lspci -v output
> > from the InfiniBand card
> > to see where its BARs are, and also the start of the kernel. You
>
On Mon, Oct 21, 2013 at 10:18:55AM -0400, Konrad Rzeszutek Wilk wrote:
> Odd, there should be messages about 1-1 mapping when you use 'debug'.
cat /proc/cmdline
placeholder root=UUID=b5711e0a-3fc8-44ec-940f-112e60d8f143 ro debug
so I suppose, I did it right. Maybe I didn't compile something impo
>>> On 21.10.13 at 16:18, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 21, 2013 at 04:06:07PM +0200, Lukas Hejtmanek wrote:
>> Region 2: Memory at 380fff00 (64-bit, prefetchable) [size=8M]
>...
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -92,6 +92,9 @@ static void __in
> The signature handover operation is binding all the necessary
> information for the HCA together: where is the data (data_mr), where is
> the protection information (prot_mr), what are the signature properties
> (sig_attrs).
> Once this step is taken (WR is posted), a single MR (sig_mr) describes
> This MR can be perceived as a generalization of fast_reg MR. When using
> fast memory registration the verbs user will call ib_alloc_fast_reg_mr() in
> order to allocate an MR that may be used for fast registration method by
> posting
> a fast registration work-request on the send-queue (FRWR). T
On Mon, Oct 21, 2013 at 03:27:50PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 16:18, Konrad Rzeszutek Wilk
> >>> wrote:
> > On Mon, Oct 21, 2013 at 04:06:07PM +0200, Lukas Hejtmanek wrote:
> >> Region 2: Memory at 380fff00 (64-bit, prefetchable) [size=8M]
> >...
> > --- a/arch/x86
>>> On 21.10.13 at 16:44, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 21, 2013 at 03:27:50PM +0100, Jan Beulich wrote:
>> >>> On 21.10.13 at 16:18, Konrad Rzeszutek Wilk
>> >>> wrote:
>> > On Mon, Oct 21, 2013 at 04:06:07PM +0200, Lukas Hejtmanek wrote:
>> >> Region 2: Memory at 380fff000
On 10/21/2013 5:34 PM, Hefty, Sean wrote:
The signature handover operation is binding all the necessary
information for the HCA together: where is the data (data_mr), where is
the protection information (prot_mr), what are the signature properties
(sig_attrs).
Once this step is taken (WR is poste
On Thu, Oct 17, 2013 at 8:29 AM, Yann Droneaud wrote:
>> Just to double check, by no means we are talking on reverting the
>> whole series, flow-steering will be in
>> 3.12 in the IB core and mlx4_ib
Correct, just hiding the unstable userspace ABI for now.
> I believe it will disable by #if 0 /
From: Yann Droneaud
The create_flow/destroy_flow uverbs and the associated extensions to
the user-kernel verbs ABI are under review and are too experimental to
freeze at this point.
So userspace is not exposed to experimental features and an uinstable
ABI, temporarily disable this for v3.12 (wit
On 10/17/2013 7:10 AM, Bernd Schubert wrote:
> A missing non-mandatory file is not an error.
>
> Signed-off-by: Bernd Schubert
Thanks. Applied.
-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Hi Bernd,
On 10/17/2013 7:10 AM, Bernd Schubert wrote:
> If partitions.conf is for some reasons invalid or empty, try again
> with the default configuration.
>
> This will re-use the default configuration created by prtn_make_default(),
> but osm_prtn_make_new() will automatically overwrite the i
On Mon, 21 Oct 2013 00:12:54 -0400
Doug Ledford wrote:
> I think I like my suggestion better: go back to having a full table,
> but use a bitmap to indicate valid entries and then use the bitmap to
> limit our comparisons in the find_cached* functions, and put the
> get_* funtions back to being O
21 matches
Mail list logo
