On Fri, Nov 18, 2011 at 12:45 AM, Roland Dreier wrote:
> On Thu, Nov 17, 2011 at 11:25 AM, Bart Van Assche wrote:
>> + pr_err("%s[%d]: unexpected opcode %d", __func__, __LINE__,
>> + opcode);
>> + WARN_ON(true);
>
> Not a big deal, but I guess this
From: David Miller
Date: Fri, 18 Nov 2011 01:17:08 -0500 (EST)
> That explains everything. The problem is that we don't do the sparc64
> PTE handling code patching in modules. So it's left at the default 4U
> versions.
...
> I'll work on a fix for this.
Ok, please test this out, thanks!
From: Lukas Razik
Date: Fri, 18 Nov 2011 05:02:57 + (GMT)
> After applying your patch I still get the errors:
> [ 1117.556582] swap_free: Bad swap file entry 14e61800
> [ 1117.556710] BUG: Bad page map in process ibv_devinfo pte:9cc300104608
> pmd:00f882d0
This looks almost lik
From: Lukas Razik
Date: Fri, 18 Nov 2011 05:02:57 + (GMT)
> Hello David!
>
> After applying your patch I still get the errors:
Thanks for testing, while I continue to look into this please double
check to make sure you really did run a kernel with the patch applied
:-)
--
To unsubscribe fro
David Miller wrote:
> Can someone with the effected hardware please test this?
>
>
> [PATCH] sparc: Kill custom io_remap_pfn_range().
>
> To handle the large physical addresses, just make a simple wrapper
> around remap_pfn_range() like MIPS does.
>
> Signed-off-by: David
David Miller wrote:
> Can someone with the effected hardware please test this?
>
>
> [PATCH] sparc: Kill custom io_remap_pfn_range().
>
> To handle the large physical addresses, just make a simple wrapper
> around remap_pfn_range() like MIPS does.
>
> Signed-off-by: David
From: Roland Dreier
Date: Thu, 17 Nov 2011 18:17:08 -0800
> Anyway definitely makes sense as something to check.
Another difference is remap_pfn_range() uses pte_mkspecial().
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kerne
From: David Miller
Date: Thu, 17 Nov 2011 21:03:16 -0500 (EST)
> Patch coming up for testing in a bit.
Can someone with the effected hardware please test this?
[PATCH] sparc: Kill custom io_remap_pfn_range().
To handle the large physical addresses, just make a simple wrapp
On Thu, Nov 17, 2011 at 6:03 PM, David Miller wrote:
> I suspect this is an issue about who is responsible for setting the
> various VM_* flags in the VMA.
>
> It at least used to be the case that the caller was responsible, but
> it seems that this has changed in some regard. And if you look at
From: Roland Dreier
Date: Thu, 17 Nov 2011 15:30:19 -0800
> But the call trace is in the munmap() call -- it's just printing where the
> bad map was set up initially. We're somewhere in unmap_vmas(),
> probably one of the tests in zap_pte_range(). Since we got
>
> [ 9305.698663] swap_free:
On Thu, Nov 17, 2011 at 11:25 AM, Bart Van Assche wrote:
> + pr_err("%s[%d]: unexpected opcode %d", __func__, __LINE__,
> + opcode);
> + WARN_ON(true);
Not a big deal, but I guess this could just be
WARN(1, "unexpected opcode %d", opcode);
On Thu, Nov 17, 2011 at 1:49 PM, David Miller wrote:
>> I'm wondering if the bug is in the mlx4 code or in the sparc
>> io_remap_pfn_range()
>> code. From the "Bad page map" pte value, if I understand sparc mm correctly,
>> the PTE is seen as not present.
> The not-present test is essentially te
From: Lukas Razik
Date: Wed, 16 Nov 2011 19:22:34 + (GMT)
> I'm wondering if the bug is in the mlx4 code or in the sparc
> io_remap_pfn_range()
> code. From the "Bad page map" pte value, if I understand sparc mm correctly,
> the PTE is seen as not present.
The not-present test is essentiall
With CONFIG_BUG=n the __WARN() macro is not defined. Avoid that
building with CONFIG_BUG=n fails by replacing __WARN() with
WARN_ON(true). Also make sure that each such statement is preceeded
by an appropriate pr_err() statement.
Signed-off-by: Bart Van Assche
Cc: Nicholas Bellinger
Cc: Roland D
On Thu, Nov 17, 2011 at 3:34 AM, Randy Dunlap wrote:
> On 11/15/2011 06:33 PM, Stephen Rothwell wrote:
>> Hi all,
>
>
> When CONFIG_BUG is not enabled:
>
> next-2011-1116/drivers/infiniband/ulp/srpt/ib_srpt.c: In function
> 'srpt_cm_dreq_recv':
> next-2011-1116/drivers/infiniband/ulp/srpt/ib_srpt
Christoph Lameter writes:
>
> We have an app here that runs fine with OFED. But if I try to use the
> kernel IB subsystem in 3.2 it complains about packets being looped back to
> the application.
>
> That seems to be controlled by IB_DEVICE_BLOCK_MULTICAST_LOOPBACK and
> IB_QP_CREATE_BLOCK_MULTI
I'm hitting an ENOMEM from ibv_reg_mr() when trying to register in excess
of ~ 26 Gb on a host with 96 Gb of RAM. I've also noticed that once I
register memory it seems to get demoted from hugepages.
Hardware is ConnectX-2:
hca_id: mlx4_0
transport: InfiniBand (0)
17 matches
Mail list logo
