Hi all again, Here it is another little Oops we found: echo 0 > /dev/cgroups/0/cpu.rt_period_us or echo 4294967296 > /dev/cgroups/0/cpu.rt_period_us [ 205.509825] divide error: 0000 [#1]=20 [ 205.510151] Modules linked in: [ 205.510151]=20 [ 205.510151] Pid: 2339, comm: bash Not tainted (2.6.26-rc8 #33) [ 205.510151] EIP: 0060:[<c030c6ef>] EFLAGS: 00000293 CPU: 0 [ 205.510151] EIP is at div64_u64+0x5f/0x70 [ 205.510151] EAX: 0000389f EBX: 00000000 ECX: 00000000 EDX: 00000...

Your statements clearly indicate that you have never worked yet and are slowly discovering the business world. I would like to return the challenge to you : show me one software company still in business and making profit who has not set a few patents on (provably obvious) methods they rely on. Trade secrets don't work anymore because once discovered, you're attacked by their patent holder (since everything is patented in this crappy world). There are no trade secrets in software, everything is d...

Makes sense to me. Thanks. Acked-by: Vivek Goyal <vgoyal@redhat.com> Thanks Vivek --

native_read_tscp shifts the bits in the high order value in the wrong direction, the attached patch fixes that. Signed-off-by: Max Asbock <masbock@linux.vnet.ibm.com> diff -pburN linux/include/asm-x86/msr.h linux.rdtscp/include/asm-x86/msr.h --- linux/include/asm-x86/msr.h 2008-06-20 11:51:17.000000000 -0700 +++ linux.rdtscp/include/asm-x86/msr.h 2008-06-25 14:26:35.000000000 -0700 @@ -18,7 +18,7 @@ static inline unsigned long long native_ unsigned long low, high; asm volatile(".byte ...

This patch series adds a new interface /sys/firmware/memmap to export the BIOS (Firmware) provided memory map via sysfs for usage with kexec. While the first patch adds the generic interface, the second patch implements that interface for E820 on x86. EFI is on the TODO list, and other architectures can be added later. This patch is RFC. It has been tested on x86-64 and i386 and replaces my previous attemt that adds such an interface via procfs. Signed-off-by: Bernhard Walle <bwalle@suse...

Hi Bernhard, Thanks for the patch. Couple of thoughts. Do we really need another CONFIG option (CONFIG_FIRMWARE_MEMMAP)? To, me this does not seem to be a big chunk of code at the same time I am assuming that most of the people will use it (because of kexec). So probably, it might not make lot of sense to put additional CONFIG option. How about leaving the decision of memory type on arch dependent code? How about letting arch code pass you an string while adding entry and that string will ...

Hello, on my AthlonXP 1700 PAT works fine (I tested it several days). Please accept one of the patches below, I don't know which you refer. Signed-off-by: Bernd Schubert <bernd-schubert@gmx.de> Patch to enable PAT specifically on model=6 diff --git a/arch/x86/kernel/cpu/addon_cpuid_features.c b/arch/x86/kernel/cpu/addon_cpuid_features.c index c2e1ce3..61a5aa5 100644 --- a/arch/x86/kernel/cpu/addon_cpuid_features.c +++ b/arch/x86/kernel/cpu/addon_cpuid_features.c @@ -57,6 +57,8 @@ voi...

Well, if I provide a link, I might as well look at it myself I guess... Earlier patches on linux-kernel did the white->black list switching but as you can see that in linux-next at least all of AMD is already whitelisted. Rene. --

Hi Oleg, I'm currently porting -rt to 26-rc7 and I came across this change: Commit: 8e60e05fdc7344415fa69a3883b11f65db967b47 With the - double_spin_lock(&new_base->lock, &old_base->lock, - smp_processor_id() < cpu); + spin_lock(&new_base->lock); + spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING); What's the reason that this is possible? Is it because the migration happens only on CPU hotplugging and that the CPU hotplugging code has locks...

This patch brings back limiting of the E820 map when a user-defined E820 map is specified. While the behaviour of i386 (32 bit) was to limit the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to limit. That patch limits the E820 map again for both x86 architectures. Code was tested for compilation and booting on a 32 bit and 64 bit system. Signed-off-by: Bernhard Walle <bwalle@suse.de> --- arch/x86/kernel/e820.c | 5 +++++ 1 files changed, 5 insertions(+), 0 ...

I have seen past postings on this topic and there still seems to be issues. Since adding process i/o stats to collectl I've been looking more closely at process stats in general and have been digging deeper into how memory is being accounted for on my current test system which is running a 2.6.23 kernel on top of a rhel4.2 distribution and have been using 'man proc' as a guide. Specifically, I realize stats are reported in /proc/pid/stat, /proc/pid/statm and /proc/pid/status and according to...

your /proc/interrutps showed just eth1, and it was on IRQ 177 -- was that from a different boot than this dmesg? in any case, when you boot these on a new kernel they should both show up on IRQ 18 (because they're on GSI 18). Also, these IOAPIC interrupts are not programmable -- they are hard-coded, so the issue is not in the ACPI PCI interrupt link programming code. -Len --

I would like to attend and I'd like to discuss the new framework for suspending and resuming devices and related things (like example implemetations of the new callbacks, the handling of wake-up etc.). Thanks, Rafael --

On Wed, 25 Jun 2008 19:58:20 +0200 pci_resource_flags() returns an unsigned long. But I think you're right and resource.flags is wrong. Because there's no way in which we'll ever be able to use bits 32-63 of that field anyway. I suppose that Someone(tm) should convert resource.flags to a u32 or something. Minor issue. --

semi-arguably, the pnp_get_resource() is simply wrong though, so maybe this patch. After this, the quirks one should indeed be an unsigned long also. Bjorn? Rene.

some functions need to be moved to setup_numa.c after we merge setup32/64.c, some funcs need to be moved back to setup.c Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c deleted file mode 100644 index a81d82c..0000000 --- a/arch/x86/kernel/setup.c +++ /dev/null @@ -1,525 +0,0 @@ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/init.h> -#include <linux/bootmem...

Linus, Arjan has been observing lots of softlockup reports on kerneloops.org and would like to have the patch below in v2.6.26 to narrow the real source of it down some more, and has asked for this patch to be applied sooner than planned. The patch is queued up for the next merge window at the moment. It's well-tested and obvious. The module list is printed here the same way it's printed for oopses. Discard it if you feel in any way nervous about it. Ingo ----------------> co...

This patch contains the following cleanups: - make the following needlessly global variables static: - required_kernelcore - zone_movable_pfn[] - make the following needlessly global functions static: - move_freepages() - move_freepages_block() - setup_pageset() - find_usable_zone_for_movable() - adjust_zone_range_for_zone_movable() - __absent_pages_in_range() - find_min_pfn_for_node() - find_zone_movable_pfns_for_nodes() Signed-off-by: Adrian Bunk <bunk@kernel.org> ...

applied. thanks, -len --

This patch makes the needlessly global register_page_bootmem_info_section() static. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- This patch has been sent on: - 5 May 2008 070dc3db481a222a79755b6a06fb300f022ff56e diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index b3fd604..6a9a28a 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -86,7 +86,7 @@ void put_page_bootmem(struct page *page) } -void register_page_bootmem_info_section(unsigned long start_pfn...

When the driver was removed back in 2002 the option was forgotten. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 7698eb0f092f61d2f1d4d99cd7150018d4ddb6fe diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 55ea52f..8012ff7 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -578,18 +578,6 @@ config MAC_HID depends on INPUT_ADBHID default y -config ADB_KEYBOARD - bool "Support for ADB keyboard (old driver)"...

The h8300 and sparc options somehow survived when the code stopped using CONFIG_UNIX98_PTY_COUNT. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/h8300/Kconfig | 14 -------------- arch/sparc/Kconfig | 14 -------------- 2 files changed, 28 deletions(-) 153f95e9cbfc5292daf1b115392e5fb231490aaf diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index 085dc6e..396ab05 100644 --- a/arch/h8300/Kconfig +++ b/arch/h...

This option was forgotten when the SCSI_QLOGIC_FC driver was removed. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 92547181b79610ddd207a9cdbea35653a1d63b8a diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 81ccbd7..a72993c 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1305,14 +1305,6 @@ config SCSI_QLOGIC_FAS To compile this driver as a module, choose M here: the module will be called ...

I just pulled from Linus and now it stalls to boot at [ 0.616031] pnp: PnP ACPI init [ 0.628031] ACPI: bus type pnp registered [ 0.640031] pnp: PnP ACPI: found 7 devices [ 0.652031] ACPI: ACPI bus type pnp unregistered [ 0.660031] SCSI subsystem initialized [ 0.664031] PCI: Using ACPI for IRQ routing [ 0.692031] PCI-GART: No AMD northbridge found. The kvm process is at 100% time. Taking the many problems I already reported about, 2.6.26 probably will be entirely broken re...

Linux uses its own routines in these cases - and in fact for MMX we The beauty of the Linux kernel being source based - we don't have to worry about ABI problems like this. Alan --