Robert, Here are the arch perfmon changes ported to your latest oprofile tree. I didn't include the forcepmu=... change yet, that will come later. Right now the force option is just removed. Please pull. Thanks, -Andi The following changes since commit 22d87103484983035cf46891428819573ec7508d: Robert Richter (1): Merge branch 'oprofile/powerpc-for-paul' into oprofile/master are available in the git repository at: ...

compat-ioctl: further compactify table Most entries use the basic compat handler, which means for most entries it's redundant. Rather than store a handler for each entry, we split the table so that there are two entry types, the 'basic stuff' and the handler pointer. At build time, the table is sorted so that each entry with a handler pointer is two entries, handler pointer first. At init time we re-sort the list so that all the handler pointers are at the end of the table and each basic ...

You mean by using a closed hash? Acked-by: Andi Kleen <ak@linux.intel.com> -Andi --

Hi, I'm currently trying to get the 2.6.26.5 kernel to work but cannot get the sata dvdrom to be recognized by the MCP55. The controller works with the 2.6.24.4 and 2.6.25.17 kernels. I had to use CONFIG_ACPI_DOCK=y for the 2.6.25.17 but this did not work with the 2.6.26.5. The problem has been confirmed on at least 2 machines. I have tried various boot options (pci=nomsi, acpi=off and any other relevant code I could find) but nothing seems to work. The odd thing is the sata dvdrom was ...

If 2.6.27 is released with e1000e driver corrupting EEPROM contents on many systems out there, rendering the cards unusable for most of the i-am-not-a-hacker users (and remember, even Dave Airlie bricked his laptop completely to death, when trying to restore eeprom contents), well, I personally find that very scary. Intel is working with us on tracking down and resolving the issue, but this is not going as well as one would like to see (one attempt, one card with completely hosed EEPROM ...

unless there is news that I missed, the E1000 bricking bug is still out there. that is a particularly nasty one. --

Linus, Please pull the latest timers-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers-fixes-for-linus The patches fix hard to trigger bugs in the CPU offline code of hrtimers which were noticed by Paul McKenney recently. In the worst case they can leave migrated hrtimers in a stale state. Thanks, tglx ------------------> Thomas Gleixner (4): hrtimer: migrate pending list on cpu offline hrtimer: fix migration ...

From: Chuck Ebbert <cebbert@redhat.com> x86: move prefill_possible_map calling early, fix, V2 fix: Fix this by making prefill_possible_map() available even when CONFIG_HOTPLUG_CPU is not set. The function is needed so that the number of possible CPUs can be determined. Tested on uniprocessor machine with CPU hotplug disabled. From boot log: Before: NR_CPUS: 512, nr_cpu_ids: 512, nr_node_ids 1 After: NR_CPUS: 512, nr_cpu_ids: 1, nr_node_ids 1 Signed-off-by: Chuck Ebbert ...

From: Chuck Ebbert <cebbert@redhat.com> xen: make CONFIG_XEN_SAVE_RESTORE depend on CONFIG_XEN Xen options need to depend on XEN. Also, add newline at end of file. Without this patch you need to disable CONFIG_PM in order to disable CPU hotplugging. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> --- Index: linux-2.6.26.noarch/arch/x86/xen/Kconfig =================================================================== --- linux-2.6.26.noarch.orig/arch/x86/xen/Kconfig +++ ...

Just one question, Suppose I have non-standard remote, and I want to teach lirc to use it, and I have general purpose receiver, how can I do this? Best regards, --

Can you see if the patch at http://bugzilla.kernel.org/attachment.cgi?id=18044&action=view (against current -git) helps? Thanks, Rafael --

Commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a causes my Thinkpad T21 to no longer generate any hotkey events (e.g. suspend fn-f4, switch-output fn-f7, etc.) after resume. It's regression from 2.6.25. 2.6.26 and 2.6.27-rc7 are broken, reverting that commit on 2.6.27-rc7 makes keys work again. Thanks. [Rafael added for regression tracking ;] commit 1b7fc5aae8867046f8d3d45808309d5b7f2e036a Author: Alexey Starikovskiy <astarikovskiy@suse.de> Date: Fri Jun 6 11:49:33 2008 -0400 ...

[PATCH 4/4] Add sysfs entries for UV Create /sys/firmware/sgi_uv sysfs entries for partition_id and coherence_id. Signed-off-by: Russ Anderson <rja@sgi.com> --- arch/x86/kernel/Makefile | 2 - arch/x86/kernel/uv_sysfs.c | 72 +++++++++++++++++++++++++++++++++++++++++++++ include/asm-x86/uv/bios.h | 1 3 files changed, 74 insertions(+), 1 deletion(-) Index: linux/arch/x86/kernel/Makefile =================================================================== --- ...

[PATCH 2/4] Add UV bios call infrastructure Add the UV wrapper code to call OEM runtime service. Signed-off-by: Russ Anderson <rja@sgi.com> Signed-off-by: Paul Jackson <pj@sgi.com> --- arch/x86/kernel/bios_uv.c | 73 ++++++++++++++++++++++++++++++++-------------- include/asm-x86/uv/bios.h | 62 ++++++++++++++++++--------------------- 2 files changed, 82 insertions(+), 53 deletions(-) Index: ...

[PATCH 0/4] x86: UV runtime bios calls Purpose: Create an interface to allow calls into bios to return platform specific information. The interface adds a new EFI runtime call for OEMs. EFI provides a mechanism for defining runtime calls to firmware routines. This patchset builds on the EFI mechanism to provide access to those firmware routines. Version 3 changes: Add function (oem) to efi_runtime_services_t, replacing uv_systab. Use efi_call_virt<n>. Remove efi_call<n> ...

[attempting resend in plain-text only because thunderbird lost the battle vs. vger] --

From: Bruce Allan <bruce.w.allan@intel.com> Export set_memory_ro() and set_memory_rw() calls for use by drivers that need to have more debug information about who might be writing to memory space. this was initially developed for use while debugging a memory corruption problem with e1000e. patch was modified with this suggestion. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> --- ...

Seems unnecessarily complicated. -Andi -- ak@linux.intel.com --

don't need to break earlier, could get more optimized setting automatically results: 1. hpa reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x13c000000 (5056MB), size= 64MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, ...

Show node to memory section relationship with symlinks in sysfs Add /sys/devices/system/node/nodeX/memoryY symlinks for all the memory sections located on nodeX. For example: /sys/devices/system/node/node1/memory135 -> ../../memory/memory135 indicates that memory section 135 resides on node1. Successfully tested with 2.6.27-rc7 source on 2-node x86_64, 2-node ppc64, and 2-node ia64 systems. Also revises documentation to cover this change as well as ...

The per cpu reserve from which loadable modules allocate their percpu sections is currently fixed at 8000 bytes. Add a new kernel parameter percpu=<dynamically allocatable percpu bytes> The per cpu reserve area will be used in following patches by the per cpu allocator. Signed-off-by: Christoph Lameter <cl@linux-foundation.org> --- arch/ia64/include/asm/percpu.h | 1 + include/linux/percpu.h | 7 ++++++- init/main.c | 13 +++++++++++++ 3 files ...

Just do the bare mininum to establish a per cpu allocator. Later patchsets will gradually build out the functionality. The most critical issue that came up awhile back was how to configure the size of the percpu area. Here we simply use a kernel parameter and use the static size of the existing percpu allocator for modules as a default. The effect of this patchset is to make the size of percpu data for modules configurable. Its no longer fixed at 8000 bytes. Changes: V5->V6: - Fix various ...

Remove the builtin per cpu allocator from modules.c and use cpu_alloc instead. Signed-off-by: Christoph Lameter <cl@linux-foundation.org> --- include/linux/module.h | 1 kernel/module.c | 178 ++++--------------------------------------------- 2 files changed, 17 insertions(+), 162 deletions(-) Index: linux-2.6/kernel/module.c =================================================================== --- linux-2.6.orig/kernel/module.c 2008-09-19 08:12:10.000000000 -0500 +++ ...

The number of BIOSes that have an option to enable the IOMMU, or fix anything about its configuration, is vanishingly small. There's no good reason to punish quiet boot for this. Signed-off-by: Adam Jackson <ajax@redhat.com> --- arch/x86/kernel/aperture_64.c | 6 +++--- include/asm-x86/gart.h | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c index 44e2182..9a32b37 100644 --- ...

This patch adapts the boot tracer to the new type of the print_line callback. It still relays entries it doesn't support to default output functions. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- kernel/trace/trace_boot.c | 15 +++++++++------ 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c index d5c9e2e..48186b1 100644 --- a/kernel/trace/trace_boot.c +++ b/kernel/trace/trace_boot.c @@ -45,21 +45,24 @@ ...

Adapt mmiotrace to the new print_line type. By default, it ignores (and consumes) types it doesn't support. Acked-by: Pekka Paalanen <pq@iki.fi> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- kernel/trace/trace_mmiotrace.c | 25 ++++++++++++------------- 1 files changed, 12 insertions(+), 13 deletions(-) diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c index a108c32..be0a6b0 100644 --- a/kernel/trace/trace_mmiotrace.c +++ ...

From: Pekka Paalanen <pq@iki.fi> This patch fixes a bug which break the pipe when the seq is empty. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- kernel/trace/trace.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 61f33da..ed10a68 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2610,7 +2610,6 @@ tracing_read_pipe(struct file *filp, char __user *ubuf, sret = ...

Here is my latest information regarding this bug. Problem: some users report that with many of the latest beta distros, during a reboot when e1000e loads it says "NVM checksum is not valid" and the driver fails to load. updated hardware affected list: laptops and desktops with 82566 or 82567 based LAN parts, which are machines with the ICH8, ICH9, ICH10R chipsets and a variety of processors. The machines I know of that have reported the issue include Lenovo X300 HP 2510p Intel ...

We need a kind of disambiguation when a print_line callback returns 0. _There is not enough space to print all the entry. Please flush the seq and retry. _I can't handle this type of entry This patch changes the type of this callback for better information. Also some changes have been made in this V2. _ Only relay to default functions after the print_line callback fails. _ This patch doesn't fix the issue with the broken pipe (see patch 2/4 for that) Some things are still in ...

Hi all, What about: pci_iomap_bar(pdev, bar) that uses pci_iomap (with the patch of Grant, http://lkml.org/lkml/2008/9/29/172) and simplifies the arguments of pci_iomap() and makes all the checks of the proposed by Arjan for ioremap_pcibar()? Best of both worlds? ;-) I like the simplification proposed by Arjan. Regards. Marin Mitov P.S. I am not on the list. --

[Empty message]

Signed-of-by: Mike Travis <travis@sgi.com> --- include/linux/sched.h | 18 +- kernel/sched.c | 450 +++++++++++++++++++++++--------------------------- kernel/sched_cpupri.c | 6 kernel/sched_cpupri.h | 8 kernel/sched_fair.c | 2 kernel/sched_rt.c | 50 ++--- 6 files changed, 252 insertions(+), 282 deletions(-) --- struct-cpumasks.orig/include/linux/sched.h +++ struct-cpumasks/include/linux/sched.h @@ -248,7 +248,7 @@ extern void init_idle_bootup_task(struct ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/cpu/common.c | 2 arch/x86/kernel/cpu/intel_cacheinfo.c | 16 +++---- arch/x86/kernel/cpu/mcheck/mce_64.c | 4 - arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 44 +++++++++++---------- arch/x86/kernel/setup_percpu.c | 8 +-- drivers/base/cpu.c | 6 +- include/linux/cpuset.h | 12 ++--- include/linux/percpu.h | 7 +-- kernel/cpu.c ...

Signed-of-by: Mike Travis <travis@sgi.com> --- drivers/base/node.c | 6 +++--- drivers/base/topology.c | 20 +++++++++++--------- drivers/firmware/dcdbas.c | 6 +++--- drivers/net/sfc/efx.c | 2 +- drivers/oprofile/buffer_sync.c | 2 +- include/asm-x86/paravirt.h | 6 +++--- include/asm-x86/processor.h | 2 +- include/asm-x86/topology.h | 14 +++++++------- include/asm-x86/uv/uv_bau.h | 2 +- include/linux/interrupt.h ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/tlb_32.c | 24 ++++++++++++------------ arch/x86/kernel/tlb_64.c | 23 ++++++++++++----------- arch/x86/kernel/tlb_uv.c | 12 ++++++------ include/asm-x86/tlbflush.h | 6 +++--- 4 files changed, 33 insertions(+), 32 deletions(-) --- struct-cpumasks.orig/arch/x86/kernel/tlb_32.c +++ struct-cpumasks/arch/x86/kernel/tlb_32.c @@ -20,7 +20,7 @@ DEFINE_PER_CPU(struct tlb_state, cpu_tlb * Optimizations Manfred Spraul ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/smp.c | 6 +++--- arch/x86/kernel/smpboot.c | 20 ++++++++++++-------- include/asm-x86/smp.h | 6 +++--- include/linux/smp.h | 8 ++++---- kernel/smp.c | 15 ++++++++------- 5 files changed, 30 insertions(+), 25 deletions(-) --- struct-cpumasks.orig/arch/x86/kernel/smp.c +++ struct-cpumasks/arch/x86/kernel/smp.c @@ -118,15 +118,15 @@ static void native_smp_send_reschedule(i ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/irq_64.c | 6 +++--- include/asm-x86/irq.h | 2 +- include/linux/irq.h | 10 +++++----- kernel/irq/manage.c | 12 ++++++------ kernel/irq/migration.c | 6 +++--- kernel/irq/proc.c | 13 +++++++------ 6 files changed, 25 insertions(+), 24 deletions(-) --- struct-cpumasks.orig/arch/x86/kernel/irq_64.c +++ struct-cpumasks/arch/x86/kernel/irq_64.c @@ -242,14 +242,14 @@ asmlinkage unsigned int ...

Signed-of-by: Mike Travis <travis@sgi.com> --- include/linux/mm_types.h | 2 +- mm/allocpercpu.c | 18 +++++++++--------- mm/page_alloc.c | 6 +++--- mm/pdflush.c | 6 +++--- mm/quicklist.c | 4 ++-- mm/slab.c | 4 ++-- mm/slub.c | 4 ++-- mm/vmscan.c | 8 ++++---- mm/vmstat.c | 6 +++--- 9 files changed, 29 insertions(+), 29 deletions(-) --- ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/xen/enlighten.c | 9 +++++---- arch/x86/xen/smp.c | 12 ++++++------ arch/x86/xen/suspend.c | 2 +- arch/x86/xen/time.c | 2 +- arch/x86/xen/xen-ops.h | 2 +- drivers/xen/events.c | 6 +++--- 6 files changed, 17 insertions(+), 16 deletions(-) --- struct-cpumasks.orig/arch/x86/xen/enlighten.c +++ struct-cpumasks/arch/x86/xen/enlighten.c @@ -626,16 +626,17 @@ static void xen_flush_tlb_single(unsigne ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/acpi/boot.c | 2 - arch/x86/kernel/apic.c | 2 - arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 4 +-- arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 6 ++--- arch/x86/kernel/cpu/intel_cacheinfo.c | 4 +-- arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 2 - arch/x86/kernel/cpu/proc.c | 4 +-- arch/x86/kernel/genapic_flat_64.c | 4 +-- ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/acpi/cstate.c | 4 ++-- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 12 ++++++------ arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 20 ++++++++++---------- arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c | 12 ++++++------ arch/x86/kernel/cpu/cpufreq/speedstep-ich.c | 12 ++++++------ arch/x86/kernel/cpu/intel_cacheinfo.c | 4 ++-- arch/x86/kernel/cpu/mcheck/mce_amd_64.c ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 6 +-- arch/x86/kernel/cpu/cpufreq/p4-clockmod.c | 6 +-- arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 8 ++--- arch/x86/kernel/cpu/cpufreq/speedstep-centrino.c | 10 +++--- arch/x86/kernel/cpu/cpufreq/speedstep-ich.c | 4 +- arch/x86/kernel/cpu/intel_cacheinfo.c | 2 - arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 4 +- ...

Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/smpboot.c | 20 ++++++++++---------- include/asm-x86/smp.h | 20 ++++++++++---------- 2 files changed, 20 insertions(+), 20 deletions(-) --- struct-cpumasks.orig/arch/x86/kernel/smpboot.c +++ struct-cpumasks/arch/x86/kernel/smpboot.c @@ -102,20 +102,20 @@ EXPORT_SYMBOL(smp_num_siblings); DEFINE_PER_CPU(u16, cpu_llc_id) = BAD_APICID; /* bitmap of online cpus */ -cpumask_t cpu_online_map __read_mostly; +cpumask_map_t ...

Signed-of-by: Mike Travis <travis@sgi.com> --- include/linux/sched.h | 6 +++--- include/linux/seq_file.h | 4 ++-- init/main.c | 11 ++++++----- kernel/cpu.c | 5 +++++ 4 files changed, 16 insertions(+), 10 deletions(-) --- struct-cpumasks.orig/include/linux/sched.h +++ struct-cpumasks/include/linux/sched.h @@ -1583,10 +1583,10 @@ extern cputime_t task_gtime(struct task_ #ifdef CONFIG_SMP extern int set_cpus_allowed_ptr(struct task_struct ...

Signed-of-by: Mike Travis <travis@sgi.com> --- cpumask.txt | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) --- /dev/null +++ struct-cpumasks/cpumask.txt @@ -0,0 +1,73 @@ + + CPUMASKS + -------- + + [PRELIMINARY] + +Introduction + +Cpumask variables are used to represent (with a single bit) all the +CPU's in a system. With the prolific increase in the number of CPU's +in a single system image (SSI), managing this large ...

Signed-of-by: Mike Travis <travis@sgi.com> --- lib/cpumask.c | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) --- struct-cpumasks.orig/lib/cpumask.c +++ struct-cpumasks/lib/cpumask.c @@ -3,34 +3,40 @@ #include <linux/cpumask.h> #include <linux/module.h> -int __first_cpu(const cpumask_t *srcp) +int cpus_first(const_cpumask_t srcp) { - return find_first_bit(srcp->bits, NR_CPUS); + return find_first_bit(srcp->bits, nr_cpu_ids); ...

Here's one(*) proposal for a new cpumask interface API in a patch that's compilable. Obviously with a change of this magnitude, a large number of files are affected. I tried to group them into functional changes, but there are a lot of "clean up" types of patches, so these are grouped in the second half by sections. Hopefully this minimizes the interdependencies between patches. [* - Rusty has an alternative approach that he'll be submitting shortly.] The patches in this patchset ...

There currently doesn't exist a labeling type that is adequate for use with labeled NFS. Since NFS doesn't really support xattrs we can't use the use xattr labeling behavior. For this we developed a new labeling type. The native labeling type is used solely by NFS to ensure NFS inodes are labeled at runtime by the NFS code instead of relying on the SELinux security server on the client end. Signed-off-by: Matthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: David P. Quigley ...

This factors out the part of the vfs_setxattr function that performs the setting of the xattr and its notification. This is needed so the SELinux implementation of inode_setsecctx can handle the setting of it's xattr while maintaining the proper separation of layers. Signed-off-by: Matthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov> --- fs/xattr.c | 55 +++++++++++++++++++++++++++++++++++++----------- include/linux/xattr.h | 1 + ...

This patch adds two new text options to to the NFS mount options to specify security labeling. It also sends certain LSM related mount options into the module for handling. Signed-off-by: Matthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov> --- fs/nfs/super.c | 9 +++++++++ include/linux/nfs4_mount.h | 6 +++++- security/selinux/hooks.c | 2 +- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/fs/nfs/super.c ...

I sent this patchset out just before LPC so I think it might have been overlooked by some people. I am resending the patchset with some corrections based on comments by Casey and Steve in hopes that it gets more attention this time. It has been six months since the last time we submitted a patch set to the mailing list for review. In this time we have fixed almost all of the issues that people have had with the last patch set and have added a new feature to allow for process labels to be ...

linux-2.6-tip. YH --

The allocator protects it freelists using zone->lock (as we can see in rmqueue_bulk), so anything which manipulates those should also be using that lock. move_freepages() is scanning the cmap and picking up free pages directly off the free lists, it is expecting those lists to be stable; it would appear to need zone->lock. It does look like setup_per_zone_pages_min() is holding the wrong thing at first look. -apw --

Hi, One thing worries me, there are bazillion of different IR protocols, but in-kernel decode support will mean that only handful of known protocols will work. Suppose I take an old remote which has some unknown protocol. I want to be able to teach the system to listen to it. But how this can be done if protocols are hard coded? I think that it would be much better to pass raw ir codes to userspace, and make it deal with bazillion protocols, and you can always make it auto learn too, and ...

Second pass at implementing evdev support for IR. The goal of in-kernel IR is to integrate IR events into the evdev input event queue and maintain ordering of events from all input devices. Note that user space IR device drivers can use the existing support in evdev to inject events into the input queue. Send and receive are implemented. Received IR messages are decoded and sent to user space as input messages. Send is done via an IOCTL on the input device. Two drivers are supplied. mceusb2 ...

Received IR messages generate event in the input queue. IR messages are sent using an input IOCTL. Jon Smirl <jonsmirl@gmail.com> --- drivers/input/Kconfig | 2 drivers/input/Makefile | 3 drivers/input/evdev.c | 55 +++++ drivers/input/input.c | 4 drivers/input/ir-core.c | 523 +++++++++++++++++++++++++++++++++++++++++++++ drivers/input/ir/Kconfig | 14 + drivers/input/ir/Makefile | 5 include/linux/input.h | 70 ++++++ 8 files changed, 675 ...

USB device commonly found on Microsoft Media Center boxes. Hardware can send and recieve at all common IR frequencies - 36K, 38K, 40K, 56K --- drivers/input/ir/Kconfig | 6 drivers/input/ir/Makefile | 1 drivers/input/ir/ir-mceusb2.c | 729 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 736 insertions(+), 0 deletions(-) create mode 100644 drivers/input/ir/ir-mceusb2.c diff --git a/drivers/input/ir/Kconfig b/drivers/input/ir/Kconfig index b80ab31..29657d0 ...

Add pci_resource_enabled() to determine whether a PCI BAR is enabled. Sometimes firmware leaves PCI BARs unconfigured, and this interface is a way for the OS to identify that situation. This is based on section 3.5 of the PCI Firmware spec, which says: Since not all devices may be configured prior to the operating system handoff, the operating system needs to know whether a specific BAR register has been configured by firmware. The operating system makes the determination by ...

These two patches address this 2.6.26 regression, so they should go in before 2.6.27: http://bugzilla.kernel.org/show_bug.cgi?id=11550 This PNP/PCI resource conflict area has been a trouble spot in the past: http://thread.gmane.org/gmane.linux.acpi.devel/27312 https://bugzilla.redhat.com/show_bug.cgi?id=280641 https://bugzilla.redhat.com/show_bug.cgi?id=313491 It would be great if Matthew, Avuton, Karl, and Willem could test these patches to make sure they don't re-introduce ...

I really don't think this is the right approach. Maybe the PCI device has been turned off, but the *resource* may still be valid. Wouldn't it be much better to just check whether the resource is inserted in the resource tree or not? Quite frankly, it looks like your change will basically cause us to look over *every* system PnP resource, and for each of them, it will look at *every* PCI device, and for each PCI device it will look at *every* BAR, and for each BAR it finds it ...

Hi Jens, I hope the previous RFC patch(*) would be no problem, since I haven't gotten any negative comment. (*) http://lkml.org/lkml/2008/9/25/262 So could you take this patch for 2.6.28 additionally? This patch adds a new interface for request stacking drivers. There should be no regression risk. This patch was created on top of the commit below of for-2.6.28. --------------------------------------------------------------------- commit ...

Just three. One is to prevent an I/O hang when we get an error on a split request (affects USB devices with the last sector bug). One is to defer enabling qla2xxx interrupts until the device is fully initialised (fixes intermittent oops on NULL deref in the driver) and one is to make the qlogicpti fill its continuation segments correctly (fixes data corruption on various sun systems) The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git The ...

I believe I found some sort of bottleneck with mounted networked file systems over 10Gig Ethernet. I've posted a question to linux-net with zero response since Friday. http://www.uwsg.indiana.edu/hypermail/linux/net/0809.3/0013.html Could a few of you folks here take a look at this and tell me what you think is the issue? -- Jason Czerak --

Dear all, my macbook pro1,1 works rock solid with -rc7 when it is freshly booted. However as soon as I perform a suspend to ram + wakeup cycle, it might freeze in the middle of some operation (e.g. backup or updatedb etc). This is now with all the drivers being open source (xorg-ati, ath5k) but exactly what I was observing before when only the closed source drivers were available (so this is not a regression but a long standing bug > 1 year now). Is anyone else observing this or has an ...

[Empty message]

This patch tries to make page->mapping to be NULL before mem_cgroup_uncharge_cache_page() is called. "page->mapping == NULL" is a good check for "whether the page is still radix-tree or not". This patch also adds BUG_ON() to mem_cgroup_uncharge_cache_page(); Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> mm/filemap.c | 2 +- mm/memcontrol.c | 1 + mm/migrate.c | 9 +++++++-- 3 files changed, 9 insertions(+), 3 deletions(-) Index: ...

Oh, thanks. I'll post fixed one, tomorrow. Thanks, --

Reviewed-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> I'll test with all the patches applied tonight. Thanks, --

There are not-on-LRU pages which can be mapped and they are not worth to be accounted. (becasue we can't shrink them and need dirty codes to handle specical case) We'd like to make use of usual objrmap/radix-tree's protcol and don't want to account out-of-vm's control pages. When special_mapping_fault() is called, page->mapping is tend to be NULL and it's charged as Anonymous page. insert_page() also handles some special pages from drivers. This patch is for avoiding to account special ...

At what point is it cheaper to pass items as args rather than recalculating them? If reducing the number of args is desirable, what about removing the "this_cpu" and "prev_cpu" args and recalculating them in wake_affine()? Chris --

If you start with the real-time kernel linux-2.6.26.5-rt9 and configure it to disable CONFIG_PREEMPT_RT, for example CONFIG_PREEMPT_DESKTOP=y # CONFIG_PREEMPT_RT is not set you will get the following compile error on 32-bit i386. (actually, this will happen on any platform that doesn't use CONFIG_RWSEM_GENERIC_SPINLOCK) In file included from include/linux/notifier.h:14, from include/linux/memory_hotplug.h:6, from include/linux/mmzone.h:560, ...

Create marker_synchronize_unregister() which must be called before the end of exit() to make sure every probe callers have exited the non preemptible section and thus are not executing the probe code anymore. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: Rusty Russell <rusty@rustcorp.com.au> CC: akpm@linux-foundation.org CC: "Frank Ch. Eigler" <fche@redhat.com> --- include/linux/marker.h | 7 +++++++ 1 file changed, 7 ...

(probably already in -tip) Add rcu_read_lock_sched() and rcu_read_unlock_sched() to rcupdate.h to match the recently added write-side call_rcu_sched() and rcu_barrier_sched(). They also match the no-so-recently-added synchronize_sched(). It will help following matching use of the update/read lock primitives. Those new read lock will replace preempt_disable()/enable() used in pair with RCU-classic synchronization. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: ...

Use the new rcu_read_lock_sched/unlock_sched() in marker code around the call site instead of preempt_disable/enable(). It helps reviewing the code more easily. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: Peter Zijlstra <peterz@infradead.org> CC: Paul E McKenney <paulmck@linux.vnet.ibm.com> CC: akpm@linux-foundation.org --- kernel/marker.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) Index: ...

Looks good. --

applied to tip/tracing/markers, thanks! Mathieu, i've reactivated tip/tracing/markers for linux-next integration, it propagates into auto-ftrace-next. Tracepoints are what we use in the scheduler/etc. in tip/master, but until there's marker use elsewhere there's no reason not to apply fix patches. Ingo --

We need a marker_synchronize_unregister() before the end of exit() to make sure every probe callers have exited the non preemptible section and thus are not executing the probe code anymore. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Ingo Molnar <mingo@elte.hu> CC: Jeremy Kerr <jk@ozlabs.org> CC: linuxppc-dev@ozlabs.org CC: Christoph Hellwig <hch@infradead.org> --- arch/powerpc/platforms/cell/spufs/sputrace.c | 1 + 1 file changed, 1 insertion(+) Index: ...

Looks good, but I don't understand this code. Krishna, I'd suggest you to send each change in a separate patch with the maintainer cc'ed. And please don't forget to mention that update() != cancel() + queue(). Otherwise maintainer can miss this fact. Oleg. --

Please note that the above is the open-coded queue_delayed_work(). I'd suggest to just start with if (queue_delayed_work(...)) return 1; ... slow path ... I can't understand why do you want to optimize this very unlikely case. Afaics, it can only improve the benchmark, when we are doing queue_update_delayed_work() in a loop with the same timeout, no? But more importantly, this is not right. We can not trust timer->expires. For example, let's suppose we are ...

I still use the ES56-PI modem driver @ http://tx.technion.ac.il/~raindel. It has a 2.6 port up to 2.6.24, but it's not more current than that due to serial/tty interface changes. And there's a challenge that it uses a binary blob. :-( Best case would be to see if the vendor could open up like Atheros (Thanks! Yea!) did. If not, I wonder if the blob could be minimalized to the bare modem functions and the serial interfaces be brought out into open code. Alan --

Hi Bart, here are some trivial enhancements to ide-cd which resulted from the debugging sessions lately. drivers/ide/ide-cd.c | 44 ++++++++++++++++++++++++++------------------ 1 files changed, 26 insertions(+), 18 deletions(-) --

Signed-off-by: Borislav Petkov <petkovbb@gmail.com> --- drivers/ide/ide-cd.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c index 9ffce7f..e41b94d 100644 --- a/drivers/ide/ide-cd.c +++ b/drivers/ide/ide-cd.c @@ -1784,7 +1784,7 @@ static int ide_cdrom_probe_capabilities(ide_drive_t *drive) if ((cdi->mask & CDC_DVD_R) == 0 || (cdi->mask & CDC_DVD_RAM) == 0) printk(KERN_CONT " DVD%s%s", (cdi->mask & CDC_DVD_R) ? ...

I have here driver that can be built for two different types of hardware from basically the same sources (this is port of old Agere drivers for Hermes-I/Hermes-II chipsets). Build differs only in one define -DHERMES2 and single file with different firmware. Unfortunately "if HII" are spread over sources which makes splitting of sources rather questionable. What is the best way (from kbuild POV) to build two modules - for H-I and H-II - from the same set of source files? TIA -andrey

Remove vmap of relay buffers. Also removes relay_reserve and switches callers over to relay_write. Signed-off-by: Tom Zanussi <zanussi@comcast.net> --- block/blktrace.c | 8 ++++- include/linux/relay.h | 47 +++++++++--------------------------- kernel/relay.c | 63 +++++++++++++++++++++--------------------------- 3 files changed, 46 insertions(+), 72 deletions(-) diff --git a/block/blktrace.c b/block/blktrace.c index 84a9cb4..f60665e 100644 --- ...

Replace subbuf_start and notify_consumers callbacks with new_subbuf. The subbuf_start callback was too confusing and there's no reason to have a separate callback to notify consumers; this patch combines them both and simplifies the interface. It's only called when there actually has been a switch to a new sub-buffer and there's now no return value saying whether the buffer is full or not - that's now handled internally. Keeping a count of dropped events is also now done internally, so the ...

Remove padding-related code from relay_read()/relay_splice_read() et al. Because we no longer write padding, we no longer have to read it or account for it anywhere else, greatly simplifying the related code. Signed-off-by: Tom Zanussi <zanussi@comcast.net> --- kernel/relay.c | 149 ++++++++------------------------------------------------ 1 files changed, 20 insertions(+), 129 deletions(-) diff --git a/kernel/relay.c b/kernel/relay.c index d382528..b55466d 100644 --- ...

Map the first sub-buffer at the end of the buffer, for temporary convenience. Make relay buffers 'circular' for writing by mapping the first subbuf at end of last subbuf. This is so we can do writes across last subbuf boundary without adding special write logic. This is a temporary state of affairs and it all goes away in a future patch, but it's here now so things will still work. Signed-off-by: Tom Zanussi <zanussi@comcast.net> --- kernel/relay.c | 26 +++++++++++++++----------- 1 ...

Add channel flags to relay, remove global callback param. relay should probably have had a flags param from the beginning; it wasn't originally added because it wasn't originally needed - it probably would have helped avoided some of the callback contortions that were added due to a lack of flags. This adds them and does a small amount of low-hanging cleanup, and is also in preparation for some new flags in future patches. Signed-off-by: Tom Zanussi <zanussi@comcast.net> --- ...

Clean up relay_switch_subbuf() and make waking up consumers optional. Over time, relay_switch_subbuf() has accumulated some cruft - this patch cleans it up and at the same time makes available some of it available as common functions that any subbuf-switch implementor would need (this is partially in preparation for the next patch, which makes the subbuf-switch function completely replaceable). It also removes the hard-coded reader wakeup and moves it into a replaceable callback called ...

[Empty message]

f072181e6403b0fe2e2aa800a005497b748fd284 simply dropped the warnings, but it does a little more than that, it also marks the current .config as needed saving, so add this back. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Index: linux-2.6/scripts/kconfig/confdata.c =================================================================== --- linux-2.6.orig/scripts/kconfig/confdata.c +++ linux-2.6/scripts/kconfig/confdata.c @@ -222,8 +222,10 @@ load: continue; if (def == ...

Hi, I've sent these changes already some time ago, but I haven't heard anything back, but they really should go into 2.6.27. I only dropped the kbuild parts, silentoldconfig is now a little misnamed, as oldconfig is now silent as well, but it still has a special role within kbuild. The naming can still be changed later. bye, Roman -- --

This is the same like pci_iomap(pdev, number, 0), no? Greetings, Eike

On Mon, 29 Sep 2008 18:45:19 +0100 pci_iomap() assumes you're using the rest of the iomap API as well! most drivers do not do that. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

I haven't verified it yet, but it looks like a good catch. Let me double check this on my test machine. Weird that we never noticed this before since I have been using the btusb driver for a very long time now. Regards Marcel --

There's a commit in the latest git which looks like it will solve the btusb suspend/resume issues: 5fbcd260.. ("[Bluetooth] Fix USB disconnect handling of btusb driver"). Marcel / linux-bluetooth, I think this double free is a separate issue with the error handling, and the following patch should fix it. --- From: Rabin Vincent <rabin@rab.in> Subject: [PATCH] btusb, bpa10x: fix double frees on error paths Justin Mattock reported this double free in btusb: BUG kmalloc-16: Object ...

Thanks Matthew. For the second part of the quirk the device name is incorrect. It should be r5c832 instead of rl5c832 and the DECLAREs also have the wrong device. I think it would probably be good to add a printk for an info or debug message saying that the proprietary controller has been disabled. After fixing that it compiles correctly and does improve things a lot, but there are still remaining issues. I suspect these are probably unrelated to the proprietary controller though. During ...

applied to tip/x86/core, thanks Krzysztof! (I left out the UML defconfig update - that can be done later and it doesnt hurt anyway.) Ingo --

got the report below - config attached. This is probably bitfield initialization related. tip-072062d5. Ingo -----------------> kmemcheck: Caught 32-bit read from uninitialized memory (f6038ec0) 0000000000000000d0e86bc0d0fa6bc070446cc060fa6bc0205c71c0103772c0 u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u ^ Pid: 0, comm: swapper Tainted: G W (2.6.27-rc7-tip-00980-g072062d-dirty #37099) System Product Name EIP: 0060:[<c06beba6>] EFLAGS: 00010282 CPU: 0 EIP is ...

[Empty message]

Ingo --

a kernel log line beginning with: INFO: WARNING: BUG: would be noticed. (That pattern has to be at the beginning of the line. Otherwise we'd match on things like 'DEBUG: ' - such printouts exist) Ingo --

FYI, i've reactivated kmemcheck on one of the -tip auto-test boxes earlier today and it's looking good so far - for example a 32-bit allyesconfig-ish config booted in just fine with kmemcheck enabled. Also, the box is very usable interactively - while previous one could always tell whether there's kmemcheck active. [ only one CPU is active, but we knew that. We've still got this test-commit: 21d01a4: x86: add functions for duplicating page tables it's not in tip/master ...

You're assuming that your metrics of people downloading your kernel debugger is an accurate way of measuring how many people are You may find these research reports interesting: http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php http://www.linux-foundation.org/publications/IDC_Workloads.pdf The former shows that the development rate is if anything, increasing based on analyzing the rate that changes are flowing into the Linus's git tree --- something which I think ...

Dear sir, Thank you for your help. -- www.mcuos.com Best Regarts, Vincen --

> These are provided by the linker script. Ok, I took a look at both vmlinux_32.lds.S and uml.lds.S (I'm assuming these are the linker scripts). I also took a look at vmlinux. I didn't realize at first that vmlinux actually has some symbols in it. I linked vmlinux to my programs using gcc and it compiled, but I got a segmentation fault when I ran it. What is the appropriate binary format to use to output the kernel binary so it won't segfault in userspace? Ideally, I would like to add ...

Please continue to track this bug. --

I forgot to mention one important detail. The "head" index will stay on the page frame. That way we do not need to figure out which head_page we are on. We grab the head_page, we atomically (local_inc_return) the head pointer on that page. If the return value is still on the page, we succeeded. We can also increment a value on this page frame that will prevent recording if we somehow overflowed the buffer before relinquishing the stack. That is reserve_event() IRQ-> ...

Well, this is my answer to Steven's "this is too complex" comments, which I suspect is really a "this is too implement to implement". Sorry Steven, but you do not actually propose anything to address my concerns, which are : I want to export this data to userspace without tricky dependencies on the compiler ABI. I also don't want to be limited in locking infrastructure implementation. Those are the kind of concerns that are much easier to address in a layered and modular implementation. If we ...

The only compiler dependant thing in there is the bitfield, which could be recoded using regular bitops. You can do stop: cpu_buffer->stop=1; smp_wmb(); sched_sync(); start: smp_wmb(); cpu_buffer->stop=0; write: if (unlikely(smp_rmb(), cpu_buffer->stop))) { return -EBUSY; or while (cpu_buffer->stop) cpu_relax(); } Sure, its probably possible to rework the merge-iterator to use consume, but that would require it having storage for 1 event, which might be ...

Remember, I plan on supporting two modes. An iterator mode and a consumer producer mode. Do you have an iterator mode? That's what most of the ftrace tools use. The iterator mode will disable writing and use the "peek" mode. The consumer mode will not, and have its own ways to read. As is right I do that too. Yes I have duplicate info. But I still like the robustness False. It is a "special" event that can actually be in 4 bytes. Which is what would be wasted anyway. Lenght ...

I now have both. But I think userspace can now easily see when there I wanted to push the event ids out of the ring buffer logic. Only a few internal ones are used. Otherwise, we'll have one hell of a bit enum Well, you need to record wraps. Probably more often then you record delta As Linus said, anything bigger than a page should be outside this buffer. All the buffer would then need is a pointer to the data. Then the tracer -- Steve --

Here is a patch (on top of the others) doing that. thanks, -serge Subject: [PATCH] capabilities: remove target argument from capset_check and set Since it is no longer possible to set capabilities on another task, remove the 'target' option from capset_set and capset_check. Since the userspace API shouldn't change, we maintain 'pid' as a valid option to the actual sys_capset(), continuing to return -EPERM when pid is not current's pid. Signed-off-by: Serge E. Hallyn ...

Nice idea. Problem with that is that approach is that we don't have full control here. It probably isn't that a hard to have vmware, xen and kvm agree here, given vmware proposes this and for xen+kvm one can send patches. But even that you can't take for granted, see the discussion of the "tsc-may-change-on-migration" problem. The real big problem are other closed-source hypervisors (VirtualPC / Hyper-V / Parallels / ...). How can we be sure they don't define that The fudamental issue ...

Besides that, nobody stops a Hypervisor to offer valid and usefull DMI and ACPI tables in the first place. I dont see a need to tunnel those through CPUID. Gruss Bernd --

This was discussed at the virtualization mini summit (can't remember who brought it up). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

If you can't mix and match, there is no point, since very likely all Yes, see my previous "half-baked" sketch. -hpa --

Yes. It would be nice to have "Hypervisor vendor id" somewhere in /sys or /proc. It seems that userspace is already hungry for that information: http://article.gmane.org/gmane.linux.utilities.util-linux-ng/1788 Karel -- Karel Zak <kzak@redhat.com> --

Aren't we overthinking / overdesigning this a bit? It's not rocket science. We'd like to have a leaf set aside for TSC frequency, and maybe another leaf in the future. We think other vendors might find a static clock frequency leaf to be useful, so if that happens to be the case, feel free to re-use the leaf. We don't expect to see lots of proliferation of CPU leaves at all, in fact, we'd be flummoxed to propose more than one right now. So basically a nicely written comment section ...

Unless there is a central authority assigning these, "we" can do all we want, enough people will not pay attention. Basically, there needs to be a standards document that describes the architecture, *and* needs to either have universal buy-in with all the vendors or imposed by an authority with enough clout to do so (Intel might.) -hpa --

Likewise, I think this should be HYPERVISOR_VMWARE_TIMING_LEAF. Or we need some way to (a) standardize hypervisor cpuid leafes (or parts of it) and (b) handle sparsely filled cpuid info. Right now both kvm and xen use the first one or two leafes (after info), but in incompatible ways, so for these the signature *must* be checked before using the info found there. 0x40000010 doesn't clash with anything as far I know, so we could attempt to make that standard accross ...

I don't think this is a realistic point of view, especically given who we're dealing with in the closed-source world. Without any kind of tagging of the information, it's realistically futile. Intel/AMD haven't helped any by reserving a space which is entirely too small. -hpa --

Can this interface be used to pass variable sized data from a hypervisor to a gust? ACPI or DMI tables for instance. -- Gleb. --

On Mon, 29 Sep 2008 01:26:43 -0600 we should detect this and DTRT inside the implementation, not in the drivers. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

*nod* FTR, I like this interface better since most drivers use ioremap() instead Should the comment be deleted? It made sense (sort of) for the orginal code and maybe including a comment like it in the new ioremap_pcibar() would be good. Alternatively, the ioremap_pcibar() code needs to check for Is there any easy way to tell if the device driver should be using uncached mappings vs cacheable mappings? (Just from looking at the source code) This patch changes that behavior of the ...

Hi. It's not particularly on-topic here, so just a short note: #ath9k should not be invite-only (but I will check again). It forwards to #madwifi, which is used for discussion about MadWifi, ath5k and ath9k. Bye, Mike --

After thinking about this, if a new runtime call was added to efi_runtime_services_t, then the existing efi_call_virt<n> could be used. This would remove the need to create uv_systab. I'll post a patch shortly. -- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc rja@sgi.com --

good. Frederic, please just resubmit all fixes you have against tip/master, with Pekka's Acked-by added. You can submit Pekka's patch as well, so that it's a coherent series. The customary way for that is to add in a From line as the first line of the changelog: From: Pekka Paalanen <pq@iki.fi> and add your signoff to the end of the changelog. This way Git will show Pekka as the author and the path of the patch is well understood. Thanks, Ingo --

Ok I will test it this evening. --

Tested! And, no problem as far as I can see :) So I'm going to send the new patchset. Thanks. --

On Mon, 29 Sep 2008 11:11:15 +0200 Is print_line_t necessary? Does it have to return any other information than "this entry was handled somehow" vs. "this entry must be handled later"? Currently it's just a flag to say "please flush and retry". -- Pekka Paalanen http://www.iki.fi/pq/ --

We definitely have a race between d_kill setting dentry->d_inode = NULL and proc_sys_compare reading d_inode. We don't generate negative dentries for /proc/sys. In dput atomic_dec_and_lock takes the lock before setting the count to 0. So there is no race there. Testing for d_unhashed and getting us out of rcu limbo before calling into the filesystem methods makes the reasoning a lot clearer. Looks good to me. Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> --

Just for kicks, I did the read part of the fast bdev interface as well. As with the write, it's totally untested (apart from compiled). Just in case anyone is curious... I plan to do a bit of testing on this this week. IMHO, this interface totally rocks. It's really async like splice was intended, and it's fast too. I may have to look into some generic IO mechanism to unify them all, O_DIRECT/page cache/splice. Famous last words, I'm sure. diff --git a/fs/block_dev.c ...

Verified, this is something completely separate, started triggering at the very same time I have fixed the 09-e1000e-allow-bad-checksum.patch only by coincidence. Please disregard this. -- Jiri Kosina SUSE Labs --

fixed Karsten's email, apologies for the bounces. Yep, I think you're right. I'm almost done prepping our current patch series, I'll include that fix. Please let me know if your test shows it fixes it. --

Yes, it fixed the hang. It crashed later though BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [<ffffffffa045211b>] inet6_net_init+0x98/0xf2 [ipv6] PGD 39d15067 PUD 39d14067 PMD 0 Oops: 0000 [1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0000:16:00.0/local_cpus which is probably related I guess. -- Jiri Kosina SUSE Labs --

[ This is the final version of this patch. From now on, I will be sending changes on top of this patch. Changes since v9: All suggestions from Ingo Molnar. - Changed comment of enum to DocBook style. - Replaced the RB_TYPE_ enums with RINGBUF_TYPE_ prefixes to avoid name collision with rbtree. Note, I did not use the TB_ extension because I envision a "trace_buffer" layer on top of this layer in the future. - Moved ring_buffer_event_{length,data} into the ...

OK, I did a quick survey of what others did in include/linux to handle multi line comments for enums. I ignored the single line comments since that is pretty standard. Here's what I found: Those that do: enum myenum { ENUM_PING_PONG, /* Bounce a ball back and forth till you have a winner. */ ENUM_HONEY_CONE, /* Soft and sweet a yummy for the tummy. ...

If you enable that option, you have to have the specific USB device plugged into your system in order for any process to run as root (like init). So, odds are you don't have this specific device, so either specify a different device id, or don't build it into your kernel :) thanks, greg k-h --

Hi, On Friday 26 September 2008, you wrote in "Re: bad DMAR interaction with=20 Could not reproduce so far - it is rather hard working on the machine with= =20 DMAR enabled because I get 1-5s lockups all the time like described above... Andres

Hi, On Saturday 27 September 2008, Tomas Winkler wrote in "Re: bad DMAR=20 Would it help to test on 32bit? I have some dissk with 32bit system install= ed=20 lying around somewhere... Any other patches to try? Andres

Hi Chirag FYI I am looking at this now. I suspect a dequeue_pushable_task() probably found its way inside a conditional for GROUP_SCHED and inadventently gets compiled away if you disable the feature.=20 Investigating now..

Ok, I figured out this part. I needed a newer version of the .rpm from a different repo. However, both async_handler and sbrk_mutex seem to segfault for me. Hmm --- ghaskins@test:~> uname -a Linux test 2.6.26.5-rt9-rt #1 SMP PREEMPT RT Mon Sep 29 14:26:45 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux test:/home/ghaskins # /usr/lib64/ltp/testcases/realtime/func/async_handler/async_handler ----------------------------------- Asynchronous Event Handling ...

On Mon, 29 Sep 2008 10:56:47 +0200 I'm not sure we are talking about the same thing. Surely, I and Joerg are talking different things. GART driver doesn't need to use the IOMMU hardware at all times. GART does a virtual mapping only when necessary (a device needs to handle an address that it can't access to). But as I wrote, if you use iommu=force, GART driver always use the IOMMU hardware. Other x86 IOMMU drivers always use the IOMMU hardware. Except for Intel VT-D, they manage free ...

Doesn't look like this patch is doing anything with respect to "hpet compiling". It is just adding some debug prints. I guess we need a better patch description. Thanks, Doesn't look like the patch below is doing anything with respect to "hpet compiling". It is just adding some debug prints. I guess we need a different patch description. Thanks, --

Not probably. You will find them that way. It is illegal for anyone to redistribute PCISIG copyrighted documents. That hasn't stopped it from happening. I've pointed this out in the past (and got a polite "please don't point that out again publicly"). +1 --

On Mon, 29 Sep 2008 08:32:07 +0530 I'll add -EBUSY behavior to force_empty. I'm now adding(merging) code to move_account.patch for supporing force_empty. Thanks. no major changes in my current stack from already posted one. Thanks, --

I've picked it up, I need to check a thing or two and I'll send patches for .27 to Linus tomorrow (Paulus is on vacation for a week). With a bit of luck he won't have closed .27 before that :-) Cheers Ben. --

Just don't expect the GPIO framework to address the problem of how to configure one of those pins for a non-GPIO function. Such pinmux problems deserve different programming interfaces. ... after I come up with a happy fix for the locking goofs; those new methods may not be called under spinlock protection. - Dave --

Nope. That disables preemption which is against the purpose of this That's to ensure that __x.hi is always (re)read before __x.lo, and not factorized out of a possible outer loop if gcc felt like doing such an optimization. However I didn't want other unrelated variables to be affected by an undiscriminating barrier(). But that's a weak argument as I suspect in most case inserting a barrier() between the 2 reads will But again, the original code had no such restriction. It works ...

Tejun Heo wrote: > Simon Holm Th

Do you mean that we should move DAC code to all the caller of vfs_* ? If we move DAC code to the caller of vfs_*(), we need not to introduce seucrity_path_*() because we can move security_inode_*() together. Furthermore, each filesystem must perform DAC by itself. It There are two approaches to perform DAC before MAC using security_path_*(). One is cloning DAC functions in security/security.c . The other is modifying fs/namei.c to make DAC functions visible to security/security.c . Which ...

>>>>> "Neil" == Neil Brown <neilb@suse.de> writes: Neil> But what if we subsequently add a different device to that array Neil> which uses a different protection format. Would we be able to Neil> tell the filesystem that integrity protection isn't available Neil> any more? Or can we detect if the filesystem is using integrity Neil> protection, and reject the new device if it doesn't match? Generally the filesystem will look at the block device's integrity profile every time it prepares an ...

Ok frame pointers are always a performance disasters on some CPUs. Perhaps they should be just unconditionally disabled for vsyscall.c and the vdso -Andi -- ak@linux.intel.com --

On Fri, Sep 26, 2008 at 00:35:08 +0200, Rafael J. Wysocki wrote: Yes, with this patch wakeup using the keyboard works as it did with 2.6.26. Thanks and regards, Tino --

We could be, if we add a check to the register function that verifies it isn't being called after DMAs have started. Something like: in register: if (dma_started) yell loudly before PCI device initialization and after IOMMU initialization: dma_started = true Cheers, Muli -- The First Workshop on I/O Virtualization (WIOV '08) Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/ xxx SYSTOR 2009---The Israeli Experimental Systems ...

On Mon, 29 Sep 2008 11:36:52 +0200 Nobody cares about the performance of dma_alloc_coherent. Only the performance of map_single/map_sg matters. I'm not sure how expensive the hypercalls are, but they are more expensive than bounce buffering coping lots of data for every I/Os? --

The bounce buffering is needed for map_single/map_sg allocations. For dma_alloc_coherent we can directly allocate from that range. The performance loss of the bounce buffering may be lower than the hypercalls we need as the alternative (we need hypercalls for map, unmap and sync). Joerg --

On Sun, 28 Sep 2008 20:49:26 +0200 I know that. As I wrote in the previous mail, we already solved that problem with per-device-dma-ops. My question is what unsolved problems this patchset can fix? This patchset is named "stackable dma_ops" but it's different from what we discussed as "stackable dma_ops". This patchset provides IOMMUs a generic mechanism to set up "stackable dma_ops". But this patchset doesn't solve the problem that a hardware IOMMU does not handle all devices (it was ...

On Mon, 29 Sep 2008 15:26:47 +0200 Basically, I'm not against this patchset. It simplify Calgary and AMD IOMMUs code to set up per-device-dma-ops (though it makes dma_ops a bit complicated). But it doesn't solve any problems including the paravirtualized device passthrough. When I wrote per-device-dma-ops, I expected that KVM people want more changes (such as stackable dma_ops) to dma_ops for the paravirtualized device passthrough. I'd like to hear what they want first. --

Can you post full kernel log including the boot messages and the error messages? Also, please attach the output of hdparm -I on the drive which fails the smart command. (cc'ing Bruce, hi!) Bruce, this is the second report I see about drive timing out SMART ENABLE OPERATIONS. Does anything ring a bell? Thanks. -- tejun --

Yes please. Manually searching MAINTAINERS is boring and hard... 'Is it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND SYSTEM'? ... plus if you want subsystem maintainer, search tends to give you about 179 individual driver maintainers, first. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

hm, that's weird indeed. You could try to trace the full battery readout itself, via a script like this: cat /debug/tracing/trace > /dev/null # drain trace cat /proc/acpi/whatever cat /debug/tracing/trace > trace.txt this way you should be seeing a full trace of the whole thing. (with the 'ftrace' tracer plugin set in current_tracer) then, assuming the trace.txt is complete, you can check where it reschedules and why. Search for 'schedule' calls. Compare the debug ...

Just enabling it in the .config is enough to trigger the behaviour change. I'm not explicitly activating any traces. Chris --

This is possible but I wonder if this is really the way we should go. It looks like you tried implementing another ioctl-like interface on the cgroup control file interface. You can do anything you want with this interface though. I guess there should be at least some rules to implement this kind of ioctl-like interface if they don't want to enhance the cgroup interface, Thank you, Hirokazu Takahashi. --

Sorry about the delay. I've been traveling for quite some time. The bug is being tracked via the following bugzilla bug and patch has been posted. http://bugzilla.kernel.org/show_bug.cgi?id=11615 Thanks. -- tejun --

But why would the filesystem every unfreeze itself? That defeats the whole point of freezing it. --

Eric Sandeen wrote: > Christoph Hellwig wrote: >> But why would the filesystem every unfreeze itself? That defeats the >> whole point of freezing it. > > I agree. Was just trying to clarify the above point. > > But there have been what, 12 submissions now, with the unfreeze timeout > in place so it's a persistent theme ;) > > Perhaps a demonstration of just how easy (or not easy) it is to deadlock > a filesystem by freezing the root might be in order, at least. > > And even ...

The suggestion was that *UN*freeze would return ETIMEDOUT if the filesystem had already unfrozen itself, I think. That way you know that the snapshot you just took is worthless, at least. I'm still not really sold on the timeout, but I think the above was the intent. -Eric --

From: Rafael J. Wysocki <rjw@sisk.pl> SATA AHCI: Blacklist system that spins off disks during ACPI power off Some notebooks from HP have the problem that their BIOSes attempt to spin down hard drives before entering ACPI system states S4 and S5. This leads to a yo-yo effect during system power-off shutdown and the last phase of hibernation when the disk is first spun down by the kernel and then almost immediately turned on and off by the BIOS. This, in turn, may result in shortening the ...

Here you go (sorry for the delay). I have also split the SATA changes so that the driver patches are droppable individually if there are problems with them (not anticipated). Thanks, Rafael --- SATA: Blacklist systems that spin off disks during ACPI power off Some notebooks from HP have the problem that their BIOSes attempt to spin down hard drives before entering ACPI system states S4 and S5. This leads to a yo-yo effect during system power-off shutdown and the last phase of ...

From: Rafael J. Wysocki <rjw@sisk.pl> Hibernation: Introduce new system state for the last phase of hibernation Replace unused SYSTEM_SUSPEND_DISK with a new system_state value SYSTEM_HIBERNATE_ENTER that can be used by device drivers to check if the system is in the last phase of hibernation. In particular, some SATA drivers are going to use it for blacklisting systems in which the disks should not be spun down during the last phase of hibernation (the BIOS will do that ...

From: Rafael J. Wysocki <rjw@sisk.pl> SATA Sil: Blacklist system that spins off disks during ACPI power off Some notebooks from HP have the problem that their BIOSes attempt to spin down hard drives before entering ACPI system states S4 and S5. This leads to a yo-yo effect during system power-off shutdown and the last phase of hibernation when the disk is first spun down by the kernel and then almost immediately turned on and off by the BIOS. This, in turn, may result in shortening the disk's ...

I will, and the full "allyesconfig" does compile. And it's basically a benign change in that the functionality is still the same. I'm currently reordering it a bit to clean it up. Thanks, Mike --

Date: Mon, 29 Sep 2008 16:22:51 +0900 From: Tejun Heo <tj@kernel.org> Robert Krawitz wrote: > This is for a Dell Inspiron E1705/9400. I'm using a non-OEM disk (a > Hitachi 320 GB drive). > > Note that matching on "MP061" doesn't work -- it needs to be "MP061*" > due to the way dmidecode seems to return the data (with a bunch of > spaces after the tag). Hence I've attached the data rather than merely > > I've only had this thing a month or so and already ...