- 19 Apr, 2008 40 commits
-
-
Glauber Costa authored
This patch implements mapping_error for pci-nommu_64.c. It takes care to keep the same compatible behaviour it already had. Although this file is not (yet) used for i386, we introduce the i386 version here. Again, care is taken, even at the expense of an ifdef, to keep the same behaviour inconditionally. Signed-off-by:
Glauber Costa <gcosta@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Glauber Costa authored
This functions are now called conditionally on their existence in the struct. So just delete them, instead of keeping an empty implementation. Signed-off-by:
-
Glauber Costa authored
This patch introduces pci-dma.c, a common file for pci dma between i386 and x86_64. As a start, dma_set_mask() is the same between architectures, and is placed there. Signed-off-by:
-
Mark McLoughlin authored
ERROR: "dma_supported" [drivers/ssb/ssb.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic79xx.ko] undefined! ERROR: "dma_supported" [drivers/net/pcnet32.ko] undefined! ERROR: "dma_supported" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "dma_set_mask" [drivers/media/video/meye.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx8802.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx8800.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx88-alsa.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx23885/cx23885.ko] undefined! They just need to be exported like on x86_64. dma_supported() and dma_set_mask() were previously inlined, but are now moved to pci-dma_32.c. Since they're used by various drivers, they need to be exported. Signed-off-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Glauber Costa authored
all the code that is left is ready to be merged as-is in dma-mapping.h. Signed-off-by:
-
Glauber Costa authored
define it conditionally to i386. Signed-off-by:
-
Glauber Costa authored
We provide a map_error function in pci-base_32.c to make sure i386 keeps with the same behaviour it used to. Signed-off-by:
-
Glauber Costa authored
It's initially 0, since we don't expect any DMA there. Signed-off-by:
-
Glauber Costa authored
Do it instead of using the conservative approach we're currently doing. This is the way x86_64 does, and this patch makes this piece of code the same between them, ready to be integrated. Signed-off-by:
-
Glauber Costa authored
This is the way x86_64 does, so this make them equal. They have to be extern now in the header, and the extern definition is moved to the common dma-mapping.h header. Signed-off-by:
-
Glauber Costa authored
they are the same in both architectures. Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Glauber Costa authored
They are similar enough to do this move. the macro version is ugly, and we use inline functions instead. Signed-off-by:
-
Glauber Costa authored
they are the same between architectures. (except for the fact that x86_64 has duplicate code) move them to dma-mapping.h Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
the old i386 implementation is moved to pci-base_32.c Signed-off-by:
-
Glauber Costa authored
i386 base does not need it, so it gets an empty function. Signed-off-by:
-
Glauber Costa authored
That's already the name of the game for x86_64. For i386, we add a pci-base_32.c, that will hold the default operations. The function call itself goes through dma-mapping.h , the common header Signed-off-by:
-
Glauber Costa authored
take it off the x86_64 specific header Signed-off-by:
-
Yinghai Lu authored
a system with 256 GB of RAM, when NUMA is disabled crashes the following way: Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Cannot allocate aperture memory hole (ffff8101c0000000,65536K) Kernel panic - not syncing: Not enough memory for aperture Pid: 0, comm: swapper Not tainted 2.6.25-rc4-x86-latest.git #33 Call Trace: [<ffffffff84037c62>] panic+0xb2/0x190 [<ffffffff840381fc>] ? release_console_sem+0x7c/0x250 [<ffffffff847b1628>] ? __alloc_bootmem_nopanic+0x48/0x90 [<ffffffff847b0ac9>] ? free_bootmem+0x29/0x50 [<ffffffff847ac1f7>] gart_iommu_hole_init+0x5e7/0x680 [<ffffffff847b255b>] ? alloc_large_system_hash+0x16b/0x310 [<ffffffff84506a2f>] ? _etext+0x0/0x1 [<ffffffff847a2e8c>] pci_iommu_alloc+0x1c/0x40 [<ffffffff847ac795>] mem_init+0x45/0x1a0 [<ffffffff8479ff35>] start_kernel+0x295/0x380 [<ffffffff8479f1c2>] _sinittext+0x1c2/0x230 the root cause is : memmap PMD is too big, [ffffe200e0600000-ffffe200e07fffff] PMD ->ffff81383c000000 on node 0 almost near 4G..., and vmemmap_alloc_block will use up the ram under 4G. solution will be: 1. make memmap allocation get memory above 4G... 2. reserve some dma32 range early before we try to set up memmap for all. and release that before pci_iommu_alloc, so gart or swiotlb could get some range under 4g limit for sure. the patch is using method 2. because method1 may need more code to handle SPARSEMEM and SPASEMEM_VMEMMAP will get Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 4000000 Memory: 264245736k/268959744k available (8484k kernel code, 4187464k reserved, 4004k data, 724k init) Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Suresh Siddha authored
For example, If the physical address layout on a two node system with 8 GB memory is something like: node 0: 0-2GB, 4-6GB node 1: 2-4GB, 6-8GB Current kernels fail to boot/detect this NUMA topology. ACPI SRAT tables can expose such a topology which needs to be supported. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
-
Roland McGrath authored
The 64-bit vDSO's sources are compiled with -g0 for no good reason. Using -g when enabled lets their separate debug files be used at runtime via build ID matching, same as we can see 32-bit vDSO's assembly sources. Signed-off-by:
Roland McGrath <roland@redhat.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Suresh Siddha authored
Signed-off-by:
-
Suresh Siddha authored
Signed-off-by:
-
Suresh Siddha authored
Only allocate the FPU area when the application actually uses FPU, i.e., in the first lazy FPU trap. This could save memory for non-fpu using apps. for example: on my system after boot, there are around 300 processes, with only 17 using FPU. Signed-off-by:
-
Suresh Siddha authored
Split the FPU save area from the task struct. This allows easy migration of FPU context, and it's generally cleaner. It also allows the following two optimizations: 1) only allocate when the application actually uses FPU, so in the first lazy FPU trap. This could save memory for non-fpu using apps. Next patch does this lazy allocation. 2) allocate the right size for the actual cpu rather than 512 bytes always. Patches enabling xsave/xrstor support (coming shortly) will take advantage of this. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Ingo Molnar authored
this function doesnt just 'find' the max_pfn - it also has other side-effects such as registering sparse memory maps. Signed-off-by:
-
Thomas Gleixner authored
We already catch most of the TSC problems by sanity checks, but there is a subtle bug which has been in the code forever. This can cause time jumps in the range of hours. This was reported in: http://lkml.org/lkml/2007/8/23/96 and http://lkml.org/lkml/2008/3/31/23 I was able to reproduce the problem with a gettimeofday loop test on a dual core and a quad core machine which both have sychronized TSCs. The TSCs seems not to be perfectly in sync though, but the kernel is not able to detect the slight delta in the sync check. Still there exists an extremly small window where this delta can be observed with a real big time jump. So far I was only able to reproduce this with the vsyscall gettimeofday implementation, but in theory this might be observable with the syscall based version as well. CPU 0 updates the clock source variables under xtime/vyscall lock and CPU1, where the TSC is slighty behind CPU0, is reading the time right after the seqlock was unlocked. The clocksource reference data was updated with the TSC from CPU0 and the value which is read from TSC on CPU1 is less than the reference data. This results in a huge delta value due to the unsigned subtraction of the TSC value and the reference value. This algorithm can not be changed due to the support of wrapping clock sources like pm timer. The huge delta is converted to nanoseconds and added to xtime, which is then observable by the caller. The next gettimeofday call on CPU1 will show the correct time again as now the TSC has advanced above the reference value. To prevent this TSC specific wreckage we need to compare the TSC value against the reference value and return the latter when it is larger than the actual TSC value. I pondered to mark the TSC unstable when the readout is smaller than the reference value, but this would render an otherwise good and fast clocksource unusable without a real good reason. Signed-off-by: -
Erik Bosman authored
This patch adds three tests that test whether the PR_GET_TSC and PR_SET_TSC commands have the desirable effect. The tests check whether the control register is updated correctly at context switches and try to discover bugs while enabling/disabling the timestamp counter. Signed-off-by:
Erik Bosman <ejbosman@cs.vu.nl> Signed-off-by:
-
Erik Bosman authored
This patch implements the PR_GET_TSC and PR_SET_TSC prctl() commands on the x86 platform (both 32 and 64 bit.) These commands control the ability to read the timestamp counter from userspace (the RDTSC instruction.) While the RDTSC instuction is a useful profiling tool, it is also the source of some non-determinism in ring-3. For deterministic replay applications it is useful to be able to trap and emulate (and record the outcome of) this instruction. This patch uses code earlier used to disable the timestamp counter for the SECCOMP framework. A side-effect of this patch is that the SECCOMP environment will now also disable the timestamp counter on x86_64 due to the addition of the TIF_NOTSC define on this platform. The code which enables/disables the RDTSC instruction during context switches is in the __switch_to_xtra function, which already handles other unusual conditions, so normal performance should not have to suffer from this change. Signed-off-by:
-
Erik Bosman authored
This patch adds prctl commands that make it possible to deny the execution of timestamp counters in userspace. If this is not implemented on a specific architecture, prctl will return -EINVAL. ned-off-by:
-
Steven Rostedt authored
This annotates NMI functions with notrace. Some tracers may be able to live with this, but some cannot. The safest is to turn it off, it's not particularly interesting anyway. Signed-off-by:
Steven Rostedt <srostedt@redhat.com> Signed-off-by:
-
Pavel Machek authored
Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Jiri Slaby authored
- noexec32 is on by default for years already - add noexec32 to kernel-parameters and fix noexec typo in there Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
