Allow setting a "dmabarrier" when the mthca driver registers user- allocated memory. Signed-off-by: Arthur Kepner <akepner@sgi.com> --- mthca_provider.c | 7 ++++++- mthca_user.h | 10 +++++++++- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c index 17486a4..c818708 100644 --- a/drivers/infiniband/hw/mthca/mthca_provider.c +++ b/drivers/infiniband/hw/mthca/mthca_prov...

Pass a "dmabarrier" argument to ib_umem_get() and use the new argument to control setting the DMA_BARRIER_ATTR attribute on the memory that ib_umem_get() maps for DMA. Signed-off-by: Arthur Kepner <akepner@sgi.com> --- drivers/infiniband/core/umem.c | 8 ++++++-- drivers/infiniband/hw/amso1100/c2_provider.c | 2 +- drivers/infiniband/hw/cxgb3/iwch_provider.c | 2 +- drivers/infiniband/hw/ehca/ehca_mrmw.c | 2 +- drivers/infiniband/hw/ipath/ipath_mr....

Document dma_flags_set_attr(). Signed-off-by: Arthur Kepner <akepner@sgi.com> --- DMA-API.txt | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index cc7a8c3..16e15c0 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -544,3 +544,30 @@ size is the size (and should be a page-sized multiple). The return value will be either a pointer to the processor virtual address of th...

define dma_flags_set_attr() for sn-ia64 - it "borrows" bits from the direction argument (renamed "flags") to the dma_map_* routines to pass an additional attributes. Also define routines to retrieve the original direction and attribute from "flags". Signed-off-by: Arthur Kepner <akepner@sgi.com> --- arch/ia64/sn/pci/pci_dma.c | 37 +++++++++++++++++++++++++++---------- include/asm-ia64/sn/io.h | 23 +++++++++++++++++++++++ 2 files changed, 50 insertions(+), 10 deletions(-) ...

Introduce the dma_flags_set_attr() interface and give it a default no-op implementation. Signed-off-by: Arthur Kepner <akepner@sgi.com> --- dma-mapping.h | 8 ++++++++ 1 files changed, 8 insertions(+) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 2dc21cb..4990aaf 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -99,4 +99,12 @@ static inline void dmam_release_declared_memory(struct device *dev) } #endif /* ARCH_HAS...

On Altix, DMA may be reordered between a device and host memory. This reordering can happen in the NUMA interconnect, and it usually results in correct operation and improved performance. In some situations it may be necessary to explicitly synchronize DMA from the device. This patchset allows a memory region to be mapped with a "dmabarrier". Writes to the memory region will cause in-flight DMA to be flushed, providing a mechanism to order DMA from a device. There are 5 patches in this p...

Sure, but I'm asking about the effect of the patches on the (avg-write-speed == device-capabilities) case. I agree that they are necessary for timely syncing of data but I'm trying to understand what effect they have on the normal write case True, but if we know we are not congested and have more work I'm interested to know what tests show that pushing more I/O when you don't have block device congestion make the system go mad (and what mad means). It sounds to me like it's hiding (yet ano...

Signed-off-by: Jeff Garzik <jgarzik@redhat.com> --- After having to go figure out what some of these means, I figured I would save others the trouble. Some of these are "best guess" based on a quick scan of the code, so it certainly needs a sanity review before going upstream. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4d175c7..8afea9b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -763,6 +...

Ah! Well, seeing as how we already have a provision for arch-specific options in kernel-parameters.txt, and some less-obscure arch-specific options can be found there, I think an argument can be made for my patch :) Nonethless, if the maintainer disagrees, they can drop this patch I suppose. Jeff -

Hi, Now, SYSTEM_RAM is registerd to resouce list and a user can see memory map from /proc/iomem, like following. == [kamezawa@drpq linux-2.6.23-rc8-mm2]$ grep RAM /proc/iomem 00000000-0009ffff : System RAM 00100000-03ffffff : System RAM 04000000-04f1bfff : System RAM 04f1c000-6b4b9fff : System RAM 6b4ba000-6b797fff : System RAM 6b798000-6b799fff : System RAM 6b79a000-6b79dfff : System RAM 6b79e000-6b79efff : System RAM 6b79f000-6b7fbfff : System RAM 6b7fc000-6c629fff : System RAM 6c62a000-6...

Hi,=20 Sorry about this but the latest sky2 seems damned odd. I have been running with jumbo frames at home for quite some time but with this kernel that doesn't work, i instead get loads of: sky2 eth0: rx length error: status 0x5e60500 length 1510 sky2 eth0: rx length error: status 0x5e60500 length 1510 sky2 eth0: rx length error: status 0x5ea0500 length 1514 sky2 eth0: rx length error: status 0x5ea0500 length 1514 Where length can be just about anything from 800 -> MTU That is not enough...

Confirmed working. Now running with 9k mtu with no errors, =3D) It also seems that the FIFO bug was the one that affected me before, Tested-by: Ian Kumlien <pomac@vapor.com> (if that tag exists now) Btw, Sorry but all mail directly to you will be blocked. I have yet to fix the relaying properly with isp:s blocking port 25 etc so for some of --=20 Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net

Hello I hope this is the right place to ask this.Does any know if there is a substantial difference in the performance of the traffic controller between kernel 2.4 and 2.6. We tested it using 1 iperf server and use 250 and 500 clients, altering the burst. We use the top command to check the idle time of our router to see this. The results we got from the 2.4 kernel shows around 65-70% idle time while the 2.6 shows 60-65% idle time. We tried to use MRTG and we're not getting any results either. We wa...

Hi all, Jeremy had some boot changes for bzImages, but buried in there was an update to the boot protocol to support Xen and lguest (and kvm-lite). I've copied those fairly simple patches, and if HPA is happy I'd like to push them for 2.6.24 (after correcting for the Great Arch Merge of course). Thanks, Rusty. -

This sounds like another good reason to do the ELF image as the postcompression image. The interface to the embedded compression routine is then unchanged, and we get the "full vmlinux" with any notes that belongs there. I'll try to get an implementation of that done -- it really shouldn't be very hard. -hpa -

No, not at all. I'm proposing that the existing bzImage format be retained, but that the payload of the decompressor (already a gzip file) simply be vmlinux.gz -- i.e. a gzip compressed ELF file, notes and all. A pointer in the header will point to the offset of the payload (this is new, obviously.) The decompression stub is adjusted to expect an ELF image, instead of a raw binary. Existing bootloaders (16- or 32-bit) simply load the bzImage the way they do now; new bootloaders have th...

It would be cleaner to actually parse the ELF; it's only a handful of lines of code (we don't have to support arbitrary placement of sections, Uhm, no it doesn't. Those bootloaders jump to the decompressor, not to It doesn't have to if it doesn't want to; it only needs to do so if it wants to access the kernel as an ELF. Again, it has the advantage that the ELF is the real vmlinux, no funnies. -hpa -

Acked-by: H. Peter Anvin <hpa@zytor.com> -hpa -

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- include/linux/linkage.h | 6 ++++++ 1 file changed, 6 insertions(+) =================================================================== --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -34,6 +34,12 @@ name: #endif +#ifndef WEAK +#define WEAK(name) \ + .weak name; \ + name: +#endif + #define KPROBE_ENTRY(name) \ .pushsection .k...

Version 2.07 of the boot protocol uses 0x23C for the hardware_subarch field, that for lguest is "1". This allows us to use the standard boot entry point rather than the "GenuineLguest" string hack. This entry point also clears the BSS and copies the boot parameters and commandline for us, saving more code. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- Documentation/lguest/lguest.c | 31 ++++--------------------------- arch/i386/kernel/head.S | 8 ++++++++ drivers...

Hello, Currently it is possible for some errors to be detected at write-back time but not reported to the program as shown by the following script using the included make_file.c. ---------8<---------8<---------8<---------8<---------8<---------8<--------- #!/bin/sh # We binary search the size of a file in 40M filesystem that can cause # the missed error. MIN=5000000 MAX=50000000 rm fs.40M dd if=/dev/zero of=fs.40M bs=40M count=0 seek=1 status=noxfer mkfs.ext2 -F fs.40M...

Hello, Now that the site has a few months of life, it's time to advertize its existence to the kernel community! The site is collecting hardware compatibilities and incompatibilities with Linux distributions in a collaborative way: users run a hardware collector program, upload the resulting file and then rate and comment how their hardware works. You could be interested in the pages around kernel modules: http://hardware4linux.info/modules/. You can also access to the information concerning PCI a...

I know I'll be getting hell for this, I must be a masochist. Anyway, I've been trying to figure out what purpose the gpl-only code serves. What good comes out of disabling people from probing modules that do not have a gpl-compatible license? Of cause, I would love to see more hardware manufactures release either full specs, or GPL'd drivers, and I'm sure it will happen, in time. But until then, why are people wasting time writing code to inhibit those who do not agree with them on licensing? ...

find /lib/modules/`uname -r` -iname '*.ko' | wc -l: 2021 Proprietary modules that I can think of: 5 to 10 It's not even 1/2 a !#$ percent. (Though knowing that many modules are for Not a kernel problem. (That said, MS would probably face yet another antitrust charge if it did that. Perhaps you intended to buy a game console instead? That said, no one is restraining you. You can edit the kernel source and rip out all the GPL checks. On top, it's not like the ati or nvidia blob...

Hi! My computer suffers from high load average when the system is idle, introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 . Long story: 2.6.20 and all later versions I've tested, including 2.6.21 and 2.6.22, make the load average high. Even when the computer is totally idle (I've tested in single user mode), the load average end up at ~0.30. The computer is still responsive, and the only fault seems to be the too high load average. All versions up to and including 2.6.19.7 is fine...