search for: _mm

...linux-2.6.13.orig/include/asm-i386/mmu_context.h 2005-08-10 17:06:52.000000000 -0700 +++ linux-2.6.13/include/asm-i386/mmu_context.h 2005-08-10 17:11:40.000000000 -0700 @@ -6,6 +6,7 @@ #include <asm/atomic.h> #include <asm/pgalloc.h> #include <asm/tlbflush.h> +#include <mach_mmu.h> /* * Used for LDT copy/destruction. @@ -15,12 +16,14 @@ struct mm_struct * old_mm; int retval = 0; + memset(&mm->context, 0, sizeof(mm->context)); init_MUTEX(&mm->context.sem); - mm->context.size = 0; old_mm = current->mm; if (old_mm && unlikel...

...linux-2.6.13.orig/include/asm-i386/mmu_context.h 2005-08-10 17:06:52.000000000 -0700 +++ linux-2.6.13/include/asm-i386/mmu_context.h 2005-08-10 17:11:40.000000000 -0700 @@ -6,6 +6,7 @@ #include <asm/atomic.h> #include <asm/pgalloc.h> #include <asm/tlbflush.h> +#include <mach_mmu.h> /* * Used for LDT copy/destruction. @@ -15,12 +16,14 @@ struct mm_struct * old_mm; int retval = 0; + memset(&mm->context, 0, sizeof(mm->context)); init_MUTEX(&mm->context.sem); - mm->context.size = 0; old_mm = current->mm; if (old_mm && unlikel...

...ebases confirm this). There's one problem with this approach: non-temporal accesses on x86 are only ordered by fence instructions! This means that code using non-temporal accesses can't rely on LLVM's fence opcode to do the right thing, they instead have to rely on architecture-specific _mm*fence intrinsics. *But wait! Who said developers need to issue any type of fence when using non-temporals?* Well, the LLVM memory model sure didn't. The x86 memory model does (volume 3 section 8.2.2 Memory Ordering) but LLVM targets more than x86 and the backends are free to ignore the !nont...

nvkm_mm_fini() was not called when exiting the driver, resulting in a memory leak. Fix this. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nouveau_platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform...

...this approach: non-temporal accesses on > > x86 > > are only ordered by fence instructions! This means that code using > > non-temporal accesses can't rely on LLVM's fence opcode to do the > > right thing, they instead have to rely on architecture-specific > > _mm*fence intrinsics. > > Just for clarify: the proposal to change the implementation of > ceq_cst is arguable separate from this proposal. It will go through > normal patch review once the semantics are addressed. Whatever we > end up doing with ceq_cst, we currently have a semantic ho...

Changes since v3: - Use a single dma_attr for all DMA-API allocations in instmem instead of one per allocation - Use device.info.ram_size instead of pfb->ram to check whether VRAM is present outside of nvkm Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into

Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to, and can trick

A series I have waited too long to submit, and the recent refactoring made me pay the price of my perfectionism, so here are the features that are at least completed Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to,

...rnel: SMP Nov 8 17:21:53 poseidon kernel: Modules linked in: nfs lockd nfs_acl smbfs radeon drm parport_pc lp parport autofs4 i2c_dev i2c_core rfcomm l2cap bluetooth sunrpc ipv6 dm_mod video button battery ac uhci_hcd ehci_hcd hw_random shpchp e1000 floppy mptspi sg ext3 jbd megaraid_mbox megaraid_mm m ptscsih mptbase sd_mod scsi_mod Nov 8 17:21:53 poseidon kernel: CPU: 3 Nov 8 17:21:53 poseidon kernel: EIP: 0060:[<f8b4b5a4>] Not tainted VLI Nov 8 17:21:53 poseidon kernel: EFLAGS: 00010206 (2.6.13-1.1532_FC4smp) Nov 8 17:21:53 poseidon kernel: EIP is at smbiod+0xef/0x184 [s...

Thanks Ilia for the v2 review! Here is the v3 of this IOMMU support for GK20A series. Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove

.... There's one > problem with this approach: non-temporal accesses on x86 are only ordered > by fence instructions! This means that code using non-temporal accesses > can't rely on LLVM's fence opcode to do the right thing, they instead > have to rely on architecture-specific _mm*fence intrinsics. > > > > > > *But wait! Who said developers need to issue any type of fence when using > non-temporals?* > > > > Well, the LLVM memory model sure didn't. The x86 memory model does (volume > 3 section 8.2.2 Memory Ordering) but LLVM targets mo...

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking