Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device driver.

On Sat, Jan 13, 2007 at 05:07:28PM -0800, Arjan van de Ven wrote: > > + > > +#define DPRINTK(_f, _a...) pr_debug(_f, ## _a) > > why this silly abstraction? Just use pr_debug in the code directly Actually, for drivers, like this one, you should use the dev_printk() and friends (dev_dbg, dev_err,

Re: No more "device" symlinks for classes

On Sun, Jan 14, 2007 at 09:10:59AM +0300, Andrey Borzenkov wrote: > Pierre Ossman wrote: > > > Hi guys, > > > > I just wanted to know the rationale behind > > 99ef3ef8d5f2f5b5312627127ad63df27c0d0d05 (no more "device" symlink in > > class devices). I thought that was a rather convenient way of

Re: [patch 18/20] XEN-paravirt: Add Xen driver utility functions.

On Fri, Jan 12, 2007 at 05:45:57PM -0800, Jeremy Fitzhardinge wrote: > Allocate/destroy a 'vmalloc' VM area: alloc_vm_area and free_vm_area > The alloc function ensures that page tables are constructed for the > region of kernel virtual address space and mapped into init_mm. Shouldn't these

Re: Linux v2.6.20-rc5

On Sun, Jan 14, 2007 at 03:38:24PM +0800, Jeff Chua wrote: > On 1/13/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >On Jan 13 2007 06:01, Adrian Bunk wrote: > >>On Fri, Jan 12, 2007 at 02:26:45PM -0800, Andrew Morton wrote: > > >*cough*vmware*cough* > > setting CONFIG_PARAVIRT=y will return in

Re: Linux v2.6.20-rc5

On 1/13/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Jan 13 2007 06:01, Adrian Bunk wrote: >On Fri, Jan 12, 2007 at 02:26:45PM -0800, Andrew Morton wrote: *cough*vmware*cough* setting CONFIG_PARAVIRT=y will return in ... vmmon.ko module unknown symbol paravirt_ops Without it,

[patch-mm 3/3] Scheduled removal of SA_xxx interrupt flags fixups 2 (mm)

The obsolete SA_xxx interrupt flags have been used despite the scheduled removal. Fixup the remaining users in -mm. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Index: linux-2.6.20-rc4-mm1/arch/i386/kernel/vmitime.c === ---

[patch 2/3] Scheduled removal of SA_xxx interrupt flags fixups

The obsolete SA_xxx interrupt flags have been used despite the scheduled removal. Fixup the remaining users. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Index: linux-2.6.20-rc5/kernel/irq/manage.c === ---

[patch 1/3] Scheduled removal of SA_xxx interrupt flags

The name space cleanup of the interrupt request flags (SA_xxx -> IRQF_xxx) left a 6 month grace period for the old deprecated flags. Remove them. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Index: linux-2.6.20-rc3-mm1/Documentation/feature-removal-schedule.txt

[patch 0/3] Scheduled removal of SA_xxx interrupt flags

Andrew, the following series removes the deprecated SA_xx interrupt flags as scheduled. There are some new users of those flags since the initial cleanup patch. The fixup of those users is split into two parts: 1) mainline fixups 2) -mm fixups tglx -- - To unsubscribe from this list:

[patch] faster vgetcpu using sidt (take 2)

ok here is the latest rev of this patch (against 2.6.20-rc4). timings in cycles: baseline patchedbaseline patched no cache no cachecache cache k8 pre-revF2116 1417 k8 revF3117 14

Re: No more "device" symlinks for classes

Pierre Ossman wrote: > Hi guys, > > I just wanted to know the rationale behind > 99ef3ef8d5f2f5b5312627127ad63df27c0d0d05 (no more "device" symlink in > class devices). I thought that was a rather convenient way of finding > which physical device the class device was coupled to. > Actually I

[PATCH 10/11] x86_64 ia32 vDSO: use install_special_mapping

This patch uses install_special_mapping for the ia32 vDSO setup, consolidating duplicated code. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/x86_64/ia32/syscall32.c | 75 -- include/asm-x86_64/proto.h |1 - 2 files changed, 21

[PATCH 11/11] powerpc vDSO: use install_special_mapping

This patch uses install_special_mapping for the powerpc vDSO setup, consolidating duplicated code. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/powerpc/kernel/vdso.c | 104 +++ 1 files changed, 27 insertions(+), 77 deletions(-) diff --git

[PATCH 9/11] i386 vDSO: use install_special_mapping

This patch uses install_special_mapping for the i386 vDSO setup, consolidating duplicated code. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/i386/kernel/sysenter.c | 53 +-- 1 files changed, 11 insertions(+), 42 deletions(-) diff --git

[PATCH 8/11] Add install_special_mapping

This patchs adds a utility function install_special_mapping, for creating a special vma using a fixed set of preallocated pages as backing, such as for a vDSO. This consolidates some nearly identical code used for vDSO mapping reimplemented for different architectures. Signed-off-by: Roland

[PATCH 6/11] powerpc vDSO: use VM_ALWAYSDUMP

This patch fixes core dumps to include the vDSO vma, which is left out now. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/powerpc/kernel/vdso.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c

[PATCH 7/11] x86_64 ia32 vDSO: define arch_vma_name

This patch makes x86_64 define arch_vma_name for CONFIG_IA32_EMULATION. This makes the ia32 vDSO mapping appear in /proc/PID/maps with "[vdso]" for ia32 processes, as it does on native i386. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/x86_64/ia32/syscall32.c |8 1

[PATCH 5/11] x86_64 ia32 vDSO: use VM_ALWAYSDUMP

This patch fixes ia32 core dumps on x86_64 to include just one phdr for the vDSO vma. Currently it writes a confused format with two phdrs for the address, one without contents and one with. This patch removes the special-case core writing macros for the ia32 vDSO. Instead, it uses

[PATCH 4/11] i386 vDSO: use VM_ALWAYSDUMP

This patch fixes core dumps to include the vDSO vma, which is left out now. It removes the special-case core writing macros, which were not doing the right thing for the vDSO vma anyway. Instead, it uses VM_ALWAYSDUMP in the vma; there is no need for the fixmap page to be installed. It handles

[PATCH 2/11] Fix gate_vma.vm_flags

This patch fixes the initialization of gate_vma.vm_flags and gate_vma.vm_page_prot to reflect reality. This makes the "[vdso]" line in /proc/PID/maps correctly show r-xp instead of ---p, when gate_vma is used (CONFIG_COMPAT_VDSO on i386). Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> ---

[PATCH 3/11] Add VM_ALWAYSDUMP

This patch adds the VM_ALWAYSDUMP flag for vm_flags in vm_area_struct. This provides a clean explicit way to have a vma always included in core dumps, as is needed for vDSO's. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- fs/binfmt_elf.c|4 include/linux/mm.h |1 + 2

[PATCH 1/11] Fix CONFIG_COMPAT_VDSO

I wouldn't mind if CONFIG_COMPAT_VDSO went away entirely. But if it's there, it should work properly. Currently it's quite haphazard: both real vma and fixmap are mapped, both are put in the two different AT_* slots, sysenter returns to the vma address rather than the fixmap address, and core

Re: [RFC][PATCH] MMC: Major restructuring and cleanup

Pierre Ossman wrote: > Hi everyone, > > As I've mentioned to some of you, I've been working on restructuring the MMC > layer in order to make it more easily maintained and to allow extensions > like SDIO support. A first draft of this is now ready for public review. > I've cc:d those who have

How to flush the disk write cache from userspace

Hi, (please CC: to my email address, I'm not subscribed) Quick question: how can I flush the disk write cache from userspace? Long question: I'm porting the Solaris ZFS filesystem to the FUSE/Linux filesystem framework. This is a copy-on-write, transactional filesystem and so it needs to ensure

Re: [patch 10/10] mm: fix pagecache write deadlocks

Nick Piggin wrote: @@ -1878,31 +1889,88 @@ generic_file_buffered_write(struct kiocb break; } + /* +* non-uptodate pages cannot cope with short copies, and we +* cannot take a pagefault with the destination page locked.

Re: ahci_softreset prevents acpi_power_off

Robert Hancock wrote: Faik Uygur wrote: What happens when you try to shutdown? Does not shutdown and freezes. Hand copied last messages seen on console: Synchronizing SCSI cache for disk sda: ACPI: PCI Interrupt for device :06:08.0 disabled Power down. acpi_power_off called

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

On Sat, 13 Jan 2007 12:54:43 EST, Lennart Sorensen said: > On Fri, Jan 12, 2007 at 10:38:43PM -0500, [EMAIL PROTECTED] wrote: > > CONFIG_MCORE2=y > > Oh good. Makes life much simpler for users. After writing that, I actually went back and *checked* the fine print. It turns out that unless you

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

On Sat, 13 Jan 2007 15:18:31 EST, Bill Davidsen said: > [EMAIL PROTECTED] wrote: > > On Fri, 12 Jan 2007 10:03:49 EST, Lennart Sorensen said: > >> I would expect any distribution should work on these (as long as the > >> kernel they use isn't too old.). Of course if it is a Mac, you need a > >>

Re: [PATCH] libata: PIIX3 support

Mikael Pettersson wrote: On Wed, 10 Jan 2007 17:13:38 +, Alan <[EMAIL PROTECTED]> wrote: This I believe completes the PIIX range of support for libata This adds the table entries needed for the PIIX3, both a new PCI identifier and a new mode list. It also fixes an erroneous access to PCI

Re: ahci_softreset prevents acpi_power_off

Faik Uygur wrote: What happens when you try to shutdown? Does not shutdown and freezes. Hand copied last messages seen on console: Synchronizing SCSI cache for disk sda: ACPI: PCI Interrupt for device :06:08.0 disabled Power down. acpi_power_off called hwsleep-0285 [01]

Re: [patch 20/20] XEN-paravirt: Add Xen virtual block device driver.

> +#include "../../../arch/i386/paravirt-xen/events.h" > +#include "../../../arch/i386/paravirt-xen/xen-page.h" this shows the headers are clearly in the wrong place... > + > + err = xenbus_printf(xbt, dev->nodename, > + "ring-ref","%u", info->ring_ref); why do you

[patch 12/12] mark struct inode_operations const 3

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 12/12] mark struct inode_operations const Many struct inode_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 11/12] mark struct inode_operations const 2

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 11/12] mark struct inode_operations const Many struct inode_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 09/12] mark struct file_operations const 9

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 09/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 10/12] mark struct inode_operations const 1

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 10/12] mark struct inode_operations const Many struct inode_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

Re: [RFC] How to (automatically) find the correct maintainer(s)

I wrote: > gcc -o test3.o test.c test.c ^^ typo gcc -o test3.o test.c test2.c -- Stefan Richter -=-=-=== ---= -===- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More

[patch 07/12] mark struct file_operations const 7

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 07/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 08/12] mark struct file_operations const 8

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 08/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 05/12] mark struct file_operations const 5

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 05/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 06/12] mark struct file_operations const 6

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 06/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

Re: [RFC] How to (automatically) find the correct maintainer(s)

On 14 Jan, Richard Knutsson wrote: > Stefan Richter wrote: [getting a wrong contact from looking at the MAINTAINERS file] > Hopefully, but I think it is asking much of the maintainer and then > there will certanly be confused/frustrated submitter who don't know why > they don't get any answer

[patch 04/12] mark struct file_operations const 4

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 04/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 03/12] mark struct file_operations const 3

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 03/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 02/12] mark struct file_operations const 2

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 02/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

[patch 00/12] Fix ppc64's writing to struct file_operations

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 00/12] Fix ppc64's writing to struct file_operations the ppc64 code needlessly wrote to a struct file_operations variable; this patch turns this into a compile time initialization instead. Signed-off-by: Arjan van de Ven <[EMAIL

[patch 01/12] mark struct file_operations const 1

From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: [patch 01/12] mark struct file_operations const Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch

Patch series to mark struct file_operations and struct inode_operations const

Hi, today a sizable portion of the "struct file_operations" variables in the kernel are const, but by far not all. Nor are any of the struct inode_operations const. Marking these read-only datastructures const has the advantage of reducing false sharing of these, often hot, datastructures. In

Re: [patch 09/20] XEN-paravirt: dont export paravirt_ops structure, do individual functions

On Fri, 2007-01-12 at 17:45 -0800, Jeremy Fitzhardinge wrote: > Wrap the paravirt_ops members we want to export in wrapper functions. Andrew, the removal of paravirt_ops export here will break kvm. Feel free to re-add "EXPORT_SYMBOL_GPL(paravirt_ops)" at the bottom of

Re: No more "device" symlinks for classes

On Sun, 2007-01-14 at 01:29 +0100, Pierre Ossman wrote: > Kay Sievers wrote: > > > > The plan is to have a single unified tree at /sys/devices, where all > > device-directories live below their parents, and /sys/class contains > > only symlinks pointing into this single tree, just like /sys/bus. >

Re: [patch 16/20] XEN-paravirt: Add the Xen virtual console driver.

Alan wrote: > Andrew: No objection to this tty stuff being merged provided the bugs > noted above (not worried about the sign stuff) are fixed before it goes > on to Linus. > Thanks for the comments. I'll see if I can put together a fixup patch before LCA, but possibly not. J - To

How to mmap a shadow framebuffer in virtual memory

Hello, This is driving me crazy. I wrote this custom fb driver for an organic LED display for an embedded ARM system. The display is connected trough an I2C bus, therefore the display buffer is not memory mapped. Anyway, I want to support mmap() and my driver allocates shadow buffer with

Re: No more "device" symlinks for classes

Kay Sievers wrote: > > The plan is to have a single unified tree at /sys/devices, where all > device-directories live below their parents, and /sys/class contains > only symlinks pointing into this single tree, just like /sys/bus. > > People want to stack class-devices, but this leads to a

Re: [patch 16/20] XEN-paravirt: Add the Xen virtual console driver.

> +#endif > + tty_insert_flip_char(xencons_tty, buf[i], 0); Please use the defines like TTY_NORMAL not just 0. > + if ((xencons_tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) && > + (xencons_tty->ldisc.write_wakeup != NULL)) > +

Re: [Xen-devel] [patch 02/20] XEN-paravirt: Add a flag to allow the VGA console to be disabled

On Fri, 12 Jan 2007 17:45:41 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Add a flag to allow the VGA console to be disabled. The VGA code will > spin forever if there isn't any real VGA hardware, which will happen > under Xen. If it is doing this then the real bug should be fixed so

Re: [RFC] How to (automatically) find the correct maintainer(s)

Richard Knutsson wrote: > Matthias Schniedermeyer wrote: > >> Richard Knutsson wrote: >> >> >> >>> Any thoughts on this is very much appreciated (is there any flaws with >>> this?). >>> >> >> >> The thought that crossed my mind was: >> >> Why not do the same thing that was done to the

Re: No more "device" symlinks for classes

On Sun, 2007-01-14 at 00:51 +0100, Pierre Ossman wrote: > I just wanted to know the rationale behind > 99ef3ef8d5f2f5b5312627127ad63df27c0d0d05 (no more "device" symlink in > class devices). I thought that was a rather convenient way of finding > which physical device the class device was coupled

Re: tuning/tweaking VM settings for low memory (preventing OOM)

On Sat, Jan 13, 2007 at 03:30:27PM +0100, Willy Tarreau wrote: > On Sat, Jan 13, 2007 at 02:16:01PM +0100, Toon van der Pas wrote: > > On Sat, Jan 13, 2007 at 08:22:18AM +0100, Willy Tarreau wrote: > > > > > > > > Which makes me think that we aren't writing back fast enough. If I > > > > mount

Re: Linux v2.6.20-rc5

CC [M] drivers/kvm/vmx.o {standard input}: Assembler messages: {standard input}:3257: Error: bad register name `%sil' make[2]: *** [drivers/kvm/vmx.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 Am I missing something or this is a real problem? What's on (and

Re: [RFC] How to (automatically) find the correct maintainer(s)

Matthias Schniedermeyer wrote: Richard Knutsson wrote: Any thoughts on this is very much appreciated (is there any flaws with this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly

Re: [RFC] How to (automatically) find the correct maintainer(s)

Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: [...] SUPERCOOL ALPHA CARD P: Clark Kent M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] C: SUPER_A S: Maintained (C: for CONFIG. Any better

[patch 03/20] XEN-paravirt: paravirt: page-table accessors

Add a set of accessors to pack, unpack and modify page table entries (at all levels). This allows a paravirt implementation to control the contents of pgd/pmd/pte entries. For example, Xen uses this to convert the (pseudo-)physical address into a machine address when populating a pagetable

[patch 18/20] XEN-paravirt: Add Xen driver utility functions.

Allocate/destroy a 'vmalloc' VM area: alloc_vm_area and free_vm_area The alloc function ensures that page tables are constructed for the region of kernel virtual address space and mapped into init_mm. Lock an area so that PTEs are accessible in the current address space: lock_vm_area and

[patch 05/20] XEN-paravirt: paravirt: reserve fixmap slot

Reserve a new fixmap slot for paravirt backends. Xen uses this for mapping the hypervisor shared-info page, which doesn't really exist in the guest address space. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Chris Wright <[EMAIL PROTECTED]> Cc: Zachary Amsden <[EMAIL PROTECTED]>

[patch 20/20] XEN-paravirt: Add Xen virtual block device driver.

The block device frontend driver allows the kernel to access block devices exported exported by a virtual machine containing a physical block device driver. Signed-off-by: Ian Pratt <[EMAIL PROTECTED]> Signed-off-by: Christian Limpach <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL

[patch 13/20] XEN-paravirt: Xen: Add config options and disable unsupported config options.

The XEN config option enables the Xen paravirt_ops interface, which is installed when the kernel finds itself running under Xen. (By some as-yet fully defined mechanism, implemented in a future patch.) Xen is no longer a sub-architecture, so the X86_XEN subarch config option has gone. The

[patch 12/20] XEN-paravirt: Xen: Add nosegneg capability to the vsyscall page notes

Add the "nosegneg" fake capabilty to the vsyscall page notes. This is used by the runtime linker to select a glibc version which then disables negative-offset accesses to the thread-local segment via %gs. These accesses require emulation in Xen (because segments are truncated to protect the

[patch 10/20] XEN-paravirt: mm lifetime hooks

Add hooks to allow a paravirt implementation to track the lifetime of an mm. Unfortunately dup_mmap and exit_mmap are in generic code, so we need to #ifdef CONFIG_PARAVIRT. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Chris Wright <[EMAIL PROTECTED]> Cc: Zachary Amsden <[EMAIL

[patch 08/20] XEN-paravirt: paravirt pgd allocation alignment

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Chris Wright <[EMAIL PROTECTED]> Cc: Zachary Amsden <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]> Cc: Rusty Russell <[EMAIL PROTECTED]>

[patch 07/20] XEN-paravirt: paravirt shared kernel pmd flag

Xen does not allow guests to have the kernel pmd shared between page tables, so parameterize pgtable.c to allow both modes of operation. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Chris Wright <[EMAIL PROTECTED]> Cc: Zachary Amsden <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL

[patch 11/20] XEN-paravirt: Add apply_to_page_range() which applies a function to a pte range.

Add a new mm function apply_to_page_range() which applies a given function to every pte in a given virtual address range in a given mm structure. This is a generic alternative to cut-and-pasting the Linux idiomatic pagetable walking code in every place that a sequence of PTEs must be accessed.

[patch 06/20] XEN-paravirt: remove pgd ctor

Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Chris Wright <[EMAIL PROTECTED]> Cc: Zachary Amsden <[EMAIL PROTECTED]> Cc:

[patch 17/20] XEN-paravirt: Add Xen grant table support

Add Xen 'grant table' driver which allows granting of access to selected local memory pages by other virtual machines and, symmetrically, the mapping of remote memory pages which other virtual machines have granted access to. This driver is a prerequisite for many of the Xen virtual device

[patch 09/20] XEN-paravirt: dont export paravirt_ops structure, do individual functions

Wrap the paravirt_ops members we want to export in wrapper functions. Since we binary-patch the critical ones, this doesn't make a speed impact. I moved drm_follow_page into the core, to avoid having to wrap the various pte ops. Unlining kernel_fpu_end and using that in the RAID6 code would

[patch 16/20] XEN-paravirt: Add the Xen virtual console driver.

This provides a bootstrap and ongoing emergency console which is intended to be available from very early during boot and at all times thereafter, in contrast with alternatives such as UDP-based syslogd, or logging in via ssh. The protocol is based on a simple shared-memory ring buffer.

[patch 04/20] XEN-paravirt: paravirt pagetable init

Add paravirt hooks into the initial pagetable setup. In the native case, the kernel builds itself a new initial pagetable from scratch. In the Xen case, the kernel starts with a pagetable provided by the hypervisor, which is used as the prototype for the kernel-generated pagetable. The hooks

[patch 02/20] XEN-paravirt: Add a flag to allow the VGA console to be disabled

Add a flag to allow the VGA console to be disabled. The VGA code will spin forever if there isn't any real VGA hardware, which will happen under Xen. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]>

[patch 01/20] XEN-paravirt: Fix typo in sync_constant_test_bit()s name.

Fix typo in sync_constant_test_bit()s name. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> === --- a/include/asm-i386/sync_bitops.h +++ b/include/asm-i386/sync_bitops.h @@ -130,7 +130,7 @@ static inline int

[patch 00/20] XEN-paravirt: Xen guest implementation for paravirt_ops interface

This patch series implements the Linux Xen guest in terms of the paravirt-ops interface. The features in implemented this patch series are: * domU only * UP only (most code is SMP-safe, but there's no way to create a new vcpu) * writable pagetables, with late pinning/early unpinning (no

Re: [Linux-fbdev-devel] Display class

Andrew please apply this patch. Signed-off-by: James Simmons <[EMAIL PROTECTED]> > > > Hi, > > > > On Tuesday 05 December 2006 13:03, James Simmons wrote: > > > +int probe_edid(struct display_device *dev, void *data) > > > +{ > > > +   struct fb_monspecs spec; > > > +   ssize_t size =

Re: [-mm patch] make mmc_sysfs.c:mmc_key_type static

Adrian Bunk wrote: > On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote: >> ... >> Changes since 2.6.20-rc3-mm1: >> ... >> git-mmc.patch >> ... >> git trees >> ... > > > This patch makes the needlessly global struct mmc_key_type static. > > Signed-off-by: Adrian Bunk <[EMAIL

Re: Display class

> Hi, > > On Tuesday 05 December 2006 13:03, James Simmons wrote: > > +int probe_edid(struct display_device *dev, void *data) > > +{ > > +   struct fb_monspecs spec; > > +   ssize_t size = 45; That code was only for testing. I do have new core code. Andrew could you merge this patch as

[PATCH -mm] MMCONFIG: Reject a broken MCFG tables on Asus etc

This rejects a broken MCFG tables on Asus etc. Arjan and Andi suggest this. Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]> --- arch/i386/pci/mmconfig-shared.c | 24 ++- arch/i386/pci/mmconfig.c|9 --- arch/x86_64/pci/mmconfig.c | 50

Re: High lock spin time for zone->lru_lock under extreme conditions

> On Sat, 13 Jan 2007 11:53:34 -0800 Ravikiran G Thirumalai <[EMAIL PROTECTED]> > wrote: > On Sat, Jan 13, 2007 at 12:00:17AM -0800, Andrew Morton wrote: > > > On Fri, 12 Jan 2007 23:36:43 -0800 Ravikiran G Thirumalai <[EMAIL > > > PROTECTED]> wrote: > > > > >void __lockfunc

Re: 2.6 Partitioning bug with LILO

On Fri, Jan 12, 2007 at 06:18:00PM -0500, Kris Karas wrote: > Hello Andries, > > I noticed you're listed as the maintainer for the disk > geometry/partitioning logic in the 2.6 kernel, so I'm sending this to > you, as I think this bug is most likely in that part of the code, ... > > I've been

Re: 2.6.20-rc5: known unfixed regressions

On Sat, 13 Jan 2007, Adrian Bunk wrote: On Sat, Jan 13, 2007 at 04:51:36PM +0100, Damien Wyart wrote: * Adrian Bunk <[EMAIL PROTECTED]> [070113 08:11]: This still leaves the old regressions we have not yet fixed... This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19.

2.6.20-rc4-mm1 USB (asix) problem

The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1, but not 2.6.20-rc3-mm1. I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix' driver. When I upgraded to 2.6.20-rc4-mm1, they were still recognized, but various ifconfig operations on them (up/down, changing IP)

Re: O_DIRECT question

Bill Davidsen wrote: > Linus Torvalds wrote: >> [] >> But what O_DIRECT does right now is _not_ really sensible, and the >> O_DIRECT propeller-heads seem to have some problem even admitting that >> there _is_ a problem, because they don't care. > > You say that as if it were a failing. Currently

Re: Kernel command line for a specific framebuffer console driver

Hi Alexey, On Friday 12 January 2007 20:36, Alexey Dobriyan wrote: > On Fri, Jan 12, 2007 at 01:43:42PM +0100, Juergen Beisert wrote: > > does someone know how to forward a kernel command line option to > > configure the AMD Geode GX1 framebuffer? > > > > I tried with "video=gx1fb:[EMAIL

Re: Linux v2.6.20-rc5

Jeff Chua wrote: On 1/13/07, Jeff Chua <[EMAIL PROTECTED]> wrote: On 1/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 12 Jan 2007 14:27:48 -0500 (EST) > Linus Torvalds <[EMAIL PROTECTED]> wrote: CC [M] drivers/kvm/vmx.o {standard input}: Assembler messages: {standard input}:3257:

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

[EMAIL PROTECTED] wrote: On Fri, 12 Jan 2007 10:03:49 EST, Lennart Sorensen said: I would expect any distribution should work on these (as long as the kernel they use isn't too old.). Of course if it is a Mac, you need a distribution that supports their firmware (which is of course not a PC

Re: [RFC] How to (automatically) find the correct maintainer(s)

On 13 Jan, Richard Knutsson wrote: > Stefan Richter wrote: >> On 13 Jan, Richard Knutsson wrote: >> [...] >> >>> SUPERCOOL ALPHA CARD >>> >>> P: Clark Kent >>> M: [EMAIL PROTECTED] >>> L: [EMAIL PROTECTED] >>> C: SUPER_A >>> S: Maintained >>> (C: for CONFIG. Any better idea?) >>> >>> then

Re: O_DIRECT question

Linus Torvalds wrote: On Sat, 13 Jan 2007, Michael Tokarev wrote: (No, really - this load isn't entirely synthetic. It's a typical database workload - random I/O all over, on a large file. If it can, it combines several I/Os into one, by requesting more than a single block at a time, but

Re: [RFC] How to (automatically) find the correct maintainer(s)

Richard Knutsson wrote: > Any thoughts on this is very much appreciated (is there any flaws with > this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all

Re: High lock spin time for zone->lru_lock under extreme conditions

On Sat, Jan 13, 2007 at 12:00:17AM -0800, Andrew Morton wrote: > > On Fri, 12 Jan 2007 23:36:43 -0800 Ravikiran G Thirumalai <[EMAIL > > PROTECTED]> wrote: > > > >void __lockfunc _spin_lock_irq(spinlock_t *lock) > > > >{ > > > >local_irq_disable(); > > > >>

Re: O_DIRECT question

Bodo Eggert wrote: (*) This would allow fadvise_size(), too, which could reduce fragmentation (and give an early warning on full disks) without forcing e.g. fat to zero all blocks. OTOH, fadvise_size() would allow users to reserve the complete disk space without his filesizes

Re: [RFC] How to (automatically) find the correct maintainer(s)

Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: [...] SUPERCOOL ALPHA CARD P: Clark Kent M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] C: SUPER_A S: Maintained (C: for CONFIG. Any better idea?) then if someone changes a file who are built with CONFIG_SUPER_A,

[-mm] reiserfs4 still hangs

Hi, using 2.6.20-rc3-mm1 and 2.6.20-rc4-mm1, I get reiserfs4 related processes in down state (not only using googleearth...). Any hints? sysrq-t shows: Jan 13 19:32:57 fb07-iapwap2 kernel: googleearth-b D 0001 0 6089 6072 6109 (NOTLB) Jan 13 19:32:57 fb07-iapwap2

Re: [-mm] reiserfs4 still hangs

> On Sat, 13 Jan 2007 19:54:53 +0100 Marc Dietrich <[EMAIL PROTECTED]> wrote: > > Hi, > > using 2.6.20-rc3-mm1 and 2.6.20-rc4-mm1, I get reiserfs4 related processes in > down state (not only using googleearth...). Any hints? > > sysrq-t shows: > > Jan 13 19:32:57 fb07-iapwap2 kernel:

Re: ieee1394 feature needed: overwrite SPLIT_TIMEOUT from userspace

(full quote for linux1394-devel) On 12 Jan, Philipp Beyer wrote to linux-kernel: > Hi, > > I'm investigating an unwanted behaviour of our firewire devices in > connection with the ieee1394 kernel module. > > The problem is caused by a non standard-conform behaviour of our > devices. Anyway,

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

On Fri, Jan 12, 2007 at 10:38:43PM -0500, [EMAIL PROTECTED] wrote: > amd64 will only work on a core2duo if it's a T7200 or higher - the > lower numbers are 32-bit-only chipsets. I admit not knowing what > exact variant the Mac has. The Core Duo had 32bit only (being a Pentium M), but the Core 2

  1   2   3   >