Fixed the warning by initializing 'rc' to zero. Signed-off-by: Steven Noonan <steven@uplinklabs.net> --- drivers/ide/ide-probe.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c index 994e410..e53c645 100644 --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -1492,7 +1492,7 @@ static struct device_attribute *ide_port_attrs[] = { static int ide_sysfs_register_port(ide_hwif_t *hwif) { - int i, ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/intel.c | 119 ++++++++++++++++++++++++++++++------------- 1 files changed, 83 insertions(+), 36 deletions(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index a669895..365a008 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -15,6 +15,11 @@ #include <asm/ds.h> #include <asm/bugs.h> +#ifdef CONFIG_X86_64 +#include <asm/topology.h> +#include ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/intel.c | 192 ++++++++++++++++++++++--------------------- 1 files changed, 98 insertions(+), 94 deletions(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 365a008..5f76bf1 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -63,15 +63,54 @@ int __cpuinit ppro_with_ram_bug(void) return 0; } +#ifdef CONFIG_X86_F00F_BUG +static void __cpuinit ...

A colleague has run into a problem. We assume it's a kernel issue. Here is the pertinent bug report data. [1.] One line summary of the problem: fstat(2) returns st_size == 0 for a FIFO that is known to have data in it. [2.] Full description of the problem/report: When using a FIFO, fstat(2) (and stat(2)) returns a 'struct stat' with the st_size field equal to zero, at a time when the FIFO is known to have data in it. Problem occurs with Linux 2.6.16 kernel (see more below), but does ...

I had always gotten strange wedges when hot plugging cpus on Niagara boxes via the hypervisor, and I think the following bug spotted by Paul McKenney finally nails it. Please pull, thanks a lot. The following changes since commit 4d084617fb0d025c42c242362d1f27d337e2d407: Paul E. McKenney (1): sparc64: Prevent sparc64 from invoking irq handlers on offline CPUs are available in the git repository at: master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git ...

On Tue, 9 Sep 2008 19:11:02 -0400 hm, OK, there may be newly-added code which will now break. Not a big The patch was wordwrapped - please fix that up before sending any more This is simpler, no? --- a/include/linux/sysfs.h~x86-sysfs-kill-owner-field-from-attribute-fix +++ a/include/linux/sysfs.h @@ -27,7 +27,7 @@ struct module; */ struct attribute { const char *name; -#if !defined(CONFIG_X86_64) && !defined(CONFIG_X86_32) +#ifndef CONFIG_X86 struct module *owner; ...

Would it be wrong to make it possible_cpu_mask? J --

On x86-64, the genapic implementations of target_cpus returns cpu_online_map. What if more cpus have yet to come online? Shouldn't it be cpu_possible_map? Though I'm probably confused. I don't really know what the intent of target_cpus and vector_allocation_domain is. Thanks, J --

Hi all, There will be no linux-next release for Sep 9 (as my body and brain are in two widely distant time zones) or Sep 10 (as I am travelling again). Hopefully normal releases will start again on Thursday (US west coast time). --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

bit is unsigned, so test before subtraction Signed-off-by: Roel Kluin <roel.kluin@gmail.com> --- diff --git a/arch/sh/kernel/cpu/irq/intc.c b/arch/sh/kernel/cpu/irq/intc.c index 8c70e20..94536d3 100644 --- a/arch/sh/kernel/cpu/irq/intc.c +++ b/arch/sh/kernel/cpu/irq/intc.c @@ -464,9 +464,10 @@ static unsigned int __init intc_prio_data(struct intc_desc *desc, } fn += (pr->reg_width >> 3) - 1; - bit = pr->reg_width - ((j + 1) * pr->field_width); - BUG_ON(bit < ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle stack segment exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index 572ea9f..e535324 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -640,7 +640,7 @@ DO_ERROR_INFO(6, SIGILL, "invalid ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle SIMD coprocessor exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index f696914..1ad7697 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -1142,6 +1142,8 @@ static void simd_math_error(void ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Only one use of the DO_TRAP macros remains. Expand that one and remove the macros now. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 66 ++++++++++---------------------------------- 1 files changed, 15 insertions(+), 51 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index 1ad7697..7047760 100644 --- a/arch/x86/kernel/traps_32.c +++ ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle exception 15 with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index c3b636e..ef934a2 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -1162,6 +1162,7 @@ void do_simd_coprocessor_error(struct pt_regs ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle general protection exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index e535324..c3b636e 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -652,6 +652,8 @@ do_general_protection(struct ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle overflow exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index 944641a..5d762a8 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -633,7 +633,7 @@ void do_##name(struct pt_regs *regs, long ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle machine check exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/entry_32.S | 2 +- arch/x86/kernel/traps_32.c | 11 ++++++++++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index 5a88585..c5fe01b 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -1019,7 ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle coprocessor error exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index ef934a2..733c0e3 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -1086,6 +1086,7 @@ void math_error(void __user *ip) ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle alignment check exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index 733c0e3..bc8b21d 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -641,7 +641,7 @@ DO_ERROR(9, SIGFPE, "coprocessor ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle invalid opcode exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index becfc84..5d8d057 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -635,7 +635,7 @@ void do_##name(struct pt_regs *regs, ...

From: Alexander van Heukelum <heukelum@fastmail.fm> The int3 exception was already takes as an interrupt and do_int3 does not fit in the new DO_ERROR macro. This patch just expands the DO_TRAP macro and rearranges the code a bit. No functional changes intended. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/traps_32.c ...

From: Alexander van Heukelum <heukelum@fastmail.fm> Handle bounds exception with interrupt initially off. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> --- arch/x86/kernel/traps_32.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c index 5d762a8..becfc84 100644 --- a/arch/x86/kernel/traps_32.c +++ b/arch/x86/kernel/traps_32.c @@ -634,7 +634,7 @@ void do_##name(struct pt_regs *regs, long ...

This patch is not tested --- fsl_msi_alloc_hwirqs() converts an int from bitmap_find_free_region() into an irq_hw_number_t, but this can be an -ENOMEM. This is tested in fsl_setup_msi_irqs(), but incorrectly: irq_hw_number_t is unsigned. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> --- diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c index 2c5187c..a2aa59a 100644 --- a/arch/powerpc/sysdev/fsl_msi.c +++ b/arch/powerpc/sysdev/fsl_msi.c @@ -67,7 +67,7 @@ static ...

On some hardware no TX done interrupts are generated, thus special 100Hz timer interrupt is required to handle this situation properly. Other device do not require that timer interrupt feature. Forcedeth has a DEV_NEED_TIMERIRQ flag to mark the broken devices. Unfortunately, nobody know the actual list of broken devices, so all device has this flag on. Other problem, this flag is not user visible, so the kernel recompilation is required to disable timer interrupts and test a device. This ...

What's the proprietary module that's tainting it? Ideally we'd like to see it reproduced on an untainted kernel, but depending on what it is, it may not matter. When you say you're not able to log in, is that because the keyboard is unresponsive? It appears to be affecting USB, so I'd be curious to know if you can ssh into the box, or log in with a PS/2 keyboard. Of course, some PS/2 ports are connected via USB under the hood, so the keyboard might not tell us much. -- Chris --

I've been noticing this message appear every "X" amount of boot's(maybe ten or so); [19.656768] irq 23: nobody cared (try booting with the "irqpoll" option) [19.666039] Pid: 0, comm: swapper Tainted: P 2.6.27-rc5-00363-ga002d93 [19.666764] [<c0151774>] __report_bad_irq+0x2e/0x6f [19.666764] [<c015199b>] note_interrupt+0x1e6/0x217 [19.666764] [<c0150d73>] ? handle_IRQ_event+0x2a/0x5a [19.666764] [<c0151f4c>] handle_fastoei_irq+0x91/0xb6 [19.666764] [<c0104ff2>] ...

Yinghai, the base idea with mask is to apply a mask only if you need it. And having _and_ operation to be mandatory implemented is a limitation and just not enough. So that is why i do check if mask is defined (well it cold be not a good practice indeed). Thanks for notice (and about binary operator too - will fix :) --

hope we can keep using MACRO.. YH --

Way too often, I have a machine that exhibits some kind of crappy behavior. The CPU looks wedged in the kernel or it is spending way too much system time and I wonder what is responsible. I try to run readprofile. But, of course, Ubuntu doesn't enable it by default. Dang! The reason we boot-time enable it is that it takes a big bufffer that we generally can only bootmem alloc. But, does it hurt to at least try and runtime-alloc it? To use: echo 2 > /sys/kernel/profile Then run ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/Kconfig.cpu | 10 - arch/x86/kernel/cpu/Makefile | 3 arch/x86/kernel/cpu/intel_64.c | 366 ----------------------------------------- include/asm-x86/bugs.h | 2 4 files changed, 3 insertions(+), 378 deletions(-) delete mode 100644 arch/x86/kernel/cpu/intel_64.c Index: linux-2.6/arch/x86/Kconfig.cpu =================================================================== --- ...

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/intel.c | 119 ++++++++++++++++++++++++++++++------------- 1 files changed, 83 insertions(+), 36 deletions(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index a669895..365a008 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -15,6 +15,11 @@ #include <asm/ds.h> #include <asm/bugs.h> +#ifdef CONFIG_X86_64 +#include <asm/topology.h> +#include ...

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- arch/x86/kernel/pci-nommu.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index 8e398b5..1c1c98a 100644 --- a/arch/x86/kernel/pci-nommu.c +++ b/arch/x86/kernel/pci-nommu.c @@ -14,7 +14,7 @@ static int check_addr(char *name, struct device *hwdev, dma_addr_t bus, size_t size) { - if (hwdev && bus + size > *hwdev->dma_mask) { + if ...

+static inline int is_buffer_dma_capable(u64 mask, dma_addr_t addr, size_t size) +{ + return addr + size <= mask; +} Do we care about wrap-around (e.g. addr=0xffffffffffffffff size=2)? -Tony --

Good idea. This patchset increases the readability of the software dma-api implementations. Acked-by: Joerg Roedel <joerg.roedel@amd.com> -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System | Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center | AMD Saxony LLC (Wilmington, Delaware, US) | ...

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Tony Luck <tony.luck@intel.com> --- lib/swiotlb.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index b5f5d11..240a67c 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -274,13 +274,13 @@ cleanup1: } static int -address_needs_mapping(struct device *hwdev, dma_addr_t addr) +address_needs_mapping(struct device *hwdev, dma_addr_t addr, size_t size) ...

Both iommu.h and dma-mapping.h have extern force_iommu. The latter doesn't need to do. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- include/asm-x86/dma-mapping.h | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 8bb3108..9dd92b4 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -16,7 +16,6 @@ extern dma_addr_t bad_dma_address; extern int ...

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> --- include/asm-x86/dma-mapping.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 9dd92b4..7b0fdd6 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -280,7 +280,7 @@ dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp |= GFP_DMA; } - if (!dev->dma_mask) + if ...

* Change genapic interfaces to accept cpumask_t pointers and to not return cpumask function values. * Modify external callers to use these cpumask_t pointers in their calls. * Create new send_IPI_mask_allbutself which is the same as the send_IPI_mask functions but removes smp_processor_id() from list. This removes another common need for a temporary cpumask_t variable. * Rewrite functions that used a temp cpumask_t variable for: cpumask_t allbutme = ...

Some more minor cleanups in cpumask stack usage with no new cpumask functions (except for the for_each_online_cpu_mask_nr call). Frees up more memory for the stack. Also, cleans up the genapic API to always pass pointers (for both 32 and 64) and to not return cpumask function values. * Add for_each_online_cpu_mask_nr to eliminate a common case of needing a temporary on-stack cpumask_t variable. * Change the genapic->send_IPI_mask function to accept cpumask_t pointer. * ...

--

This is a totally experimental patch against 2.6.27-rc5-mm1. It allows to control how much dirty file pages a cgroup can have at any given time. This feature is supposed to be strictly connected to a generic cgroup IO controller (see below). Interface: a new entry "filedirty" is added to the file memory.stat, reporting the number of dirty file pages (in pages), and a new file memory.file_dirty_limit_in_pages is added in the cgroup filesystem to show/set the current limit. The overall ...

Before staring patch review, why not dirty_ratio per memcg ? Is there difficult implementation issue ? Thanks, -Kame --

Every kernel package trying to provide files under /lib/firmware runs into problems really quickly with multiple kernels installed, especially with respect to distribution package tracking of the files. This patch moves them to /lib/firmware/$KERNELRELEASE. udev v127's firmware.sh looks there first before falling back to /lib/firmware. Signed-off-by: Jeff Mahoney <jeffm@suse.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Makefile +++ b/Makefile @@ ...

When using kdump modifying the e820 map is yielding strange results. For example starting with BIOS-provided physical RAM map: BIOS-e820: 0000000000000100 - 0000000000093400 (usable) BIOS-e820: 0000000000093400 - 00000000000a0000 (reserved) BIOS-e820: 0000000000100000 - 000000003fee0000 (usable) BIOS-e820: 000000003fee0000 - 000000003fef3000 (ACPI data) BIOS-e820: 000000003fef3000 - 000000003ff80000 (ACPI NVS) BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) BIOS-e820: ...

Hi. I am pleased to announce new Distributed Storage (DST) project release. DST is a block layer network device, which among others has following features: * Kernel-side client and server. No need for any special tools for data processing (like special userspace applications) except for configuration. * Bullet-proof memory allocations via memory pools for all temporary objects (transaction and so on). * Zero-copy sending (except header) if supported by device using sendpage(). ...

Cheers Jeremy - a better solution. Worth mentioning - this doesn't exist peacefully alongside my patch 965fe78fe Ingo - could you revert that please? Thanks, - Alex --

On Tue, 09 Sep 2008 15:43:25 -0700 What are the effects of the bug which you fixed? Do you consider this to be 2.6.27 material? 2.6.26.x? 2.6.25.x? --

Define USE_SPLIT_PTLOCKS as a constant expression rather than repeating "NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS" all over the place. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/xen/mmu.c | 2 +- include/linux/mm.h | 6 +++--- include/linux/mm_types.h | 10 ++++++---- include/linux/sched.h | 6 +++--- 4 files changed, 13 insertions(+), 11 deletions(-) =================================================================== --- ...

Yes. Also, could you wait for an Ack from me before committing anything Xen related? And Alex, could you be sure to explicitly cc: me on Xen patches? Thanks, J --

Where does the unpin happen? xen_unpin_page() also checks to see if it took the lock before trying to unpin, symmetric with xen_pin_page(). --

Hmm ok. I'll search further for a solution which fixes things more officially (and deals with the CONFIG_SMP && (NR_CPUS < CONFIG_SPLIT_PTLOCK_CPUS) case, which I just realized is also broken, and isn't fixed by this patch). In the meantime, at least UP is now usable. - Alex --

Right, I see. We shouldn't be pinning ptes on attachment in xen_alloc_ptpage() if we're not using split pte locks. --

Yup, this all looks reasonable to me, too. But these regions must be different than they were when the PNP quirk ran. I wonder if the BIOS left them unprogrammed, we ran the PNP quirk and discovered all these "conflicts," then PCI came along and assigned resources. Your dmesg shows power state changes for the PCI devices. Maybe the BIOS left them in D3 and unprogrammed: Intel ICH Modem 0000:00:1f.6: power state changed by ACPI to D0 Intel ICH 0000:00:1f.5: power state changed by ACPI ...

The only thing I used to get for pnp 00:08 on my Toshiba Satellite A40 up to 2.6.26 was this single line: pnp 00:08: can't add resource for IO 0xa8-0xa9 During bisecting I have found that fairly early in the 2.6.27 cycle this was "fixed" and that message disappeared. The commit that changed this was: commit aee3ad815dd291a7193ab01da0f1a30c84d00061 Author: Bjorn Helgaas <bjorn.helgaas@hp.com> Date: Fri Jun 27 16:56:57 2008 -0600 PNP: replace pnp_resource_table with dynamically allocated ...

It's not just a check, and not just general... Generally, you need it -- if PnP grabs an I/O resource, PCI can no longer do so (making the driver fail) which is the same problem that quirk_system_pci_resources() upto that point solved for mem resources only. And specifically, I definitely need it to not have my soundcard driver crap out due to PnPACPI grabbing a range that overlaps with its BAR. I don't know why your 1f.5 and 1f.6 are grabbing the "motherboard I/O ports" 0x00-0xff ...

Hello, I run linux on an AMD/VIA combination that appears to be prone to producing extremely anoying buzz on the sound card (and also in the image I get from my bt848 TV board) when I run the kernel with "make idle calls to CPU when not busy". The way out is to supply a "no-hlt"-append in lilo.conf. Doing so makes the noise go away. Unfortunately but unevitably, it then also pulls 5-10 Watts more from the grid. I thought it might be an idea to make this "no-hlt" flexible via a /proc entry, so that ...

On Mon, 08 Sep 2008 18:35:16 -0700 I'll dig if I have time. This is just a report. I tries UnixBench4.1 on x86_64/2cpu/1socket machine. (memory cgroup is enabled) Following is comparison with a mmtom based on rc4. === [rc4mm1] Execl Throughput 3004.4 lps (29.6 secs, 3 samples) C Compiler Throughput 1017.9 lpm (60.0 secs, 3 samples) Shell Scripts (1 concurrent) 5726.3 lpm (60.0 secs, 3 samples) Shell Scripts (8 concurrent) ...

Now that the PCI core manages the 'name' for each individual hotplug driver, and all drivers have been converted to use hotplug_slot_name(), there is no need for the PCI hotplug core to drag around its own copy of name either. Cc: jbarnes@virtuousgeek.org Cc: kristen.c.accardi@intel.com Cc: matthew@wil.cx Cc: kaneshige.kenji@jp.fujitsu.com Signed-off-by: Alex Chiang <achiang@hp.com> --- drivers/pci/hotplug/pci_hotplug_core.c | 6 +++--- include/linux/pci_hotplug.h | 3 ...

We no longer need to manage our version of hotplug_slot->name since the PCI and hotplug core manage it on our behalf. Now, we simply advise the PCI core of the name that we would like, and let the core take care of the rest. Cc: jbarnes@virtuousgeek.org Cc: kristen.c.accardi@intel.com Cc: scottm@somanetworks.com Signed-off-by: Alex Chiang <achiang@hp.com> --- drivers/pci/hotplug/cpci_hotplug.h | 6 ++ drivers/pci/hotplug/cpci_hotplug_core.c | 75 ...

Not quite true ... the Mth registered slot becomes N-(M-1). With the I don't like the goto-loop style (yes, I know we do it elsewhere), and I think we only need to krealloc inside the 'if' condition. Something like this, perhaps: static char *make_slot_name(const char *name) { char *new_name; int len, max, dup; new_name = kstrdup(name, GFP_KERNEL); if (!new_name) return NULL; /* * Make sure we hit the realloc case the first time through the * loop. 'len' will be ...

What's the difference between snprintf and scnprintf? And why were we bothering to use snprintf anyway? For when we fall into a parallel universe where a u32 can have more than twenty digits? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

Unfortunately, our name is kind of crappy. Can we not give the user anything better than this? I can't seem to find the CompactPCI specification to see if we have a better name available. I wonder if we can use DMI data on this class of machine. Scott? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

We no longer need to manage our version of hotplug_slot->name since the PCI and hotplug core manage it on our behalf. Now, we simply advise the PCI core of the name that we would like, and let the core take care of the rest. Cc: jbarnes@virtuousgeek.org Cc: kristen.c.accardi@intel.com Signed-off-by: Alex Chiang <achiang@hp.com> --- drivers/pci/hotplug/cpqphp.h | 13 +++++------- drivers/pci/hotplug/cpqphp_core.c | 39 +++++++++++++++++-------------------- 2 files changed, 23 ...

We no longer need to manage our version of hotplug_slot->name since the PCI and hotplug core manage it on our behalf. This means that alloc_slot_struct() no longer needs to take a 'name' param. On the other hand, we give rpaphp_register_slot() a 'name' param now to simplify the hotplug registration process. rpaphp_register_slot() can directly pass the drc_name to the PCI hotplug core. Cc: jbarnes@virtuousgeek.org Cc: kristen.c.accardi@intel.com Cc: benh@kernel.crashing.org Signed-off-by: ...

This is about all that can be done, unfortunately. I've never seen anything useful with regards to this in DMI on the boards I've looked at, and we would have to rework the board driver -> CPCI hotplug core interface to pass that information along even if we could get it for some boards. In general, it is a difficult problem to solve since the same set of system master and peripheral boards in a different chassis could very well be at different geographic addresses depending on where the ...

Prevent callers of pci_create_slot() from registering slots with duplicate names. This condition occurs most often when PCI hotplug drivers are loaded on platforms with broken firmware that assigns identical names to multiple slots. We now rename these duplicate slots on behalf of the user. If firmware assigns the name N to multiple slots, then: The first registered slot is assigned N The second registered slot is assigned N-1 The third registered slot is assigned N-2 The Mth ...

We do not need to manage our own name parameter, especially since the PCI core can change it on our behalf, in the case of duplicate slot names. Remove 'name' from pciehp's version of struct slot, and remove unused 'task_list' as well. Cc: jbarnes@virtuousgeek.org Cc: kristen.c.accardi@intel.com Cc: kaneshige.kenji@jp.fujitsu.com Signed-off-by: Alex Chiang <achiang@hp.com> --- drivers/pci/hotplug/pciehp.h | 9 +++++-- drivers/pci/hotplug/pciehp_core.c | 25 ...

So ... we're using %d here and %u in acpiphp. Obviously we don't expect to get a number above 2 billion, but I think if we do have some utterly bogus firmware that gives us a number above 2 billion, printing a positive number is a better user experience than a negative number. We clearly have a common pattern here where hotplug drivers have a number insteaqd of a name (I would venture this is the most common). Maybe we need a common helper? I think this is a subject for the long-term todo ...

It should select MII. That should change CONFIG_MII to =y. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

Hi, I missing some functionality in the current GPIO interface which I am using in an embedded environment. It is not possible to specify if an output is low or high active on arch level. IOW I want to activate or deactivate (on driver level) an output without having to know if an output is high or low active, which should be specified on arch level. Currently I created a structure with the gpio number and a boolean is_inverted, and I added two functions called gpio_activate and ...

Hi Andrew, I posted these patches previously and revised to follow comments, but they haven't been merged yet. So I resend them. The previous post: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/30/2742434 Thanks, Subject: [PATCH 1/2] ext3: add an option to control error handling on file data If the journal doesn't abort when it gets an IO error in file data blocks, the file data corruption will spread silently. Because most of applications and commands do buffered writes ...

__try_to_free_cp_buf(), __process_buffer(), and __wait_cp_io() test BH_Uptodate flag to detect write I/O errors on metadata buffers. But by commit 95450f5a7e53d5752ce1a0d0b8282e10fe745ae0 "ext3: don't read inode block if the buffer has a write error"(*), BH_Uptodate flag can be set to inode buffers with BH_Write_EIO in order to avoid reading old inode data. So now, we have to test BH_Write_EIO flag of checkpointing inode buffers instead of BH_Uptodate. This patch does it. (*) ...

On Tue, 9 Sep 2008 01:43:54 -0700 Oh, thank you. -Kame --

vi arch/powerpc/oprofile/cell/vma_map.c +46 And you'll find this comment in vma_map_lookup(): Default the offset to the physical address + a flag value. Addresses of dynamically generated code can't be found in the vma map. For those addresses the flagged value will be sent on to the user space tools so they can be reported rather than just thrown away. Returned is the flag value 0x10000000 + vma when not found. The test for negative overlay_tbl_offset does not work because it is ...

Using spatch I have found the following occurrences where there is an invalid test on an unsigned. Some may be not seriously, but just redundant, others may indicate an incorrect assumption (that the variable can be negative). I haven't found time to sort out these. If I have time I will write patches, but feel free to write one yourself if you want. Roel What is shown below is not meant as patch, just for reporting. ----[ arch/arm/mach-davinci/psc.c, unsigned ]---- --- ...

Arnd, This patch was originally submitted some time back, and I gave my approval for it. The last I heard from you about it (on July 2), you said you were queuing it up for 2.6.27. Has it gotten upstream yet? Thanks. -Maynard -------------------------------------------------------------------------- --

This needs to use an ERR_PTR(). It will save using the double-pointer. -- Dave --

These patches implement checkpoint-restart [CR v3]. This version is aimed at addressing feedback and eliminating bugs, after having added save and restore of open files state (regular files and directories) which makes it more usable. Todo: - Add support for x86-64 and improve ABI - Refine or change syscall interface - Extend to handle (multiple) tasks in a container - Security (without CAPS_SYS_ADMIN files restore may fail) Changelog: [2008-Sep-09] v4: - Various fixes and clean-ups ...

Hi, Below are some concerns, I would be grateful for explanations (or pointers if I missed them before). Should cr_hbuf_put() come before the return here? As far as I've understood, "leaking" the buffer size/data isn't critical (1. because it's just some extra space, and/or 2. the buffer is discarded on error anyway). The code looks really unbalanced Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is ...

Restoring the memory address space begins with nuking the existing one of the current process, and then reading the VMA state and contents. Call do_mmap_pgoffset() for each VMA and then read in the data. Signed-off-by: Oren Laadan <orenl@cs.columbia.edu> --- arch/x86/mm/checkpoint.c | 5 +- arch/x86/mm/restart.c | 54 +++++++ checkpoint/Makefile | 2 +- checkpoint/ckpt_arch.h | 2 + checkpoint/restart.c | 43 ++++++ checkpoint/rstr_mem.c | 351 ...

Dump the files_struct of a task with 'struct cr_hdr_files', followed by all open file descriptors. Since FDs can be shared, they are assigned an objref and registered in the object hash. For each open FD there is a 'struct cr_hdr_fd_ent' with the FD, its objref and its close-on-exec property. If the FD is to be saved (first time) then this is followed by a 'struct cr_hdr_fd_data' with the FD state. Then will come the next FD and so on. This patch only handles basic FDs - regular files, ...

As I replied to Dave, I don't see why this would be a security problem. This handles private memory only. In particular, the uncommon case of a read-only VMA tha has modified contents. This _cannot_ affect the file from which this VMA may have been mapped. Shared memory (not file-mapped) will be handled differently: since it is always backed up by an inode in shmfs, the restart will populate the relevant pages directly. Besides, non-file-mapped shared memory is again not a security ...

Create trivial sys_checkpoint and sys_restore system calls. They will enable to checkpoint and restart an entire container, to and from a checkpoint image file descriptor. The syscalls take a file descriptor (for the image file) and flags as arguments. For sys_checkpoint the first argument identifies the target container; for sys_restart it will identify the checkpoint image. Signed-off-by: Oren Laadan <orenl@cs.columbia.edu> --- arch/x86/kernel/syscall_table_32.S | 2 ++ ...

Covers application checkpoint/restart, overall design, interfaces and checkpoint image format. Signed-off-by: Oren Laadan <orenl@cs.columbia.edu> --- Documentation/checkpoint.txt | 187 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 187 insertions(+), 0 deletions(-) create mode 100644 Documentation/checkpoint.txt diff --git a/Documentation/checkpoint.txt b/Documentation/checkpoint.txt new file mode 100644 index 0000000..f67aef1 --- /dev/null +++ ...

Hm, shouldn't this be max * sizeof(*fdlist) like the kmalloc above? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Hi all, when process wants set limit of open files to RLIM_INFINITY it gets EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch should fix the problem. Please add me to CC of your responses because I'm not member of list. Regards, Adam -- Adam Tkac

seccomp is prctl(2)-driven now. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- arch/x86/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1191,7 +1191,6 @@ config IRQBALANCE config SECCOMP def_bool y prompt "Enable seccomp to safely compute untrusted bytecode" - depends on PROC_FS help This kernel feature is useful for number crunching applications that may need to compute untrusted bytecode ...

I'm missing the strings that go into /proc/cpuinfo? -- error compiling committee.c: too many arguments to function --

it should go into intel_64.c and intel.c YH --

Yeah, I've considered that, but seems duplicate for both files? The feature detection code is the same. Any way to merge them? Thanks! -- regards Yang, Sheng --

You could add another file (intel-vt.c) and #include or link it from both intel.c and intel_64.c. -- error compiling committee.c: too many arguments to function --

Dear Members, Its our great pleasure to launch a new version of your favorite everyday website with Great New Looks, New Logo & More Features. One stop homepage for you, with one click links to all the important daily visit websites. <http://www.myeverydaypage.com/> Changes/Additions: 1: Brand new Platform to provide you with better looks and performance. 2: More new websites added, as per your recommendations/feed backs. 3: Easy Access to Google Search. 4: New MEP ...

applied to tip/fastboot - thanks Steven! Ingo --

applied to tip/x86/iommu - thanks Steven, Ingo --

On Tue, 9 Sep 2008 08:57:36 +0200 Did you apply the same patch yesterday? http://lkml.org/lkml/2008/9/8/274 --

Patch works for me. Tested-by: Frans Pop <elendil@planet.nl> --

(Resending because of error in mail headers in previous attempt; sorry) On my Toshiba Satellite A40 with 2.6.27-rc4/5 I noticed the following error in the boot log (not there with 2.6.26): e100: 0000:01:08.0: e100_probe: Error clearing wake event Bisection has fingered the following patch as the cause of the message. commit eb9d0fe40e313c0a74115ef456a2e43a6c8da72f Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Mon Jul 7 03:34:48 2008 +0200 PCI ACPI: Rework PCI handling of ...

L1 instruction memory and MMR memory on blackfin can not be accessed by common functions probe_kernel_read() and probe_kernel_write(). Blackfin asks for 2/4 byte align access to MMR memory and DMA access to L1 instruction memory. These functions need to be reimplemented in architecture specific kgdb.c. Signed-off-by: Sonic Zhang <sonic.adi@gmail.com> --- kernel/kgdb.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/kgdb.c b/kernel/kgdb.c index ...

Successfully tested earlier tonight, see: https://bugzilla.redhat.com/show_bug.cgi?id=459523 Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Tom Horsley <tom.horsley@att.net> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_imon.c | 1280 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1288 insertions(+), 0 deletions(-) ...

Hi [...] This might actually be the most common setup, as it is very easy to build[1] with minimal soldering skills and has also been used by various vendors (older models of the TechniSat SkyStar2 DVB-S budget card, to name just one example; it is only slowly being replaced by alternative means, as serial ports are becoming rare on newer systems. Regards Stefan Lippers-Hollmann [1] http://www.lirc.org/receivers.html --

Knew I had to screw up at least one thing. That should be j@jannau.net, not jannua.net. -- Jarod Wilson jarod@redhat.com --

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_bt829.c | 388 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 396 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_bt829.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index ...

So where do all these LIRC_SERIAL_* macros come from? I can't really tell It would be really nice to use the .field=value structure initialization This is a little scary. Maybe hrtimers would be a better way of handling This all looks like a reimplementation of ioport_map() and the associated This looks like a hard busy wait, without even an occasional, polite, cpu_relax() call. There's got to be a better way? The i2c code has the result of a lot of bit-banging work, I wonder ...

Jarod Wilson <jwilson@redhat.com> writes: This means you always wake up every half a second? That will not make the powertop users happy. When there's nothing to do it should just sleep. The checks in plugin_register seem a bit extreme. Always use the #ifdef MODULE path, it does DTRT when compiled in too. Remove the init_module wrapper, replace with module_init() ... not read further ... -Andi -- ak@linux.intel.com --

On Tue, 9 Sep 2008 00:05:49 -0400 As I understand it, proper assertions of copyright need the word My guess is that this will not be a major impediment to mainline inclusion; What is the locking regime for this function? As far as I can tell, it's called with no locking at all, even though it's manipulating the irctl This kind of formatting suggests that, just maybe, the control structures Looking at lirc_unregister_plugin(), I don't see any cause of failure that could be expected ...

--- diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig index 5f9d860..2ba0904 100644 --- a/drivers/input/Kconfig +++ b/drivers/input/Kconfig @@ -170,6 +170,8 @@ source "drivers/input/tablet/Kconfig" source "drivers/input/touchscreen/Kconfig" +source "drivers/input/lirc/Kconfig" + source "drivers/input/misc/Kconfig" endif diff --git a/drivers/input/Makefile b/drivers/input/Makefile index 98c4f9a..4dcb852 100644 --- a/drivers/input/Makefile +++ ...

LIRC_SERIAL_TRANSMITTER is already gone, not sure that should happen to done thanks for the review. My changes are until Jarod pulls them in following tree git://git.jannau.net/linux-2.6-lirc.git Janne --

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_igorplugusb.c | 619 +++++++++++++++++++++++++++++++++ 3 files changed, 627 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_igorplugusb.c diff --git a/drivers/input/lirc/Kconfig ...

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_serial.c | 1312 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 1320 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_serial.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index ...

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_atiusb.c | 1321 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 1329 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_atiusb.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index ...

I don't really care and I agree that the SCM is the preferred place for the information. The only problem is that the info is in a different SCM (lirc cvs repository). I've removed the changelogs from all files as long as no names wre sigh, It would be a good idea, not sure if I'm motivated enough to add That's probably a question for the original author, Dan. CC added. I'm yes, the declaration looks like this: static DECLARE_MUTEX(...); which gives us a single holder ...

IR device handling is often a bit, shall we say, "special", for a number of devices... Some receivers decode the waveform and give us something sensible the input layer could use (and some IR receivers do work that way), while other receivers pass along raw IR codes, which we require the use of the lirc daemon to decode and convert into something sensible. To complicate the matter further, a number of devices are either output-only devices, or both input and output devices. There's been ...

Janne took care of these. Heck, he's already replied, I'll just leave out the Historical. I think it is supposed to signify that this was originally licensed and written by Artur, but simply removing "(L) " is fine (here and in Yeah, but now that you point that out, I'm not sure how... :) Me too. Gone. -- Jarod Wilson jarod@redhat.com --

Do you rely on this specific major? Since your daemon opens /dev/lirc0 you don't need a fixed major do you? LIRC_SERIAL_TRANSMITTER is used in patch 2 and just to enable a module options. Since it is always the case, please remove it. if you need this than you use the BKL back. As far as I remember the ioctl() handler in kernel core no longer takes the BKL and I don't For all comments above functions: - Please use the default comment style. - don't comment obvious things - please use kernel ...

One frequently-used source of pre-built serial receivers (and transmitters) here in the US is http://irblaster.info/. Hey, that actually just reminded me... I think I *do* have a serial IR receiver laying about somewhere that came w/one of my TechniSat SkyStar HD-5000 cards... Thank you, Stefan! ;) -- Jarod Wilson jarod@redhat.com --

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_it87.c | 999 ++++++++++++++++++++++++++++++++++++++++ drivers/input/lirc/lirc_it87.h | 116 +++++ 4 files changed, 1123 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_it87.c create mode 100644 ...

Yeah, I realized imon was much lower in the sort order after my reply there, which was a bad initial move by me, since its actually one of the ones that has definite positive testing feedback already. I believe quite a number of vendors of HTPC cases use imon lcd (or vfd) and ir combo devices. -- Jarod Wilson jarod@redhat.com --

Added CONFIG_LIRC_SERIAL_TRANSMITTER to Kconfig and removed this from A relict. Lirc used many single holder semaphore and I forgot to remove the include after converting them to mutexes. I'll check the other Probably not, but it doesn't make a difference for the current kernel. The only other hit for this symbol is arch/xtensa/kernel/syscall.c 38:#undef __KERNEL_SYSCALLS__ There is only one other inline. I doubt it makes a difference there but I won't change it without test. ...

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_sir.c | 1302 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1310 insertions(+), 0 deletions(-) create mode 100644 drivers/input/lirc/lirc_sir.c diff --git a/drivers/input/lirc/Kconfig b/drivers/input/lirc/Kconfig index 42e9bc3..b2bdbfb ...

Successfully tested with the IR interface on a Hauppauge PVR-250 and the flimsly little grey remote that shipped with it. Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannua.net> CC: Christoph Bartelmus <lirc@bartelmus.de> Tested-by: Jarod Wilson <jarod@redhat.com> --- drivers/input/lirc/Kconfig | 8 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/lirc_i2c.c | 639 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 648 ...

The following patch series adds 17 new drivers for assorted infrared and/or RF remote control receivers and/or transmitters. These drivers have long lived out-of-tree at http://www.lirc.org/, packaged as 3rd-party modules by many distributions, and more recently, patched into the kernels of at least Fedora and Ubuntu. The primary maintainer of lirc, Christoph Bartelmus simply hasn't had the time to send these bits upstream, and a few months back, gave me the go-ahead to take on the task. Most ...

Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Janne Grunau <j@jannau.net> CC: Christoph Bartelmus <lirc@bartelmus.de> --- drivers/input/lirc/Kconfig | 7 + drivers/input/lirc/Makefile | 1 + drivers/input/lirc/commandir.c | 982 +++++++++++++++++++++++++++++++++++++++ drivers/input/lirc/commandir.h | 68 +++ drivers/input/lirc/lirc_cmdir.c | 596 ++++++++++++++++++++++++ drivers/input/lirc/lirc_cmdir.h | 25 + 6 files changed, 1679 insertions(+), 0 ...

From: Milan Broz <mbroz@redhat.com> Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> --- cherry-picked from mainline 9f497bcc695fb828da023d74ad3c966b1e58ad21 Let's see if this time it will make it for 2.6.26.6? Without ...

Commit 22af89aa0c0b4012a7431114a340efd3665a7617 changed the order of operations for computing monochrome color values. This generates 0xffff000f instead of 0x0000000f for a 4 bit monochrome color, leading to image corruption if it is passed to cfb_imageblit or other similar functions. Here's a quick patch to fix it up. David Winn PS: Please CC me with any replies. Thanks diff --git a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h index a6e38e9..89a3468 100644 --- ...

Ahh. Took me a second to see that this is saved from signed/unsigned attacks by the fact that CName.len is u8. In other words: len is declared as an "int" (i.e., signed). memcpy's third parameter is declared as size_t (i.e., unsigned). Fortunately, len can't be negative, because CName.len is u8. OK, got it. I took a glance at some of the rest of fs/hfs/, to see whether there are any other issues in there, and I couldn't tell whether it's all OK. e.g., * hfs_asc2mac() doesn't seem to ...

Trace preempt/softirqs off/irqsoff latency in rwlock. Can be used to perform precise measurement on the impact of these primitives without being lost in the kernel noise. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> CC: Andrew Morton <akpm@linux-foundation.org> CC: Ingo Molnar <mingo@elte.hu> CC: "Paul E. McKenney" ...

Sample module to show how to use psrwlock. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> CC: Andrew Morton <akpm@linux-foundation.org> CC: Ingo Molnar <mingo@elte.hu> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> CC: Peter Zijlstra <peterz@infradead.org> CC: Joe Perches <joe@perches.com> CC: Wei Weng <wweng@acedsl.com> --- ...

Design goal, algorithmic description and performance tests. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> CC: Andrew Morton <akpm@linux-foundation.org> CC: Ingo Molnar <mingo@elte.hu> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> CC: Peter Zijlstra <peterz@infradead.org> CC: Joe Perches <joe@perches.com> CC: Wei Weng ...

I had to go digging through the archives to find out where the "+1" came from, as it pre-dates my involvement with kgdb. It turns out this actually appeared in the initial version of the 'X' 'M' gdb serial packet write. You can see historical first version if you scroll to line 973 at: http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/core-lite.patch?annotate=1.40 That means we have carried this for 3 years, 10 months with no one noticing it. :-) The flush_icache_range() is a "start" to ...

Hello Linus, I see you applied this patch but not the two patches from my script. Does this mean you consider this is not the right time for the latter two patches? If so should I trigger you again later? When? Or didn't you find time to look at the script? thanks and best regards Uwe --

Roland suggested this approach; I just want to snapshot the field That's not completely clear to me. I'm allowing for the possibility that it might be called during, say, process teardown. It's used in so If that's the consensus I'll do so. I assumed that speed was more That was the original plan but we (that is, Roland and I) decided to eliminate the separate storage for the dead-threads totals. It's now all kept in the totals field, for the whole thread group. Note that this ...

Just to clarify: yes I see, .totals is also used by do_task_stat()/etc, but they can iterate over sub-threads as before. And my apologies if this was already discussed ;) Oleg. --

That's a much better idea, thanks. Though it wasn't *quite* the same in the 32-bit 2-level case, because that mode didn't need any mask at all, the right shift was sufficient. I expected gcc to optimize away that difference, and often it does, but not always (I'm using 4.2.1 and CC_OPTIMIZE_FOR_SIZE here): pte_page() involved 228: c1 e8 0c shr $0xc,%eax 22b: c1 e0 05 shl $0x5,%eax before the unification, but afterwards 228: 25 00 f0 ff ff and ...

Latest version is out there now (leaving the gas-error-proofing for later), Linus --

it fixes build errors in my test setup too. Ingo --

The Kconfig.cpu change wasn't in my git pull. David --

I haven't seen this come across the wire in Linus's 2.6.27 tree. We're still going to do this right? David --

I see it now thanks. David --

If I understand the binutils changelog correctly -march=generic32 support was added one week before the NOP code in question, so all cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

Yes, but if it's slower than jmp+mov than you actively want to avoid it. -hpa --

Compile just about any C program with -march=i686. -hpa --

.. Our firewall here uses a Via C3-600 CPU, and CMOV has never worked on it. But based upon your posting, I have today upgraded the BIOS to the latest (2004) version. Now.. how can I check whether CMOV works or not? It's not listed in /proc/cpuinfo. Thanks --

AFAIK they fixed that in newer BIOS with a microcode update. It's slow, but it works. -Andi --

If it's not in cpuinfo it won't work. -Andi -- ak@linux.intel.com --

.. .. Okay, done. And the binary does indeed have a ton of CMOV instructions. When running it, this appears immediately: Illegal instruction So much for the "BIOS upgrade fixes CMOV microcode" theory. Cheers --

On Mon, 8 Sep 2008 10:45:30 -0700 Seems I already fixed it: http://userweb.kernel.org/~akpm/mmotm/broken-out/drivers-char-tpm-tpmc-fix-error-patch... (identical to yours, with a different label name). --

From: David Brownell <david-b@pacbell.net> Can you be more specific? Oh, you want me to use the string defined by that config option. Ok :-) But as far as I can tell this will only be set of RTC_HCTOSYS and users currently are allowed to not set that. If this code goes somewhere generic you would need to ifdef test on that, depending upon where you'd want to put it and how it would When would be "eventually closed" if I open it here and remember the pointer in a static local variable, ...

From: David Brownell <david-b@pacbell.net> Well if I cache it then we'll hold it forever and that's not so nice right? I'm going to put the missing rtc_close() in there for now to fix the leak. I'm happy to cache this if you think it's warranted, but then I see, as Paul mentioned this is needed for stuff like RTCs behind I2C. This change isn't in Linus's tree yet. --

I'll translate that as "-ENOPATCH". :) It'd suffice to fire a timer every 15 minutes or so, and close it if the NTP logic hasn't refreshed the clock since last time. You're right that the simplest scheme is to just open/close on each call. The extra work is so infrequent it OK by me. --

That's bad then, because ACPI video support does not work here. I can boot, and even Fn-home/end works, but it breaks with X. In old versions, it resulted on black screen after LID close in X. In 2.6.27-rc5, screen goes black as soon as X are started. (In old versions, I could use ibm-acpi, and fn-home/end worked even without CONFIG_ACPI_VIDEO...) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) ...

Should be fixed in .28. Sorry about that, confusion over which DRM branches were getting merged meant it missed .27. -- Matthew Garrett | mjg59@srcf.ucam.org --

The previous kernel I used was linux-2.6.22.1 and this kernel doesn't have the problem. I discovered the problem when I built and installed the "latest stable" 2.6.25.17. My main working disk, a new SATA, showed severe errors during each reboot. I can duplicate this at will and remove the errors by removing my second CPU! Cheers, Dick Johnson Penguin : Linux version 2.6.25.17 on an i686 machine (4786.48 BogoMips). My book : ...

Following up on my own mumble: There are some lesser known make targets for git which almost do that already. make install-html uses only asciidoc and xsltproc, but not xmlto, for generating (and installing) html doc, which makes some people happier already. make quick-install-doc installs the man pages (and only the man pages, not the html version) by using the "man" branch provided by "the man" (JC). I would go about renaming quick-install-doc to quick-install-man, introducing ...

This works because you have the full toolchain, especially xmlto. He might want an install target which installs doc from the doc-tarball or from the man- and html-branches. Be it a Makefile in those convenience branches. I know it's just a tar or cpio away, of course. I might look at a Makefile for the doc branches. Michael --

It makes it more systematic. Right now: Documentation/Makefile: all: builds html and man install: installs only man (depends on man) install-{info,html}: installs $foo (depends on $foo) quick-install: installs man from man branch Makefile: doc: builds html and man (-C D all) install-doc: installs only man (-C D install) install-{info,html}: installs $foo (-C D install-$foo) quick-install-doc: installs man from man branch (-C D install-$foo) So there is a distinct asymmetry between ...

A very esoteric oops that hasn't shown up for two years. Please let's look at this and see what it would take to fix this properly. What are we trying to achieve by reading utsname? Eric --

But an easily reproducible one. It's not as though we'll stop looking for the right fix just bc we have It looks like it gets copied into the sunrpc messages so I assume it is a part of the sunrpc spec? I don't want to do this, but we *could* put a conditional in utsname() to have it return init_utsname if current->nsproxy is null... -serge --

cl_server is the server-side. cl_nodename is the "machine name" of It's worth investigating. Just enable RPC tracing (/usr/sbin/rpcdebug -m rpc -s all) before shutting down the client. NFS unmounting is historically difficult because during a system shutdown, unmounting is the last thing to occur, and usually happens after most system services (such as the portmapper service) have become unavailable. That's fine for local file systems, but it makes for a rather dodgy ...

Thanks, Darn. Looks like we need to capture both names at the same or a similar point. Interesting. Eric --

struct rpc_create_args seems to be used only as a stack argument I see. It make sense but, looking at the code, the nfs and sunrpc will need some heavy changes ... Thanks, C. --

Right, I get the domain stuff - that's good stuff. But, let my try and confuse you with ASCII-art ;-) Domain [0-7] group [0-3] group [4-7] Domain [0-3] group[0-1] [group2-3] Domain [0-1] group 0 group 1 (right hand side not drawn due to lack of space etc...) So we have this tree of domains, which is cool stuff. But then we have these groups in there, which closely match up with the domain's child domains. So my idea was to ditch the groups ...

Sure, and those comments only tell me what it does, not why it does it. But then why not add a domain level that represents the packages and power schedule on that? That way you dont have to change the domain structure depending on the load balance goals. Also, that justification is just wrong - AMD has similar constructs in its cpus, and god knows what other architectures do, so hiding this in Yes I understand, but we really need to do something about it - and everybody with interests in ...

Peter, Almost every if() stmt/basic block in the power savings code has comments around it. And also power-savings code is 50 lines (mostly comments) Why? Based on the power vs perf, we wanted to construct topologies differently. Reason for the complexity is, in some of the Intel cpu's, while the cores share the same package they have different last level caches. So for performance, we want to differentiate based on last level caches power-savings code is very small part of that nightmare ...

But it's all per-cpu, so you'd have to iterate down other CPU's child domains. Which may get dirtied by that CPU. So you get cacheline bounces. You also lose flexibility (although nobody really takes full advantage I'm not saying you couldn't do it (reasonably well -- cacheline bouncing might be a problem if you propose to traverse other CPU's domains), but Yes it would be great if it happens. --

Are you harking back to the good old days of 2.6.24? Or looking ahead to a bright new future? There was a defect, in the TLB flushing sequence IIRC, which got them kicked out in a hurry. They might return - but I think everybody would prefer to have a better way of applying the existing allocators than this extra pool. Hugh --

Thanks, but that is still version 0.9.8 with no support for usb. It defines DLT_USB and DLT_USB_LINUX but has no code to actually read from /dev/usbmon. I need the CVS version of libpcap. --

From: Keith Owens <kaos@ocs.com.au> Sorry that's the most recent CVS tree Patrick had when I built that GIT repo. --

I still think this patch shouldn't change handle_signal(). Once again. The signal handler for SIGSYS can first do sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any other syscall, so this change is not needed, afaics. The overhead of the additional PTRACE_SELF_OFF syscall is very small, especially compared to signal delivery. I don't think this functionality will be widely used, but this change adds the unconditional overhead to handle_signal(). Btw, the check above ...

Thanks! I will update the patch to add another category, and merge the array. -- regards --

Frans, what's the highest value which you have seen ? Thanks, tglx --

It's nothing to worry about. I out the WARN_ON() there to get some information about the validation of min_delta_ns and to see in which range this happens. I'm going to remove the WARN_ON() and just keep the information that we need to increase the min_delta_ns value for safe operation. Thanks, tglx --

Ah, OK. A WARN_ON is perhaps a bit heavy for that, unless you actually want to be flooded with reports :-) In my case it prevented me from running the kernel on other boxes than the laptop because I feared some possibly important issue. Also, a single line can easily be filtered out from logcheck reports while Sounds like a plan; have already done so locally. Here are some results I've got so far. You can see reboots and supend to RAMs. Maximum observed value on the HP 2510p is now 80000 ...

Oh, yes, our _PAGE_IO has the same meaning. -- Keir --

That's basically what our _PAGE_IO flag (in our old Linux patchset) means. We use it to cause pte_pfn() to return an invalid pfn and hence avoid reference counting that way. Since kernel mappings are never reference counted (I think?) perhaps we could use _PAGE_SPECIAL even if it is restricted to use on user mappings. -- Keir --

Well, _PAGE_IOMAP's most important semantic from Xen's perspective is that the frame number is considered to already be an MFN and so isn't converted. It may be that _PAGE_SPECIAL is also useful for its "no refcount" properties, but we could set both in that case. At present we can't set _PAGE_SPECIAL on kernel mappings because we assume its usermode only, and its shared with _PAGE_CPA_TEST which is kernel-only. Most _PAGE_IOMAP mappings are in kernel space, but I wouldn't discount user ...

SDHCI supports CB712/714 parts. I already investigated that CB710 is not I checked yesterday that indeed nothing bad happens, but looking at the code I can see that mmc_request_done can call ->request() with a retried request so, unless gcc optimizes tail-calls, recursion Is it safe to assume that cmd->data is NULL when command type is other than ADTC? I've looked briefly through drivers/mmc/core/*_ops.c, but I'll give it a try. Thanks for your reply. I'll post the code for review ...

(cc linux-usb) I guess it risks breaking someone else's system. Or perhaps the number was just grabbed out of the air. Can we do a separate quirk just for that machine (and ones with the same bug)? --

Which kernel version(s)? --

I also think it's a userspace problem. I found it while playing with KDE4.1 kwin/Compiz, less than a month ago, always running on a current vanilla git kernel: I noticed the syslog storm only recently (my bad, because judging from the disk light I think it has always been there). If you think it's useful I can do some test with older kernels (will take some time btw). R --

This is against vanilla current git. Linux poppero1 2.6.27-rc5-00000-g7686ad5-dirty #1 PREEMPT Sun Sep 7 08:47:08 CEST 2008 i686 GNU/Linux R --

Thanks for that, it clearly shows the virtual address allocator is allowing an overlapping allocation after a vm_unmap_aliases() call. Unfortunately, my "random" test case happened not to trigger that... I should have paid more attention to edge cases rather than just random testing. Anyway, I hope this fix should solve the problem for you? (it fixes it here)

The only case I didn't test was the case for Intel's drivers, all other drivers would use regulatory_hint() based on an alpha2 and that worked swell. I found some issues with the case of providing a built regulatory domain so I'm updating it now and am also updating some other parts of the code for the old regulatory infrastructure, it seems there were a few obvious issues we didn't catch there yet. I hope to have the new doc for you with a few fixes and an example as to what Intel drivers ...

I mean git pulled from Linus' tree. Btw, I'm attaching dmesg with debug. Luca

After using ia64 defconfig, all I had to do was enable Sparse Memory model instead of Discontiguous. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

EXPORT_SYMBOL_GPL(remove_memory) is removed. It is required by drivers/acpi/acpi_memhotplug.ko. -- Yasunori Goto --

I think this patch is a step in the right direction, lets get rid of that pesky kobject just for the cmdfilter. Can you resend the patch _without_ the sysfs changes and link support? We haven't released a kernel with cmd filter support yet, so we can change the location still and not have to worry about compatability. -- Jens Axboe --

Yeah, it's certainly starting to look like it... The amount of changes to unbreak it are too large to submit now, so lets postpone it until 2.6.28. -- Jens Axboe --

Unfortunately, ia64 does /not/ currently support the standard lockstat reporting interface. However, I was able to utilize Caliper (an HP ia64 profiler similar to Oprofile) and gathered a couple of interesting values. These are averaged over 10 runs each (10 w/ rq_affinity=0 and 10 w/ rq_affinity=1, alternating between the two). First: For the overall system we can gauge how efficient the instruction stream is by looking at un-stalled instructions: w/ rq_affinity set to 0 we see 24.001% of ...

I just spotted it - it's a mismerge on my part. Will send v3 in a minute. Jan --

yeah - questionable in the sense of assuming that it's all non-RAM. But there's nothing weird about this testbox (it's a usual whitebox) - and two other testboxes failed as well after some time (no crashlog available from them). A 64-bit testbox didnt fail so it seems 32-bit only. Ingo --

Make the x86_{phys,virt}_bits common for 32- and 64-bits, and use the former in ioremap's phys_addr_valid() check also on 32bit/PAE. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- arch/x86/kernel/cpu/common.c | 17 ++++++++++++++++- arch/x86/mm/ioremap.c | 15 +++++++-------- include/asm-x86/processor.h | 4 ++-- 3 files changed, 25 insertions(+), 11 deletions(-) --- linux-x86.orig/arch/x86/kernel/cpu/common.c +++ linux-x86/arch/x86/kernel/cpu/common.c @@ -439,6 ...

I suppose. They only appear with certain configs and are fairly harmless, so I wasn't planning on pushing them into 2.6.27. But I'll include it in my next pull request anyway, since you're such a cool guy and I want to make you happy :) (assuming 2.6.27 proper isn't released in the next couple of day...) Thanks, Jesse --

Correct, and I'm also thinking it's the disks, I'll try that as soon as --

This is with the NVidia driver I guess? So your resume appears to be 1.6 s faster without the USB devices. Perhaps the disks also add to the latency. If you have CONFIG_PCIEASPM set in the kernel config, you can try to unset it and see if that changes anything. Thanks, Rafael --

But you have customers telling you they're getting annoyed because of this? Or you have your own "realistic" workloads that allocate hugepages on demand (OK, when I say realistic, something like specjbb or whatever is obviously a reasonable macrobenchmark even if it isn't strictly They shouldn't, because that's sad and deadlocky. But yes I agree it Yeah, but blocking the whole pool gives a *much* bigger chance to coalesce freed pages. And I'm not just talking about massive order-10 ...

Looks like something for Bart to look into. -- Jens Axboe --

Sure. It applied fine to clean current mainline. It looks ok now. No oopses and no BUGs. But still after a fresh boot I see # modprobe ide-cd_mod # rmmod ide-cd_mod # rmmod ide-cd_mod # rmmod ide-cd_mod ERROR: Module ide_cd_mod does not exist in /proc/modules # modprobe ide-cd_mod # rmmod ide-cd_mod # rmmod ide-cd_mod ERROR: Module ide_cd_mod does not exist in /proc/modules You need to rmmod ide-cd_mod twice to get it unloaded. After another modprobe/rmmod it works as ...

Hi, I think I like this patch better than Stephen's, but despite causing the Rusty, can you take http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.27-rc5/2= .6.27-rc5-mm1/broken-out/net-fix-compilation-ng-when-config_module.patch (although I'd rather see the blank line stay) and fold it into that patch or put it into the tree that Stephen pulls? johannes

On Tue, 9 Sep 2008 09:55:48 -0700 one option is poll fast for <X jiffies> and then back off with sleeping delays -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Compiling with -O0 has worked previously, but not for a while. David --

^^^^^^^ The reason why it works for Keith at all seems to be that even with -O0 gcc already does this kind of optimizations. Check e.g. the assembler generated for the following (userspace) program with -O0: <-- snip --> int foobar; int main() { if (1) return 0; foobar = 12345; return 42; } cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had ...

Sorry, I couldn't resist after being required to write code in VC++/MFC, where memory leaks are "normal," and pointers passed to "methods" don't remain valid if there is any other activity besides yours occurring in the machine. If you have to single-step through kernel procedures, you are not writing proper code for a kernel. Furthermore, even when using the kernel debugger, you are not executing the exact same path that would be executed without the debugger attached. These are some ...

Your observation is correct; I chose this interface because it's really simple and handy. I'm not worried about the performance because such VMAs (read only but modified) are really rare, and the code can be optimized later on. VMAs of shared maps (IPC, anonymous shared) will be treated differently. VMAs of shared files (mapped shared) are saved without their contents, as the contents remains available on the file system ! (yes, for that we will eventually need file system ...

From: David Fries <david@fries.net> A call to pnp_stop_dev and pnp_start_dev now shuts down and initializes plug and play devices for suspend and resume. Signed-off-by: David Fries <david@fries.net> Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Jeff Garzik <jeff@garzik.org> --- drivers/net/ne.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/drivers/net/ne.c ...

The sky2 bits too? Sure, that's fine with me. I'll stuff it into my linux-next tree tomorrow after a quick look. Thanks, Jesse --

> ahci, pata_marvell: play nicely together I can't see how that's going to work with a 6145 adapter and no PATA devices attached. The AHCI driver will always defer to pata_marvell (unless marvell_enable=1 is passed) and pata_marvell will defer to ahci when it doesn't see any PATA devices. --

Thanks! I've found more slippery place, could you please add attached patch if the first one doesn't work? Regards, Alex.

Oh shit, my mistake. I applied it to a 2.2.26.4 tree. please disregard. I will test it shortly. Jeff --

The first patch corrected the problem. I have regressed the patch on 2.6.27-rc5. The message is now gone. I will test the new patch you just Jeff --

Can you resend this against my linux-next branch? It didn't apply to my latest bits... Thanks, Jesse --

I use 2.6.26 Kernel available in Debian Lenny and don't have any problem. Best regards, Renato --

Applied. I'll include it in my next 2.6.27 pull request after fixing up my trees. Thanks, Jesse --

OK, just to be clear, where are those fields not used? They are used in the new mmc_get_timeout() function. I'm assuming SDIO should use the same logic as MMC for working out the timeout value? Or is there an upper limit of 1 second on the timeout for SDIO? I am not very confident in my understanding of the nuances of SDIO. Also, I don't have any SDIO hardware so I can't test this change (which is the reason I didn't change it in the first place). --

On Tue, 9 Sep 2008 08:59:11 +0100 Sorry, you're right. I just noticed the !host->mmc->card part and assumed you had your own logic in there. Why do you have that part though? What case have you found where you need the timeouts and do not have properly set timeout fields? -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish ...

On Tue, 9 Sep 2008 08:34:27 +0100 Yup, timeout_ns and timeout_clks. -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. --

Chris, AFAICS, interpreting 0 as the TGID would be more consistent with those parts of the interface that are specified by POSIX.1. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html --

Denys, Tested-by: Michael Kerrisk <mtk.manpages@gmail.com> Please do CC me on API changes, so that they might get documented in the man pages. Thanks for this work. (I'm not sure whether or not it's a response to my bug report, http://bugzilla.kernel.org/show_bug.cgi?id=6258 ) I tested your patch. Most things seem to work as I would expect, but there is one strangeness. I would expect setpriority(PRIO_PROCESS, getpid()) and setpriority(PRIO_PROCESS, 0) to have the same affect ...

Just keep in mind that an important point is to make it more attractive to configure cgroup into the kernel, but have it disabled or unused at runtime. --

Agreed, but we do reduce the sizeof(struct page) without adding on to What address calculation do we need, sorry I don't recollect it. 32 bit systems with PAE can support quite a lot of memory, so I am not sure I I don't like the approach. -- Balbir --

No problem, I am glad to know that we are not limited to a particular model. -- Balbir --

Yeah of course. 4 or 8 bytes. Everything adds up. There is nothing special about cgroups that says it is allowed to use fields in struct page where others cannot. Put it in perspective: we try very hard not to allocate new Yes I too think that would be the ideal way to go to get the best of performance in the enabled case. However Balbir I believe is interested in memory savings if not all pages have cgroups... I don't know, I don't care so much about the "enabled" case, so I'll leave you two ...

On Mon, 8 Sep 2008 20:58:10 +0530 Hmm.. I've considered this approach for a while and my answer is that this is not what you really want. Because you just moves the placement of pointer from memmap to radix_tree both in GFP_KERNEL, total kernel memory usage is not changed. So, at least, you have to add some address calculation (as I did in March) to getting address of page_cgroup. But page_cgroup itself consumes 32bytes per page. Then..... My proposal to 32bit system is following - remove ...

On Tue, 9 Sep 2008 15:00:10 +1000 I'll add a new patch on my set. Balbir, are you ok to CONFIG_CGROUP_MEM_RES_CTLR depends on CONFIG_SPARSEMEM ? I thinks SPARSEMEM(SPARSEMEM_VMEMMAP) is widely used in various archs now. Thanks, -Kame --

Does this apply to smp_send_reschedule() as well? A [rare] codepath in the current rcu code does to trigger quiescent states on remote cpus. -- Manfred --

From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> No, the timer interrupts are controlled differently, as the IRQ source lives inside of the CPU rather in some external entity. I need to fix that by invoking tick_ops->disable_irq() here. I'll take And IPI handler runs in HW irq context, therefore such an IPI-creates-an-IPI should not be allowed, at least not directly. Actually the restriction seems to be that an IPI cannot be sent when Exactly. --

So now we just need a sane way to resize dm-multipath devices online :) -- Pasi --

Hi all, I have been looking at the USBIP stuff and don't understand the generic probe issues. In your second patch: static struct usb_device_id stub_table[] = { +#if 0 + /* just an example */ + { USB_DEVICE(0x05ac, 0x0301) }, /* Mac 1 button mouse */ + { USB_DEVICE(0x0430, 0x0009) }, /* Plat Home Keyboard */ + { USB_DEVICE(0x059b, 0x0001) }, /* Iomega USB Zip 100 */ + { USB_DEVICE(0x04b3, 0x4427) }, /* IBM USB CD-ROM */ + { USB_DEVICE(0x05a9, 0xa511) }, /* LifeView USB cam ...

It is unfortunate that these two words have been used in multiple ways, with meanings that are sometimes only subtly different and sometimes grossly conflicting. Isn't it standard in networking circles for "server" to mean the system running a daemon that waits for incoming connections and "client" to mean the system running an on-demand program that initiates a Okay, "controller" and "target". I'm not sure that "controller" is the best word either, since it might be confused with "USB ...

Thanks for fixing this up, Seth. I just applied it to my linux-next branch. Jesse --

NetworkManager can see access points, but doesn't get much further than that. From an end user perspective, similar to how it behaved in 2.6.26, before Dave's wext compat fixes. Alex --

By the way, that description is incorrect; the change was in the other Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved all WEXT cases. This code is (and was) using wireless_send_event() and I did not find clear changes to its use in Dave's patch set. Was that supposed to be fixed with the compat ioctl patches? I'm not very familiar with this area and don't have an easy way to test this now (I'm traveling and don't have access to a 64/32-bit setup). As far as I ...

Are you using 802.11n? Dave's patches fixed scan result processing, but it looks like they may not have fixed wireless_send_event() processing. It would be interesting to see what wpa_supplicant debug log shows here. I would assume the device was able to associate with the AP, but something went wrong when the association information (the data that was changed to use binary format instead of text-based custom iw event). -- Jouni Malinen PGP id ...

From: Jouni Malinen <j@w1.fi> If we're talking about the netlink emission of WEXT blobs, then such bits cannot be fixed unfortunately, because via netlink we don't know in the message generating context what kind of process will receive the message. In fact, when broadcasting a netlink message, applications of different dispositions can want to receive the message. So in essence netlink cases cannot be fixed for COMPAT handling, rather, netlink protocols must be designed to be COMPAT ...

I'm so entirely tired of reading these 300+ column emails today that I'm just flat out refusing to read this one. People, fix your setup please! And if you have to get your email client to auto format your outgoing email text for you, that's fine. Although I can't understand why folks are too lazy to type enter every 80 columns or so. It's funny how something so fundamental that everyone could get right 15 years ago, is now such an epidemic problem. :-/ --

Though regression was not reported, it is actually a regression internally. It doesn't have a big impact against the hotplug controller that supports "command completed interrupt", but it might have a impact against the controller that doesn't support "command completed interrupt". So I think it should go into 2.6.27. As you said, the patch looks good and simple. Thanks, Kenji Kaneshige --

I don't have a preference here; whatever is most useful for people is probably what we should go for. Zhao? Thanks, Jesse --

On Mon, 08 Sep 2008 10:11:46 -0600 Taking a spinlock outside lock_kernel() isn't good, and is quite unusual. - It might be ab/ba deadlockable (I didn't check) (I trust you always test with lockdep enabled?) - will make Ingo unhappy when he applies his "make lock_kernel use mutex_lock" patch (if it's still around). - will probably give the -rt guys conniptions. swapping the above two lines would presumably be an easy fix, but one wonders whether we still need lock_kernel() in ...

That used to be the case, but the mutex_lock() version of the bkl got yup. --

Indeed - and, as Alan said, lock_kernel() can sleep (a nuance I had not realized until looking more into the kernel locking mechanisms just now). Although I have seen no issues during testing (and I do have lockdep in the kernel), you are 100% right. I had wanted to keep from disturbing the locking situation in n_tty, but maybe it is time to get rid of the BKL there. My echo buffer patches actually isolate the tty column state stuff to the output processing functions now anyway, so the BLK ...

The driver output side can sleep, and it has to be able to sleep because the drivers like USB need to be able to sleep. If you have the column handling isolated and locked that is a big step towards exterminating the BKL in the n_tty code. It also illustrates why locking people always say "lock data not code". Alan --

Btw, I'm assuming you'll be queuing this up, Geert. Let me know if you want to do otherwise... Thanks, Jesse --

Hi Kenji-san, As always, thank you very much for the excellent review. Sorry for the delay; I've been busy with travel, and trying to figure out how to solve the issue you pointed out below. Yes, you are right, that is a problem. I've taken the following approach: - the above code is providing a mechanism to allow a _hotplug_ driver to override a _detection_ driver slot name. - in other words, we only have to worry about the case when a _detection_ driver was loaded ...

Just have chance to re-check the problem. I have spotted the place that strace misbehaves when SIGTRAP is blocked by task being straced with -f flag (follow trace) The problem is that after debugee blocking SIGTRAP the task's exec path would not wake up debugger (strace) with this signal. But strace don't know about it, and expect such a wake up. Upon receiving a subsequent wake up,strace still thought it was a wake up from "SIGTRAP in previous exec path". From now on, Debuger and Debugee ...

It should be quite obvious that 'dma_base' will never be 0 since It should print "MMIO-DMA" since the registers are memory-mapped. Making another notch... MBR, Sergei --

If we get false negatives that is quite frankly their problem, not ours. If nothing else, we should be able to look for a host bridge with the VMWare vendor ID -- that should arguably be safer than DMI. -hpa --

Yeah, I agree with you, it's a bad method. I just took it for granted that vmware has done the necessary study and they knew what they were doing. I have tested it on two boxes so I thought they were OK. Now I They haven't done this. Per VMware's design, the cpuinfo in virtual guest is identical to the underlying physical CPU. I guess they want to send most of the code to run on underlying CPU directly and won't I think they didn't use this way cause VMware wanted it to be Some people ...