Is this something people are interested in seeing? WARNING: vmlinux.o(.text+0x1422b): Section mismatch in reference from the function set_pte_phys() to the function .init.text:spp_getpage() The function set_pte_phys() references the function __init spp_getpage(). This is often because set_pte_phys lacks a __init annotation or the annotation of spp_getpage is wrong. WARNING: vmlinux.o(.text+0x1429a): Section mismatch in reference from the function set_pte_phys() to the function .init.text:s...

From: Paul Jackson <pj@sgi.com> Remove bitmap_scnprintf_len and cpumask_scnprintf_len. They aren't used. They were briefly used as part of some other patches to provide an alternative format for displaying some /proc and /sys cpumasks. They probably should have been removed when those other patches were dropped, in favor of a different solution. Signed-off-by: Paul Jackson <pj@sgi.com> Cc: "Mike Travis" <travis@sgi.com> Cc: "Bert Wesarg" <bert.wesarg@googlemail.com> ...

Hi all, I've updated today to 2.6.26-rc1-00166-gc0a1811 , running an 64bit kernel at the moment. dmesg shows here : ... [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000) [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4 [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753 [4294014.506571] Kernel command line: ...

2.6.25* , tested 2.6.25-git* , 2.6.26-rc1 , and 2.6.26-rc1-00065-g5717922. From my log 2.6.26-rc1-00065-g5717922 was fine. ... May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000) May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 r...

[cc: linux-scsi] --- ~Randy --

Hi. The line in the subject is printed on the screen at every boot. It never happened before. Is it something to worry about? Also, there is this new line: BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor) FWIW, the machine is an HP DV4378EA laptop, so if there's someone from HP listening... cheers, Fabio --

Cpuset proc code is directly playing with seq_file internals, for that add seq_bitmap() and wrappers around it: seq_cpumask() and seq_nodemask(). They use NR_CPUS and MAX_NUMNODES bits respectively. Also they will be used by code /proc/irq/*/{smp_affinity,spurious} code. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- fs/seq_file.c | 15 +++++++++++++++ include/linux/seq_file.h | 12 ++++++++++++ kernel/cpuset.c | 12 ++++-------- 3 files changed, 31 ...

from commit ec92d08292d3e9b0823eba138a4564d2d39f25c7 The wakeup ordering should be in priority order. However if the priority of a task is modified while it's waiting on the futex you will get an out of order wakeup. If you use a priority inheriting mutex this is correct. It's because the rtmutex hooks into sched_setscheduler to catch any priority changes, then re-queues with the new priority.. But the futex doesn't have this hook. Was this intentionally left out of this priority wake up p...

On Thu, 8 May 2008 02:14:50 +0400 There was a reason most of those 1:1 wrappers but yes, this one seems to be Does Paul have an opinion? (Well, Paul always has an opinion. But what is it?) --

Hi Tom, Jens, My build system started reporting these error messages recently. Reverting commit c3270e577c18b3d0e984c3371493205a4807db9d on top of 2.6.26-rc1 gets things working for me again. -- Dan --

In many cases, especially in networking, it can be beneficial to know at compile time whether the architecture can do unaligned accesses efficiently. This patch introduces a new Kconfig symbol HAVE_EFFICIENT_UNALIGNED_ACCESS for that purpose and adds it to the powerpc and x86 architectures. Also add some documentation about alignment and networking, and especially one intended use of this symbol. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Sam Ravnborg <sam@ravnbor...

I just tried it, and it ends with "Zach Brown". We have had problems with occasional truncation of the front page; unfortunately we don't have enough info to discern any pattern what would trigger it... -hpa --

I can confirm that the problem persists on a 2.6.25.2 kernel. -- Jesper --

Page fault on NFS apparently goes into an infinite loop if the read on the server fails. I don't understand the NFS readpage code, but the filemap_fault() code looks somewhat suspicious: /* * Umm, take care of errors if the page isn't up-to-date. * Try to re-read it _once_. We do this synchronously, * because there really aren't any performance issues here * and we need to check for errors. */ ClearPageError(page); error = mapping->a_ops->readpage(file, page); page_cache_...

When a small page mapping is created with mmap() reservations are created by default for any memory pages required. When the region is read/write the reservation is increased for every page, no reservation is needed for read-only regions (as they implicitly share the zero page). Reservations are tracked via the VM_ACCOUNT vma flag which is present when the region has reservation backing it. When we convert a region from read-only to read-write new reservations are aquired and VM_ACCOUNT is set. ...

x86.git testing found the following "possible circular locking" lockdep warning, generated by the ecryptfs code: | multipath.stati/2972 is trying to acquire lock: | (&ecryptfs_daemon_hash_mux){--..}, at: [<ffffffff80321745>] ecryptfs_miscdev_open+0x23/0x13b | | but task is already holding lock: | (misc_mtx){--..}, at: [<ffffffff8043da31>] misc_open+0x22/0xf0 | | which lock already depends on the new lock. with the following config: [ message continues ]

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- sound/i2c/cs8427.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/sound/i2c/cs8427.c b/sound/i2c/cs8427.c index e57e9cb..9c3d361 100644 --- a/sound/i2c/cs8427.c +++ b/sound/i2c/cs8427.c @@ -23,6 +23,7 @@ #include <linux/slab.h> #include <linux/delay.h> #include <linux/init.h> +#include <asm/unaligned.h> #include <sound/core.h> #include <sound/control.h>...

Suppose you had an N GB file that just filled up the disk. You now delete it, but get control back before it is really deleted. You now start to write a new file that will eventually just fill up the disk. Your task will get a media full error long before the media is really full because the old file's data space hasn't been freed yet. So, to "fix" this, you modify the file- system to defer your logical writes until all the previous spaces has been freed (writes to the physical media are deferred...

Same reason your shell waits for your program to complete before Say you had one realtime application running that would do lots of new writes after the unlink finished. When the unlink is put into the background, you interleave the unlink operation with new writes, probably causing needless seeks and therefore not hitting the deadlines anymore. For you desktop use, `rm -f foobar.avi &` should do. No? --

Code complexity. But then again, a few good filesystems don't even need to do such heavy housekeeping, and I suggest using these if you are worried about unlink speed. --

After patch 2 in this series, a process that successfully calls mmap() for a MAP_PRIVATE mapping will be guaranteed to successfully fault until a process calls fork(). At that point, the next write fault from the parent could fail due to COW if the child still has a reference. We only reserve pages for the parent but a copy must be made to avoid leaking data from the parent to the child after fork(). Reserves could be taken for both parent and child at fork time to guarantee faults but if the map...

A later patch in this set needs to call hugetlb_acct_memory() before it is defined. This patch moves the function without modification. This makes later diffs easier to read. Signed-off-by: Mel Gorman <mel@csn.ul.ie> --- mm/hugetlb.c | 82 +++++++++++++++++++++++++++--------------------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.25-mm1-revert-ide-pci-patches/mm/hugetlb.c linux-2.6.25-mm1-0010-move-hugetlb_acct_m...

Now that 2.6.26-rc1 boots on my Ultra5, I noticed that it reports having only 128MB RAM, while earlier kernels reported the correct amount: 256MB. A diff of the dmesg output from 2.6.25 and 2.6.26-rc1 shows: --- dmesg-2.6.25 2008-05-07 19:41:26.000000000 +0200 +++ dmesg-2.6.26-rc1 2008-05-07 19:41:26.000000000 +0200 @@ -1,24 +1,36 @@ PROMLIB: Sun IEEE Boot Prom 'OBP 3.25.3 2000/06/29 14:12' PROMLIB: Root node compatible: -Linux version 2.6.25 (mikpe@sparge) (gcc version 4.2.3) #1 Thu Apr 17 ...

This is somewhat improved version of strnicmp() function in lib/string.c. I have implemented binary comparison rather than linear one(which was in the older version). I am appending the patch bellow --- 2.6.25-vanilla/lib/string.c 2008-04-17 08:19:44.000000000 +0530 +++ 2.6.25-hacked/lib/string.c 2008-05-07 23:31:57.000000000 +0530 @@ -1,24 +1,3 @@ -/* - * linux/lib/string.c - * - * Copyright (C) 1991, 1992 Linus Torvalds - */ - -/* - * stupid library routines.. The optimized version...