ACK. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

On Wed, 26 Mar 2008 10:50:41 +1100 Acked-by: Alan Cox <alan@redhat.com> --

While I have no desire to defend that particular design, saying "tasteless" without suggesting an alternate approach does appear somewhat unhelpful. NeilBrown --

Hello! Current Kernels (2.6.25-rc6, commit d2532dd20a126020de407c1c2476a75b53fce7ac) results in the following link errors: CC arch/alpha/lib/udelay.o AR arch/alpha/lib/lib.a LD vmlinux.o MODPOST vmlinux.o WARNING: "saved_config" [vmlinux] is COMMON symbol WARNING: modpost: Found 22 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD ...

here are some (probably more or less minor) issues i have found in /var/log/messages & dmesg after some bigger module load/unload session - maybe someone wants to take a closer look. this one looks more serious (happened with modprobe -r ac), because kernel has problems afterwards (cannot load/anload any other module afterwards) ACPI: ACPI0007:00 is registered as cooling_device0 ACPI: Processor [CPU0] (supports 8 throttling states) BUG: unable to handle kernel paging request at 1b563b0c IP: ...

Well, Andrew should be CCed too ... Thanks, Rafael --

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 25 Mar 2008 15:11:15 -0700 (PDT) --

On Wed, Mar 26, 2008 at 08:38:22AM +1100, NeilBrown wrote: I looked at the code (xfs_ialloc.c:xfs_ialloc_ag_alloc) 290 /* 291 * Set initial values for the inodes in this buffer. 292 */ 293 xfs_biozero(fbuf, 0, ninodes << args.mp->m_sb.sb_inodelog); 294 for (i = 0; i < ninodes; i++) { 295 free = XFS_MAKE_IPTR(args.mp, fbuf, i); 296 ...

* Change the following static arrays sized by NR_CPUS to per_cpu data variables: _cpuid4_info *cpuid4_info[NR_CPUS]; _index_kobject *index_kobject[NR_CPUS]; kobject * cache_kobject[NR_CPUS]; * Remove the local NR_CPUS array with a kmalloc'd region in show_shared_cpu_map(). Also some minor complaints from checkpatch.pl fixed. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Cc: ...

Change fixed size arrays to per_cpu variables or dynamically allocated arrays in sched_init() and sched_init_smp(). (1) static struct sched_entity *init_sched_entity_p[NR_CPUS]; (1) static struct cfs_rq *init_cfs_rq_p[NR_CPUS]; (1) static struct sched_rt_entity *init_sched_rt_entity_p[NR_CPUS]; (1) static struct rt_rq *init_rt_rq_p[NR_CPUS]; static struct sched_group **sched_group_nodes_bycpu[NR_CPUS]; char str[NR_CPUS]; int ints[NR_CPUS], i; (1 - these arrays are allocated via ...

Change cpu_sys_devices from array to per_cpu variable in drivers/base/cpu.c. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git (MAINTAINER unknown) Signed-off-by: Mike Travis <travis@sgi.com> --- drivers/base/cpu.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux.trees.git.orig/drivers/base/cpu.c +++ linux.trees.git/drivers/base/cpu.c @@ -18,7 +18,7 @@ struct ...

Change cpufreq_policy and cpufreq_governor pointer tables from arrays to per_cpu variables in the cpufreq subsystem. Also some minor complaints from checkpatch.pl fixed. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Mike Travis <travis@sgi.com> --- drivers/cpufreq/cpufreq.c | 45 +++++++++++++++++++++------------------- ...

Cleanup references to the early cpu maps for the non-SMP configuration and remove some functions called for SMP configurations only. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git Cc: Andi Kleen <ak@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> --- This patch was ...

What means Hugepage? Does it mean 8KiB? 16KiB? 32KiB? 64KiB? 2MiB? 4MiB? The real page sizes of x86 and x86-64 are 4 KiB for this linux kernel. But the page sizes can be soft 8 KiB or 16 KiB or 32 KiB or 64 KiB if it is implemented in the memory manager of the kernel. But too they exist real page sizes of 2 MiB and 4 MiB that they have some reserved entries of TLB in the specs of Intel/AMD processors for these gigant pages. --

From: Daniel Yeisley <dan.yeisley@unisys.com> Commit 556a169dab38b5100df6f4a45b655dddd3db94c1 ("slab: fix bootstrap on memoryless node") introduced bootstrap-time cache_cache list3s for all nodes but forgot that initkmem_list3 needs to be accessed by [somevalue + node]. This patch fixes list_add() corruption in mm/slab.c seen on the ES7000. Cc: Mel Gorman <mel@csn.ul.ie> Cc: Olaf Hering <olaf@aepfle.de> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by: Dan Yeisley ...

Will try. There is also a Debian bug report of the same or a similar problem with kernels from 2.6.18: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415147 --

$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3200+ ... cache size : 512 KB ... The cache size is currently misinformed. It's not the real size because it's 64+64+512 KiB = 640 KiB, not 512 KB. How can i know what hw-caches use the processors? The current kernel doesn't know well what hw-caches uses. The good proposal is by example (the data below are not real): * In ...

I think you want this: /sys/devices/system/cpu/cpu0/cache /proc/cpuinfo is intended to give a general summary of certain properties of the processor that tend to be particularly interesting, and present them all in one place. It is not intended to expose everything the kernel knows about every processor on the system. -- Chris --

Well, i understand as if this cosmetic data formatting can break the grep of some applications. But if the modern PC has 6 or 8 cores then it prints an equivalent to x6 or x8 common pages in a small xterm console of 80x25 although the panoramic TFT is bigger as 23' 1900x1200 pixels. Tomorrow, 32 cores, it prints x32 instead of x8. Soon, it will need cosmetic data formatting. Hahahaha ;) --

We provide a map_error function in pci-base_32.c to make sure i386 keeps with the same behaviour it used to. Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-base_32.c | 7 +++++++ include/asm-x86/dma-mapping.h | 8 ++++++++ include/asm-x86/dma-mapping_32.h | 6 ------ include/asm-x86/dma-mapping_64.h | 8 -------- 4 files changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index ...

all the code that is left is ready to be merged as-is in dma-mapping.h Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/dma-mapping.h | 19 +++++++++++++------ include/asm-x86/dma-mapping_32.h | 23 ----------------------- include/asm-x86/dma-mapping_64.h | 17 ----------------- 3 files changed, 13 insertions(+), 46 deletions(-) delete mode 100644 include/asm-x86/dma-mapping_32.h delete mode 100644 include/asm-x86/dma-mapping_64.h diff --git ...

This is the way x86_64 does, so this make them equal. They have to be extern now in the header, and the extern definition is moved to the common dma-mapping.h header Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-dma_32.c | 33 +++++++++++++++++++++++++++++++++ include/asm-x86/dma-mapping.h | 3 +++ include/asm-x86/dma-mapping_32.h | 29 ----------------------------- include/asm-x86/dma-mapping_64.h | 4 ---- 4 files changed, 36 insertions(+), 33 ...

Do it instead of using the conservative approach we're currently doing. This is the way x86_64 does, and this patch makes this piece of code the same between them, ready to be integrated Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/dma-mapping_32.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/dma-mapping_32.h b/include/asm-x86/dma-mapping_32.h index fd7246d..d0512c9 100644 --- a/include/asm-x86/dma-mapping_32.h +++ ...

they are the same between architectures (except for the fact that x86_64 has duplicate code) move them to dma-mapping.h Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/dma-mapping.h | 10 ++++++++++ include/asm-x86/dma-mapping_32.h | 9 --------- include/asm-x86/dma-mapping_64.h | 11 ----------- 3 files changed, 10 insertions(+), 20 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 53a404b..3ea3802 100644 --- ...

i386 gets an empty function Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 9 +++++++++ include/asm-x86/dma-mapping_32.h | 6 ------ include/asm-x86/dma-mapping_64.h | 11 ----------- 4 files changed, 10 insertions(+), 17 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index 4512c30..d876600 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...

i386 gets an empty function Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 12 ++++++++++++ include/asm-x86/dma-mapping_32.h | 6 ------ include/asm-x86/dma-mapping_64.h | 11 ----------- 4 files changed, 13 insertions(+), 17 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index 9205304..dce03c8 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...

i386 gets an empty function Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 11 +++++++++++ include/asm-x86/dma-mapping_32.h | 7 ------- include/asm-x86/dma-mapping_64.h | 11 ----------- 4 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index dce03c8..3648824 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...

i386 gets an empty function Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 9 +++++++++ include/asm-x86/dma-mapping_32.h | 8 -------- include/asm-x86/dma-mapping_64.h | 8 -------- 4 files changed, 10 insertions(+), 16 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index 2474152..9205304 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...

That's already the name of the game for x86_64. For i386, we add a pci-base_32.c, that will hold the default operations. The function call itself goes through dma-mapping.h , the common header Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/Makefile | 1 + arch/x86/kernel/pci-base_32.c | 20 ++++++++++++++++++++ include/asm-x86/dma-mapping.h | 10 ++++++++++ include/asm-x86/dma-mapping_32.h | 10 ---------- include/asm-x86/dma-mapping_64.h | 9 ...

take it off the x86_64 specific header Signed-off-by: Glauber Costa <gcosta@redhat.com> --- include/asm-x86/dma-mapping.h | 54 ++++++++++++++++++++++++++++++++++++++ include/asm-x86/dma-mapping_64.h | 49 ---------------------------------- 2 files changed, 54 insertions(+), 49 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 58f790f..aebd178 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -1,5 +1,59 ...

The following features are supported: plane 0 works as a regular frame buffer, can be accessed by /dev/fb0 plane 1 has two AOIs (area of interest), can be accessed by /dev/fb1 and /dev/fb2 plane 2 has two AOIs, can be accessed by /dev/fb3 and /dev/fb4 Special ioctls support AOIs All /dev/fb* can be used as regular frame buffer devices, except hardware change can only be made through /dev/fb0. Changing pixel clock has no effect on other fbs. Limitation of usage of AOIs: AOIs on the same plane ...

Could you split some of this up into separate functions at lower (void __user *)arg As I said in an internal review, this is not enough, and it's inefficient. Read rather than write, and do so only once per cache line, but the size you access has to be at least 13/8 of the cache size for an 8-way plru cache. -Scott --

take them out of the x86_64-specific asm/mach_apic.h Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/apic_64.c | 2 +- arch/x86/kernel/cpu/amd.c | 2 +- arch/x86/kernel/io_apic_64.c | 2 +- arch/x86/kernel/setup_64.c | 2 +- include/asm-x86/mach-default/mach_apic.h | 80 ++++++++++++++++-------------- include/asm-x86/mach_apic.h | 26 ---------- 6 files changed, 47 insertions(+), 67 ...

That will dig you a nice large hole for real time to fall into. If you want to do rt nicely you want to avoid semaphores and the corresponding Better to keep ia64 perversions in the IA64 code whenever possible and lower risk for everyone else. Alan --

Generating vectorized code in the kernel is death anyway, so I don't think the change in alignment is an issue. We CANNOT ALLOW vectorized code in the kernel under any circumstances (well, except when surrounded by the appropriate protection constructs.) -hpa --

There's a nasty memory leak in firewire-ohci's ar_context_tasklet(), in that we're not freeing up some of the memory we use for each ar_buffer, due to a moving pointer. The problem has been there for a while, but didn't start to be noticed until we were doing a coherent allocation for the ar_buffer -- meaning we have a smaller pool of memory to work with now, so the problem crops up sooner. The manifestation of this comes after doing a bunch of I/O to a firewire disk, which eventually stalls, and ...

[1] "Performance changes between 2.6.13 and 2.6.23" http://lkml.org/lkml/2008/3/25/102 It's the velocity, ctxts/interval, a parameter not recognized by the scheduler. I said them to put the proposal of putting the counters and velocities fields to the task's struct for the scheduler can take a good decision, the past month. More weight in higher ctxts/s for the scheduler=> more interactivity. [2] "Re: Serious performance regression in Wine applications and Linux ...

There are already counters recording the switches: My parents were married. --

Ran patches through scripts/Lindent. Signed-off-by: Dean Nelson <dcn@sgi.com> --- drivers/misc/xp/xp.h | 115 ++++------ drivers/misc/xp/xp_main.c | 109 ++++------ drivers/misc/xp/xp_sn2.c | 52 ++-- drivers/misc/xp/xp_uv.c | 7 drivers/misc/xp/xpc.h | 368 ++++++++++++++-------------------- drivers/misc/xp/xpc_channel.c | 379 +++++++++++++----------------------- drivers/misc/xp/xpc_main.c | 329 ...

Forgot to mention that scripts/checkpatch.pl gave 15 false positives of The fact is that the EXPORT_SYMBOL(xp_remote_memcpy) does immediately follow the function/variable as follows. enum xp_retval (*xp_remote_memcpy) (void *dst, const void *src, size_t len); EXPORT_SYMBOL_GPL(xp_remote_memcpy); --

[Empty message]

This set of five patches moves XPC and XPNET to drivers/misc/xp in preparation for enabling X86_64 support. --

Part 2 (which I got since you addressed it to me directly as well as to the list) has a couple of "Space in indent is follwed by a tab" complaints from GIT. Part 3 has one too. Apart from that all five parts apply and the build is clean on all my configs. Boots on the tiger (but this doesn't constitute a review ... just a "you didn't I think git has an option to produce its own brand of diff output that lists the renames without doing a full remove & add which is needed for patch(1) ...

By including processor-flags.h we are allowed to use predefined macroses instead of keeping own ones Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- I've tried to bring as minimum changes as possible during this patch (even checkpatch was not being started 'cause I know it will require reformat much more lines that are touched by this patch. Anyway, if someone wants me to do so - no problem just say ;) Please review entry_32.S | 20 +++++++------------- 1 file changed, 7 ...

kafs doesn't check if the cell already exists - so if you do an echo "add newcell.org 1.2.3.4" >/proc/fs/afs/cells it will try to create this cell again. kobject will also complain about a double registration. To prevent such problems, return -EEXIST in that case. Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: David Howells <dhowells@redhat.com> --- fs/afs/cell.c | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) diff --git a/fs/afs/cell.c ...

What do you use as a benchmark for writing large sequential files or reading them, and why is it better than dd at modeling programs which read or write in a similar fashion? Media programs often do data access in just this fashion, multi-channel video capture, streaming video servers, and similar. -- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot --

Unfortunately this shows the same trend as kernel compile, small database operations, etc. If you are using a journaling filesystem on 2.6 and not 2.4 be sure you have the filesystem mounted "noatime" or retest with a non-journaled f/s. If you are running LVM in the test all bets are off as there are alignment issues (see linux-raid archives) to consider. But the trend has unfortunately been slower, and responses demanding you use another benchmark, saying that kernel compile is not a ...

dd has been capable of doing direct io for years, so I assume it can emulate that behavior if it is appropriate to do so, and the buffer size can be set as needed. I'm less sure that large buffers are allocated on the stack, but often the behavior of the application models is the small And this is what I was saying earlier, there is a trend to blame the benchmark when in fact the same benchmark runs well on 2.4. Rather than replacing the application or benchmark, perhaps the *regression* ...

It means you shouldn't use dd as a benchmark. -- Chris --

Calling drop_pagecache_sb() without having a reference to 'sb'? Surely not... Trond --

I've been seeing list_add corruption in slab.c on the ES7000 since the 2.6.24.1 kernel. There are several places where the initkmem_list3 array is access by [somevalue + node]. This also needs to be done in kmem_cache_init(). Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com> --- diff -Naur linux-2.6.25-rc5/mm/slab.c linux-2.6.25-rc5-new/mm/slab.c --- linux-2.6.25-rc5/mm/slab.c 2008-03-10 01:22:27.000000000 -0400 +++ linux-2.6.25-rc5-new/mm/slab.c 2008-03-20 13:59:24.000000000 -0400 @@ ...

Hi Daniel, Good catch! You'd need to fix up the use of initkmem_list3 farther Care to send a tested patch that fixes that as well? Pekka --

I actually saw that initkmem_list reference, but didn't change it since my original patch fixed my list corruption. Anyway, I made the changed and tested it. The system booted fine. Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com> --- diff -Nuar linux-2.6.25-rc6/mm/slab.c linux-2.6.25-rc6-new/mm/slab.c --- linux-2.6.25-rc6/mm/slab.c 2008-03-25 15:39:07.000000000 -0400 +++ linux-2.6.25-rc6-new/mm/slab.c 2008-03-25 15:13:01.000000000 -0400 @@ -1481,7 +1481,7 @@ ...

Hi Daniel, Yeah, but the second change is needed; otherwise we forget to fix up some of the bootstrap caches. > Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com> Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> Mel, as this change is related to the memoryless node fix that went in 2.6.24, any chance you'd give this patch a spin on your machines so we can get the fix in 2.6.25 and 2.6.24-stable? Pekka --

For example, If the physical address layout on a two node system with 8 GB memory is something like: node 0: 0-2GB, 4-6GB node 1: 2-4GB, 6-8GB Current kernels fail to boot/detect this NUMA topology. ACPI SRAT tables can expose such a topology which needs to be supported. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> --- diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 227fdb0..99eb102 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -880,6 +880,15 @@ config ...

Hi Greg, This is v12 of the physical pci_slot series. I had to do one last respin because I misspelled Kenji-san's name in the changelog. I've also added his Acked-by. There are no code changes between v11 and v12. Sorry for the noise. Thanks. /ac --

Export kobject_rename() to fix the following link error. This happens when pci_hotplug_core driver is compiled as a kernel module. ERROR: "kobject_rename" [drivers/pci/hotplug/pci_hotplug.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 make: *** Waiting for unfinished jobs.... Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: Alex Chiang <achiang@hp.com> --- lib/kobject.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff ...

Detect all physical PCI slots as described by ACPI, and create entries in /sys/bus/pci/slots/. Not all physical slots are hotpluggable, and the acpiphp module does not detect them. Now we know the physical PCI geography of our system, without caring about hotplug. v10 -> v12: Thanks to Kenji Kaneshige for the following updates: - Fix dmi table for Fujitsu PRIMEQUEST - Fix _STA evaluation - Use list_head for pci slot list - Fix slot removal path v9 -> v10: Allow an hp driver to ...

Implement GPIO LIB API on CPM1 Freescale SoC. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- This is based on the series starting at http://patchwork.ozlabs.org/linuxppc/patch?id=17299 arch/powerpc/platforms/8xx/Kconfig | 2 + arch/powerpc/sysdev/cpm1.c | 240 +++++++++++++++++++++++++++++++++++- 2 files changed, 241 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig index 7fd224c..e12cbf0 100644 --- ...

Sorry for the triple mail, it appeared to fail twice. --

from include/linux/ieee80211.h:274: #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 --- ! has a higher priority than & Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c index d727de8..6576757 100644 --- a/drivers/net/wireless/iwlwifi/iwl-4965.c +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c @@ -4589,7 +4589,7 @@ static u8 iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv, if ...

This patch has already been acked and merged into wireless-testing, and afaik already pushed further upstream. Reinette --

from include/linux/ieee80211.h:274: #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 --- ! has a higher priority than & Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c index d727de8..6576757 100644 --- a/drivers/net/wireless/iwlwifi/iwl-4965.c +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c @@ -4589,7 +4589,7 @@ static u8 iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv, if ...

Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com> --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. z siedziba w Gdansku ul. Slowackiego 173 80-298 Gdansk Sad Rejonowy Gdansk Polnoc w Gdansku, VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, numer KRS 101882 NIP 957-07-52-316 Kapital zakladowy 200.000 zl This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). ...

Indicate that HEA calculates IPv4 checksums only Signed-off-by: Thomas Klein <tklein@de.ibm.com> --- diff -Nurp linux-2.6.24.4.org/drivers/net/ehea/ehea.h linux-2.6.24.4/drivers/net/ehea/ehea.h --- linux-2.6.24.4.org/drivers/net/ehea/ehea.h 2008-03-25 12:42:18.000000000 +0100 +++ linux-2.6.24.4/drivers/net/ehea/ehea.h 2008-03-25 13:13:29.000000000 +0100 @@ -40,7 +40,7 @@ #include <asm/io.h> #define DRV_NAME "ehea" -#define DRV_VERSION "EHEA_0083" +#define DRV_VERSION "EHEA_0083a" ...

When a tracer exits without detaching from the traced process, the tracee may be at a tracer notification stop and will thus interpret the value in task->exit_code (SIGTRAP | 0x80) as the signal to be delivered. This patch fixes the problem by clearing exit_code when detaching the traced process from a dying tracer. Signed-off-by: Petr Tesarik <ptesarik@suse.cz> --- exit.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/kernel/exit.c +++ b/kernel/exit.c @@ ...

Additional note. Suppose that the tracee dequeues the "good" signal, notices PT_PTRACED and calls ptrace_stop(). We set TASK_TRACED under ->siglock, without holding tasklist_lock. At this moment you kill strace, it clears ->exit_code. The tracee notices it is not traced any longer and returns to get_signal_to_deliver(). Since ->exit_code is cleared, the "right" signal is lost. So I think this patch adds a race. In some sense (yes I am biased) this is even worse than the problem this patch ...

This patch needs Roland's opinion. I can't really judge, but I have some (perhaps wrong) doubts. This reduce the likelihood that the tracee will be SIGTRAP'ed, but doesn't solve the problem, no? Suppose that the tracee does send_sigtrap(current) in do_syscall_trace() and then ptracer exits. Or ptracer wakes up the TASK_TRACED tracee without clearing its ->exit_code and then you kill(ptracer, SIGKILL). If we really need this, _perhaps_ it is better to change do_syscall_trace(), so that ...

In that case it might be interesting to observe the number of context switches per second caused by the different processes. If the product of the context switch time reported by lmbench2 and the number of context switches per second is more than about 0.1, this means that a lot of time is spent in just context switching and the application probably should be optimized to cause less context switches. This holds for any OS. On a Linux system you can observe the number of context ...

P0 should also work fine with cpu hotplug. At least in theory. -Andi --

maxcpus=3D1 should turn off the SMP alternative and switch to UP only, optimising some locks and instructions. --=20 Luciano Rocha <luciano@eurotux.com> Eurotux Inform=E1tica, S.A. <http://www.eurotux.com/>

CPU hot unplug will do the same. But it is unlikely it accounts for that much performance difference. If he used maxcpus=0 it would make sense. maxcpus=0 disables the IO-APIC which likely makes a large difference. But it should be actually slower. There should be actually no difference in theory between max_cpus=1 and hot unplug to one CPU. Might be some bug. -Andi --

I had the following time values: maxcpus=1: real 0m1.642s user 0m1.528s sys 0m0.068s maxcpus=2 and echo 1 > /sys/devices/system/cpu/cpu1/online: real 0m2.579s user 0m4.096s sys 0m0.160s maxcpus=2 and echo 0 > /sys/devices/system/cpu/cpu1/online: real 0m3.757s user 0m3.632s sys 0m0.112s Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go --

We provide data services to our clients. We are already seeing USB enclosures routinely provided to us by our clients with 1TB. 1.5TB on occasion. 2TB usb enclosures can't be far behind. For usb a bigger factor than anything is when will MS offer compatibility/supportfor 2TB+ drives. As soon as they become readily supported in MS, our clients will start buying them and filling them up and we will need to be able to access them from all of our systems. (old and new). Greg -- Greg ...

Absolutely - they more or less hit a stonewall once the disk has any trouble and you need to fsck. On the other hand, this might be merciful since on 64 bit boxes, we will let you run the fsck and watch it run for a week or so before you despair ;-) On a serious note, fsck time tends to track more the number of active inodes, so you can fsck a large file system if you use it to store large files (especially if you use a file system with dynamic inode creation or something like the ...

I can attest to this. I hear from a reliable source (manufacturer) that 2TB 3.5" disks will be out no later than first half of 2009 (possibly even sooner, or at least 1.5TB). I currently use 1TB disks with a Geode LX based motherboard for SATA RAID and I plan on upgrading/consolidating to larger sizes once they become available in the market. 64-bit is not an option for me on this hardware. -Andrew --

Well 2TB, assuming a 4k blocksize, means a block bitmap is 512 megs. So at least for ext3, 4GB should be just enough, unless you hit certainly really nasty complicated corruptions (i.e. large number of blocks claimed by more than one inode, which can happen if an inode table is written to the wrong location on disk --- on top of some other portion of the inode table), or if the filesystem has a large number of files with hard links (such as the case with certain backup programs). The plan is ...

Hello! Oldalunk cime: http://tavasz.letoltes.org/ Szeretnenk veletek megismertetni Magyarorszag egyik legnagyobb letoltohelyet, ahol minden vagyad teljesulhet. A tartalom folyamatos frissites alatt all. Az oldalunkon a tartalom nem atveres, mint a tobbi warez oldalon, de ezt te is leellenorizheted. A kozel 16 TB-nyi adatot 1 SMS araert elerheted, garantalt sebesseg es adatkorlatozas nelkul. Amennyiben problemad adodna 100 szazalekos support var a ...

So, two processors, and multiple processes passing data back and Many more context switches per second, so a lot less work is getting A lot has changed between 2.6.23 and current mainline as well. Particularly in the scheduler, which I suspect is the issue for your test. If possible, could you try a 2.6.25-rc-latest kernel, both before and after an "echo 5 > /proc/sys/kernel/sched_features" and see if that makes any difference? --

This is likely a code pessimization because "current" is inline assembler and many gcc versions cannot CSE it. -Andi --

there's actually not that many explicit calls to either set_task_state or __set_task_state in the entire tree, and a lot of those don't count as they really are setting the state for a different task or for some other reason. in fact, here's the entire list for the whole tree: $ grep -r set_task_state * arch/powerpc/kernel/semaphore.c: __set_task_state(tsk, TASK_UNINTERRUPTIBLE); arch/powerpc/kernel/semaphore.c: set_task_state(tsk, ...

It is not unsafe, just generates slight worse code. current is inline assembler and the compiler doesn't know that it could cache it in a register because it is not marked pure for various reasons. That is why current is often cached explicitely in a local variable to tell the compiler that. Before you run off and do that everywhere: it is also not a large win, just a small one unless current is used very often. -Andi --

Linus, Please pull the i2c subsystem fixes for Linux 2.6.25 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus drivers/i2c/busses/Kconfig | 2 +- drivers/i2c/busses/i2c-omap.c | 36 ++++++++++++++++++++++++++++-------- drivers/i2c/i2c-core.c | 4 ++-- sound/soc/codecs/tlv320aic3x.c | 2 -- 4 files changed, 31 insertions(+), 13 deletions(-) --------------- Bryan Wu (1): i2c-bfin-twi: Disable BF54x support for now Jean Delvare (1): ...

Hello List, I am writing a linux kernel module, and I want to allocates the memory in a way so I can define each individual bit, like bitfield structure in userspace. Please tell me the way to do the same. Thanks and regards, Shard Gupta --

Linus, please pull from the repo and branch git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git for-linus The patches fix a memory leak, ioperm() failures on unrelated processes on the host, a locking issue, and a host crash when host userspace changes the memory map. Diffstat, shortlog and individual patches follow: arch/x86/kvm/mmu.c | 18 ++++++++++++++---- arch/x86/kvm/vmx.c | 7 ++----- 2 files changed, 16 insertions(+), 9 deletions(-) Avi Kivity (3): KVM: ...

Pulled. And looking at the diffs, I see sequences like dget(save.dentry); mntget(save.mnt); ... path_put(&save); which looks very strange compared to the natural sequence: path_get(&save); .. path_put(&save); and yes, I realize the code was just moved (and the reason for the mixing is that the "path_put()" conversion was done much more aggressively, as the ordering matters), but I'm bringing this up in the hope somebody has the energy to clean things like up some ...

On Tue, Mar 25, 2008 at 9:15 AM, Bart Van Assche Found the cause: apparently this is what happens when the path containing the kernel source tree contains a colon. Renaming the kernel source tree directory solved this issue. Bart. --

Hello, When I try to compile the latest git tree (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git, last change Tue, 25 Mar 2008 06:24:16 +0000), make halts and prints an error message. This happens both with GNU make version 3.79.1 and version 3.81. The 2.6.24.3 kernel builds fine on my system with the same tools, and that the Documentation/Changes document has not been changed since 2.6.24.3. Does anyone know how I can get around this ? # gmake --version GNU Make ...

ocfs2 link/build problem with CONFIG_OCFS2_FS=y CONFIG_OCFS2_FS_O2CB=m ERROR: "dlmunlock" [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: "dlm_setup_eviction_cb" [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: "dlm_register_eviction_cb" [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: "dlm_register_domain" [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: "dlm_unregister_domain" [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: "dlm_unregister_eviction_cb" [fs/ocfs2/ocfs2_stack_o2cb.ko] ...

OK, note previous question: what is the motivation for having this as a whitelist (as opposed to a blacklist)? -hpa --

Yes, using a whitelist of this type is wrong, IMO, and smells faintly of vendor-lockin. -hpa --

thanks, applied - we need this to widen the testing scope of the PAT changes. Ingo --

[PATCH] x86: pat cpu feature bit setting for known cpus Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index eb94460..b186047 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -309,6 +309,19 @@ static void __cpuinit early_get_cap(struct cpuinfo_x86 *c) } + clear_cpu_cap(c, X86_FEATURE_PAT); + + switch (c->x86_vendor) { + case X86_VENDOR_AMD: + if (c->x86 >= 0xf && c->x86 <= ...

well, the upside would be that since most testing of Linux kernels is done on _old_ hardware (people tend to risk their old hw first ;-), we'd get faster convergence of the codebase, even though we have the risk of erratas (known and unknown ones alike). Code that artificially limits its utility is almost always slow to stabilize. Ingo --

if the PAT works, we may need to trim the memory according to MTRR, right? YH --

Here are two PCI fixes for your 2.6.25-rc6 git tree. They are: - revert a troublesome PCI patch - iommu lockdep reporting fix Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/ All of these patches have been in the -mm tree for a while, as well as -next. thanks, greg k-h ------------- drivers/pci/intel-iommu.c | 7 +++++++ drivers/pci/pci.c | 21 --------------------- include/linux/pci.h | 4 ---- 3 files changed, 7 ...

Here are 2 patches against your current git tree that do: - fix UIO to work properly on ARM and other platforms - remove BUG in sysfs and add better debugging for attributes that overflow the buffer provided by sysfs. Andrew asked that this patch go in now to help people out. Both of these patches have been in -next and -mm for quite a while. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message ...

Here are some USB fixes against your 2.6.25-rc6 git tree. It includes: - more device id updates - minor bugfixes Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ All of these patches have been in the -mm tree for a while, as well as -next. The full patches will be sent to the linux-usb mailing list, if anyone wants to see them. thanks, greg k-h ------------ drivers/net/usb/rtl8150.c | 2 +- drivers/usb/core/message.c ...

Hi Oleg, Thanks for some patches about tasklist_lock. The avoidance of tasklist_lock is very important for us. And now, I found another avoidable tasklist_lock, and made the patch. Could you please have a look? This patch avoid taking tasklist_lock in kill_something_info() when the pid is -1. It can convert to rcu_read_lock() for this case because group_send_sig_info() doesn't need tasklist_lock. This patch is for 2.6.25-rc5-mm1. Signed-off-by: Atsushi Tsuji ...

Detect all physical PCI slots as described by ACPI, and create entries in /sys/bus/pci/slots/. Not all physical slots are hotpluggable, and the acpiphp module does not detect them. Now we know the physical PCI geography of our system, without caring about hotplug. v10 -> v11: Thanks to Kenji Kanishige for the following updates: - Fix dmi table for Fujitsu PRIMEQUEST - Fix _STA evaluation - Use list_head for pci slot list - Fix slot removal path v9 -> v10: Allow an hp driver to ...

Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Thanks, Kenji Kaneshige --

Hi Greg, Kenji-san, First, many thanks to Kenji-san for his code review and subsequent patches. They really improved the code a lot! I've merged all his changes into my series, with the thought that it will be better to contain all the fixes in one spot for future bisectability purposes. I gave Kenji-san credit in the changelog, as well at the top of drivers/acpi/pci_slot.c, but if that's not sufficient, we can certainly add more attributions where it's appropriate. Please let me ...

Currently, /sys/bus/pci/slots/ only exposes hotplug attributes when a hotplug driver is loaded, but PCI slots have attributes such as address, speed, width, etc. that are not related to hotplug at all. Introduce pci_slot as the primary data structure and kobject model. Hotplug attributes described in hotplug_slot become a secondary structure associated with the pci_slot. This patch only creates the infrastructure that allows the separation of PCI slot attributes and hotplug attributes. In ...

On Tue, Mar 25, 2008 at 11:17 AM, James Bottomley I believe GUID Partition Tables (GPTs) are the answer. I believe one of the features of GPT is the elimination of the 32-bit sector restrictions. http://en.wikipedia.org/wiki/GUID_Partition_Table Windows VISTA 64-bit supports GPTs on data disks and new Mac OS based systems have been using it on internal drives for a couple years at least. GPTs are part of the Extensible Firmware Interface (EFI), so they should be usable for PC bootable ...

Ah, there's some sanity. :) --- ~Randy --

ia64 uses it exclusively ... at least on discs that you want to use from EFI. -- Intel are signing my paycheques ... these opinions are still mine "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." --

Perhaps I've missed something, but surely geometry doesn't make sense on a >2TB drive does it? The only reason we use it on modern disks (which usually make it up specially for us) is that the DOS partition scheme requires it. Once we're over 2TB, isn't it impossible to use DOS partitions (well, OK, unless you increase the sector size, but that's only delaying the inevitable), so we can just go with a proper disk labelling scheme and use BLKGETSIZE64 all the time. James --

(resending .. forgot to copy the lists originally) We have a problem coming down the pipeline. Practically all utilities that care about it, use ioctl(fd, HDIO_GETGEO) to determine the starting sector offset of a hard disk partition. SCSI, libata, IDE, USB, Firewire.. you name it. The return value uses "unsigned long", which on a 32-bit system limits drive offsets to 2TB. There will be single drives exceeding this limit within the next 12 months or less, and we already have RAID ...

That sounds useful. But you're the one who has investigated this - please make a recommendation? --

It shouldn't be under /sys/block... there are enough many things that scan /sys/block and assume any directory underneath it has the current format. -hpa --

Well, when dealing with shell scripts a O(n) very easily becomes O(n^2). For the stuff that I, personally, do, it's not a big deal, but people with large number of disks have serious gripes with our boot times. -hpa --

Probably a better thing to have would be a way to look up block devices in sysfs by device number. -hpa --

I've been waiting to see if sanity will take hold of anyone here. Come on people, adding symlinks for device major:minor numbers in sysfs to save a few 10s of lines of userspace code? Can things get sillier? You can add a single udev rule to probably build these in a tree in /dev if you really need such a thing... And what's wrong with your new ioctl recomendation? greg k-h --

Can I assume you mean conf->nr_pending == conf->nr_queued ?? Yes, it is after reschedule_retry which increments ->nr_queued, but also after conf->nr_queued--; in raid1d when the request is removed from the queue. Does that make sense? NeilBrown --

Hi Linus, Andrew, Now that we are (presumably) approaching the next merge window, can I ask what use (if any) will you be making of the linux-next tree? Alternatively, is there any information you want from it? --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

PowerPC is included as powerpc-next in the linux-next tree. josh --

Hi, I'd like some clarification about the future (use) of linux-next and Andrew's -mm patch series. They duplicate a lot of the major git tree or quilt patch series. Can we expect both of them to continue as is or will -mm be a patch series on top of linux-next or what? -- ~Randy --

The layers within the VFS are probably not very clearly defined, but I think one can fairly clearly see a difference between a "filesystem" layer and a "namespace" layer. The vfs_XX function are (in my mind) the top of the filesystem layer. They primarily call the relevant xxx_operation and just add minimal support code to enforce standard policy, callouts, etc. vfsmnts are very much part of the "namespace" layer. The heart of this layer is probably link_path_walk. It allows mounts to ...

Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git upstream-linus to receive the following updates: drivers/ata/ahci.c | 6 ++- drivers/ata/libata-core.c | 48 ++++++++++++-------- drivers/ata/libata-scsi.c | 14 ++++- drivers/ata/pata_it821x.c | 2 +- drivers/ata/sata_promise.c | 109 +++++++++++++++++++++++++++++++++++-------- include/linux/libata.h | 8 +++- 6 files changed, 141 insertions(+), 46 ...

Return pointer to requested cpumask for cpu_coregroup_map() functions. Based on linux-2.6.25-rc5-mm1 # sparc Cc: David S. Miller <davem@davemloft.net> Cc: William L. Irwin <wli@holomorphy.com> # x86 Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/smpboot_32.c | 6 +++--- arch/x86/kernel/smpboot_64.c | 6 +++--- include/asm-sparc64/topology.h | 2 ...

Reduce the amount of stack used in build_sched_domains by allocating all the masks at once, and setting up individual pointers. If NR_CPUS <= 128, then stack space is used instead. Based on linux-2.6.25-rc5-mm1 Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Mike Travis <travis@sgi.com> --- One checkpatch warning that I'm not sure how to remove: ERROR: Macros with complex values should be enclosed in parenthesis #61: FILE: kernel/sched.c:6656: +#define SCHED_CPU_VAR(v, a) ...

I'm not 100% sure if this is needed but I can't find where memory allocated for sched_group_nodes is released if the kmalloc for alloc_rootdomain fails. Also, sched_group_nodes_bycpu[] is set, but never completely filled in for the kmalloc failure case. Based on linux-2.6.25-rc5-mm1 Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Mike Travis <travis@sgi.com> --- kernel/sched.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- linux-2.6.25-rc5.orig/kernel/sched.c +++ ...

Pass cpumask_t variables by reference in acpi-cpufreq functions. Based on linux-2.6.25-rc5-mm1 Cc: Len Brown <len.brown@intel.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- linux-2.6.25-rc5.orig/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c +++ linux-2.6.25-rc5/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c @@ -211,22 +211,22 @@ ...

Instead of passing by value, the "newly allowed cpus" cpumask argument, pass a pointer: -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask) +int set_cpus_allowed(struct task_struct *p, const cpumask_t *new_mask) This is a major ABI change and unfortunately touches a number of files as the function is very commonly used. I had thought of using a macro to "silently" pass the 2nd arg as a pointer, but you lose in the situation where you already have a pointer to the new ...

Modify usage of cpumask_t variables to use pointers as much as possible. Changes are: * Use a per_cpu variable for cpumask_of_cpu when large NR_CPUS count is present. This removes 25552 bytes of stack usage (see chart below), as well as reduces the code generated for each usage. * Modify set_cpus_allowed to pass a pointer to the "newly allowed" cpumask. This removes 10784 bytes of stack usage but is an ABI change. * Add node_to_cpumask_ptr that returns pointer to ...

In 2.6.24.x, after building a kernel+modules, successive runs of make do very little: [24]$ make CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h Kernel: arch/x86/boot/bzImage is ready (#21) Building modules, stage 2. MODPOST 27 modules But in v2.6.25-rc6-294-gcc7feea, re-running make seems to rebuild stuff that may not need to be rebuilt, wasting cycles: [25]$ make CHK ...

Remove the fixed size channels[NR_CPUS] array in net/core/dev.c and dynamically allocate array based on nr_cpu_ids. Based on linux-2.6.25-rc5-mm1 Cc: David S. Miller <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: James Morris <jmorris@namei.org> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by: Mike Travis <travis@sgi.com> --- net/core/dev.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) --- linux-2.6.25-rc5.orig/net/core/dev.c +++ ...

Move the setting of nr_cpu_ids from sched_init() to setup_per_cpu_areas(), so that it's available as early as possible. Based on linux-2.6.25-rc5-mm1 # ia64 Cc: Tony Luck <tony.luck@intel.com> # powerpc Cc: Paul Mackerras <paulus@samba.org> Cc: Anton Blanchard <anton@samba.org> # sparc Cc: David S. Miller <davem@davemloft.net> Cc: William L. Irwin <wli@holomorphy.com> # x86 Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: H. Peter Anvin ...

Change cpu_sys_devices from array to per_cpu variable in drivers/base/cpu.c. Based on linux-2.6.25-rc5-mm1 (MAINTAINER unknown) Signed-off-by: Mike Travis <travis@sgi.com> --- drivers/base/cpu.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-2.6.25-rc5.orig/drivers/base/cpu.c +++ linux-2.6.25-rc5/drivers/base/cpu.c @@ -18,7 +18,7 @@ struct sysdev_class cpu_sysdev_class = { }; EXPORT_SYMBOL(cpu_sysdev_class); -static struct sys_device ...

Change fixed size arrays to per_cpu variables or dynamically allocated arrays in sched_init() and sched_init_smp(). (1) static struct sched_entity *init_sched_entity_p[NR_CPUS]; (1) static struct cfs_rq *init_cfs_rq_p[NR_CPUS]; (1) static struct sched_rt_entity *init_sched_rt_entity_p[NR_CPUS]; (1) static struct rt_rq *init_rt_rq_p[NR_CPUS]; static struct sched_group **sched_group_nodes_bycpu[NR_CPUS]; char str[NR_CPUS]; int ints[NR_CPUS], i; (1 - these arrays are allocated via ...

Add a new function cpumask_scnprintf_len() to return the number of characters needed to display "len" cpumask bits. The current method of allocating NR_CPUS bytes is incorrect as what's really needed is 9 characters per 32-bit word of cpumask bits (8 hex digits plus the seperator [','] or the terminating NULL.) This function provides the caller the means to allocate the correct string length. Based on linux-2.6.25-rc5-mm1 Cc: Paul Jackson <pj@sgi.com> Signed-off-by: Mike Travis ...

Cleanup references to the early cpu maps for the non-SMP configuration and remove some functions called for SMP configurations only. Based on linux-2.6.25-rc5-mm1 Cc: Andi Kleen <ak@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> --- This patch was moved from the zero-based percpu variables patchset to here. --- arch/x86/kernel/genapic_64.c | 2 + ...

We are pleased to announce the 2.6.24.3-rt3 tree, which can be downloaded from the location: http://rt.et.redhat.com/download/ Information on the RT patch can be found at: http://rt.wiki.kernel.org/index.php/Main_Page Changes since 2.6.24.3-rt3 - ported to 2.6.24.4 - kthread cpus_allowed init (Gregory Haskins) - migration CPU_DYING case (Gregory Haskins) - PPC preempt disable tlbflush (Egor Starkov) - printk hack fix (Steven Rostedt) - preemption during ...

On Mon, 24 Mar 2008 17:47:34 -0700 Acked-by: Alan Cox <alan@redhat.com> Although I suspect some people may dislike that. --

Silence two kerneldoc warnings. Warning(kernel/audit.c:1276): No description found for parameter 'string' Warning(kernel/audit.c:1276): No description found for parameter 'len' [also fix a typo for bonus points] Signed-off-by: Dave Jones <davej@codemonkey.org.uk> --- linux-2.6.24.noarch/kernel/audit.c~ 2008-03-24 20:22:32.000000000 -0400 +++ linux-2.6.24.noarch/kernel/audit.c 2008-03-24 20:23:34.000000000 -0400 @@ -1269,8 +1269,8 @@ static void audit_log_n_string(struct au /** * ...

This really should be handled through a CPU flag. Specifically, it should be handled by disabling the PAT flag if PAT is unusable or suspect of being unusable; it should *NOT* be stashed away in a completely separate piece of code. -hpa --

PAT patches in x86.git latest, only support some intel CPUs. if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && (boot_cpu_data.x86 == 0xF || (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model >= 15))) { if (cpu_has_pat) { return 1; } } should be moved to setup_64.c? YH --

On Mon, 24 Mar 2008 16:48:10 -0700 (PDT) The relevance is that I should have net-2.6.26 in my lineup, but I don't because I didn't know that it was available, and I didn't think to check. If I _did_ have net-2.6.26 here, I'd have immediately seen that you'd I dropped net-2.6.24 when its git-fetch started failing. But I have no automatable way of knowing when to start picking up net-2.6.25. --

that needs a KERN_INFO, and should be labeled "Warning: ...". Ingo --

It looks fine to me, not a big deal I think... I was woried that core_initcall() would not suit all, so this helps. Thanks Tony! -- Jens Axboe --

In ia64 the first calls to smp_call_function_single() are made while bringing up other cpus ... which happens from: kernel_init() smp_init() The init calls are made a few lines later (still in kernel_init): do_basic_setup() do_initcalls() I moved the call radically earlier (before sched_init() in init/main.c:start_kernel()) just to be sure, but that was overkill. Perhaps making the call from do_pre_smp_initcalls() is the logical place? Like this (though purists will say ...

Problem is that local apic is not always present. I'm sending a replacement. --

thanks, applied. Ingo --

this broke the 32-bit build: In file included from arch/x86/kernel/cpu/amd.c:8: include/asm-x86/mach-default/mach_apic.h: In function 'init_apic_ldr': include/asm-x86/mach-default/mach_apic.h:47: error: implicit declaration of function 'apic_write_around' [...] .config attached. Ingo

take them out of the x86_64-only asm/mach_apic.h Signed-off-by: Glauber Costa <gcosta@redhat.com> --- arch/x86/kernel/apic_64.c | 2 ++ arch/x86/kernel/crash.c | 4 ---- arch/x86/kernel/io_apic_64.c | 2 ++ arch/x86/kernel/kgdb.c | 6 +----- arch/x86/kernel/smp.c | 6 +----- arch/x86/kernel/tlb_64.c | 3 ++- include/asm-x86/mach-default/mach_ipi.h | 10 ++++++++++ ...

No instead of having lots of if (xyz_system) do_xyz_special() go through smp_ops for the whole thing so that UV would just have a special smp_ops that has special implementions or wrappers. Oops I see smp_ops are currently only implemented for 32bit. Ok do it only once smp_ops exist on 64bit too. -Andi --

Really caller should have done preempt_disable(), otherwise the value can be wrong as soon as you return. Better probably to just WARN_ON if preemption is on Actually it should be correct. Except for UV you likely really need a NUMA aware irqbalanced. I used to have some old very hackish patches to implement that in irqbalanced, but never pushed it because the Instead of doing that it might be better to implement __read_mostly per CPU variables This should be probably factored ...

dont we want to put get_apic_id() into struct genapic instead? We already have ID management there. also, we want to unify 32-bit and 64-bit genapic code and just have genapic all across x86. Ingo --

Does the kernel really need all this information? You just want to address the UV-APIC right? I suspect you could use a much stripped But it it would be cleaner if your BIOS just supplied a suitable __va() and then you remove these macros. -Andi --

Will change... --- jack --

bitfields are only problematic on portable code, which this isn't. -Andi --

IIR the x2apic scheme entails using the legacy entries for the first 256 entries, and extended entries for the processors above that, no? Here we seem to be assuming all lapic or all sapic entries. -Len --

x86.git#latest http://people.redhat.com/mingo/x86.git/README YH --

> And the return value of thermal_zone_device_register is also misused. Indeed, I missed that one. --

Patch looks correct. Thanks, Julia. But it misses the same problem in driver/misc/intel_menlow.c. And the return value of thermal_zone_device_register is also misused. How about this refreshed patch? :) Check the return value of thermal zone/cooling device registration correctly. Signed-off-by: Zhang Rui <rui.zhang@intel.com> --- drivers/acpi/fan.c | 3 +-- drivers/acpi/processor_core.c | 3 +-- drivers/acpi/thermal.c | 2 +- drivers/acpi/video.c | ...

--

How is a driver supposed to prevent calls to probe()? You can block in probe() or you can fail it, but how do you prevent it from being called? User space can trigger probe via sysfs. To be useful to driver writers, this has Probably it should be mentioned that this is the time to allocate memory if you have to. And it is too late to request firmware. Regards Oliver --

Well, I think it is, but I'm not sure how that can help. To prevent the race from happening, we can lock dpm_list_mtx before switching interrupts off in kernel/power/main.c:suspend_enter() and analogously in kernel/power/disk.c . Thanks, Rafael --

I don't see anything else to change. ACK. Alan Stern --

The comment is supposed to mean that probe() should be prevented from running Well, not exactly. Afterwards you cannot use GFP_KERNEL allocations, but GFP_NOIO should still work, although for hibernation it's quite possible that Yes. Thanks, Rafael --

The PX-712A still doesn't work right? Maybe it is related to the bug: http://bugzilla.kernel.org/show_bug.cgi?id=8918 Tejun has the dirve, but nothing new for now. http://bugzilla.kernel.org/show_bug.cgi?id=8918 regards Bjoern --

That's right. Thanks. Spirits are using me, A larger voice is calling me. -- Alan J. Mayer SGI ajm@sgi.com WORK: 651-683-3131 HOME: 651-407-0134 -- --

thanks, applied. I suspect this can wait until .26, as there appears to be a number of other patches that you need to get these boxes running on vanilla, right? Ingo --

I kept that as a template for freeing up code. I'll remove that since OK Thanks for the review Balbir --

Found the solution. It was a problem on my ARM platform at91rm9200 which didn't have internal pullup's enabled on the CMD and DAT0..DAT3. I found it by comparing the patch for AT91 kernel 2.6.19 on http://maxim.org.za/at91_26.html with the driver I had backported. regards Martin --

I don't see why this particular issue is any special case. The zombie leak is just one of many ways that the system might become unusable if root does the wrong thing to an essential system daemon. Caveat superusor. Diddling with init on a system you expect ever to do anything again is dangerous and requires great care. The question of allowing an administrator to engage in dangerous activities is orthogonal to the details of a particular danger. With today's kernel, init can avoid any ...

How is that different from ptracing any other process with _lot_ of children -- like X? You'll get same zombies in both cases, leading to same issues, no? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

[Empty message]

inside a guest, by default no (i.e. there simply is no capability for that), on the host the behaviour is unmodified .. note that there are guests without init where the blend through init is protected in a special way HTH, --

Not quite. CAP_SETPCAP was taken out of everyone's bounding set. But kernel/sysctl.c allowed only init to add capabilities to the bounding Herbert, Pavel, do you have objections to allowing ptrace of init? (I believe Eric has already Acked the idea iirc?) thanks, -serge --

Well, I think it isn't even necessary, unless you ptrace init for a Though root-only. Root doesn't want to be limited and knows better anyway. I think ptracing init is useful even when no one takes care of the dead (especially if you want to trace waits). -- Krzysztof Halasa --

The problem is that you can deadlock if you are not very careful. -Andi --

It would be fine to allow this unconditionally if there was some mechanism to make sure someone else takes over reaping childs while init is ptraced. I like the general idea -- i used to patch kernels to allow this too, but it is dangerous. -Andi --

I think someone with a consistent code style generates better code than someone who can't even make up his mind on how to write it, let alone what to write. With Linux we have many people, many of us with a preferred style, most of which will differ from the suggested style. Much like natural languages, many of us don't speak English as their native tongue, mine is Dutch, yours is German. Still we communicate with each other using English, because that is the de-facto standard on LKML [ ...

Careless. I'll set up an x86-64 cross-compiler. Before building I did s/__LINE__/0/g to minimize the md5sum differences and md5sum/diff and objdump -Dx/diff and inspected the objects before and after. --

that is crap too ... Ingo --

could you please give me a file name as an example that i could double-check myself? Thanks, Ingo --

From: Ingo Molnar <mingo@elte.hu> And yet you used it to claim that the sparc64 port is an unmaintainable pile of poo. Thanks but no thanks, you just proved even more to me why checkpatch is crap. --

seconded - i asked Joe to offer such cleanups in a git tree. Given that most of the changes in the patches are along the same pattern, posting the script would have made more sense as well. while we do have a growing code quality problem, spamming our lists with trivialities is certainly not the answer. Ingo --

hm, you apparently never built this on 64-bit x86? The above has a trivial typo. Ingo --

in the last series of coding style patches i sent to both ingo and bart i worked as follow: - worked on files with agreement of the maintainer (or after he asked me to do the cleanup) - separated changes that modified the binary from the pure style changes. -all the patch were compile tested and when possible a size/md5sum verificatio was performed and added to the changelog. i learned this "rules" learning from my mistakes and in the end it worked well so i think the problem is in how ...

well, once a subsystem is "checkpatch-clean" (which my challenge above obviously assumes), there's no such "partial style" problem. It obviously also assumes that the maintainer agrees that having consistent coding style across all of Linux is a long-term advantage. The current visual inconsistency between subsystems makes the Linux kernel appear rather unpleasant and unprofessional to new kernel developers. This is not just embarrasing to us (we want to write the best OS on the ...

I disagree with that assertion. My favorite example of where CodingStyle has gone too far is this: for (i=0; i<10; i++) While the official document demands four extra spaces, I _hate_ them. Whitespace offers visual grouping. The lack of whitespace around the binary operators emphasizes that one kind of grouping is stonger than another. Ever since this binary operator testament was added to our Holy Canon, I started violating the coding style on purpose. Imo this is beyond silly. So do ...

The last should and will be fixed. The // I don't really care about. Send a patch if you do. Going over my logfs patch, I found several things that are either false positives or rather questionable in my book. <adds Andy to Cc:> (foo*) should be (foo *) What does that extra space gain us? ERROR: no space before that close parenthesis ')' #2565: FILE: fs/logfs/gc.c:294: + seg_ofs + sizeof(oh) < super->s_segsize; ) { Actual code is this: for (seg_ofs = ...

checkpatch does not necessarily result in the same binaries. First there is the build date and then there might be changes like KERN_* prefixes added etc. And there might be code which is not covered under a single configuration, e.g. when both 32bit and 64bit x86 is changed. -Andi --

You assert that all the time, but it is just that: an assertation. I assert that code style is only a small part of code correctness. Also just an assertation. Who is more right? Probably the truth is somewhere inbetween. At least I think it is nearer my position than yours @) Also regarding the rules enforced by checkpatch I think there is a wide range on how much they impact readability: e.g. if someone uses the wrong bracket style consistently that is somewhat disrupting. I agree. But ...

On Sat, 22 Mar 2008 21:47:52 -0700, "Ray Lee" <ray-lk@madrabbit.org> As mentioned in another response, it was happening as recently as 2.6.25-rc6-git7; I'm currently performing a git bisect between 2.6.23 and 2.6.24, unless someone has a better idea; it seems my best option, as I'm not really very experienced with kernel hacking or debugging. --

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> MBR, Sergei --

[Ingo Molnar - Tue, Mar 25, 2008 at 04:57:00PM +0100] | | * Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > You know, Peter, I'm a bit scared that these flags are in number of | > files and could break others queued patches... | | as long as your work against x86.git/latest you shouldnt be worried | about any clashes. | | Ingo | oh, thanks Ingo, I continue workin on this realm ;) - Cyrill - --

thanks Jiri, applied. Ingo --

pulled, thanks --

Heh... me refreshing the patchset again. Doing it right now. -- tejun --

I just merged it into #upstream-fixes (answering your question)... what is your preferred method of sync'ing at this point? Jeff --

All i get is: [ 1175.600768] ACPI: PCI Interrupt 0000:0c:03.0[A] -> GSI 19 (level, low) -> IRQ 19 no ioremap debug offset. --

Just to clarify, in case the thread of discussion caused any confusion: I only have an unaffected system which never maps MMIO space above 4G. So far only Thomas M.'s system did this. -- Stefan Richter -=====-==--- --== ==--= http://arcgraph.de/sr/ --

I didn't bisect this.But I recompiled with CONFIG_RESOURCES_64BIT *unset* and everything is fine now, i.e. no error occurs anymore. lspci -vv output: 0c:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) (prog-if 10 [OHCI]) Subsystem: Agere Systems FW323 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B+ DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- ...

64-bit ioremaps never worked on 32-bit, so we are in totally unchartered waters now - but due to the unification we have a realistic chance to make them work. At minimum we need the fix below in addition to Linus' patch - does it make any difference? Ingo --- arch/x86/mm/ioremap.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Index: v/arch/x86/mm/ioremap.c =================================================================== --- v.orig/arch/x86/mm/ioremap.c +++ ...

could you please try x86.git/latest: http://people.redhat.com/mingo/x86.git/README which has all the fixes and debug patches integrated (no extra patching should be needed). If it still doesnt work then please send the new dmesg and /sys/kernel/debug/kernel_page_tables dump. head 0fef904c33841be92f or later. Ingo --

The kernel boots, but hangs at "populating dev tree with devices usings uevents". After removing both firewire drivers (ohci1394 and firewire_ohci) the system comes up correctly. See attached file. Modprobing either ohci1394 or firewire_ohci seems to lock up the system. mfg thomas

So version 3 of the interface will be the first stable and usable one... sigh :/ It's just disheartening that the userspace filtering stuff (including interface) was disabled rather than fixed, given that that change came first and arguably the follow-on change (285e9670) was an abuse of the API that was never corrected -- which seems to be tacitly acknowledged since everyone seems to agree more than one flag is needed. Jeff --

This passes smoke tests, so have incorporated it. Thank you, Mathieu!!! --

Shouldn't this be increased to 48? AMD family 10h CPUs actually support 48 bits for the physical address. Regards, Andreas --

You are probably correct but I don't work with AMD processors and don't understand their requirements. If someone wants to submit a patch to support larger phys memory sizes, I certainly have no objections.... --- jack --

Hi, Here is what I could find on my side: ============================================================= lkernel@akt$ cat tst3/res_new/output [root@akt tests]# echo 32768 > /proc/sys/kernel/msgmni [root@akt tests]# ./msgbench_std_dev_plot -n 32768000 msgget iterations in 21.469724 seconds = 1526294/sec 32768000 msgsnd iterations in 18.891328 seconds = 1734583/sec 32768000 msgctl(ipc_stat) iterations in 15.359802 seconds = 2133472/sec 32768000 msgctl(msg_stat) iterations in ...

That would be about on par with my luck. I'll try to muster up the gumption to go looking for part three, though my motivation for searching long ago proved to be a dead end wrt sysv ipc. -Mike --

[Empty message]

Right. It just requires a page allocator rewrite. Which is overdue Well. Guess we need a definition of preserving memory. All allocations typically have some kind of overhead. --

From: Paul Mackerras <paulus@samba.org> Implementing transparent automatic usage of hugepages has been discussed many times, it's definitely doable and other OSs have implemented this for years. This is what I was implying. --

From: Paul Mackerras <paulus@samba.org> Please read the rest of my responses in this thread, you can have your HPC cake and eat it too. --

Interesting.... Never realized we were doing these tricks with DTR. --

I think that to a first approximation, the improvement in user time (24 seconds) is due to the increased TLB reach and reduced TLB misses, and the improvement in system time (18 seconds) is due to the reduced number of page faults and reductions in other kernel overheads. As Dave Hansen points out, I can separate the two effects by having the kernel use 64k pages at the VM level but 4k pages in the hardware page table, which is easy since we have support for 64k base page size on machines ...

>>>>> "David" == David Miller <davem@davemloft.net> writes: David> From: Christoph Lameter <clameter@sgi.com> Date: Tue, 25 Mar David> Transparent automatic hugepages are definitely doable, I don't David> know why you think this requires application changes. It's actually harder than it looks. Ian Wienand just finished his Master's project in this area, so we have *lots* of data. The main issue is that, at least on Itanium, you have to turn off the hardware page table walker for hugepages ...

From: Peter Chubb <peterc@gelato.unsw.edu.au> If the hugepage is more than 3 to 4 times larger than the base page size, which it almost certainly is, it's still an enormous Right, admittedly this is just a (one of many) strange IA64 quirk. --

Can you do the same thing with the 4k MMU pages and 64k PAGE_SIZE? Wouldn't that easily break out whether the advantage is from the TLB or from less kernel overhead? -- Dave --

Someone posted a patch recently that showed that the cdrom layer does it. Might be more. It is hard to audit a few million lines It might be a subtle failure. Maybe sparse could be taught to check for this if it happens in a single function? (cc'ing Al who might have some thoughts on this). Of course if it happens spread out over multiple functions sparse wouldn't help neither. -Andi --

"large" pages, or "super" pages perhaps ... but Linux "huge" pages seem pretty hard to adapt for generic use by applications. They are generally a somewhere between a bit too big (2MB on X86) to way too big (64MB, 256MB, 1GB or 4GB on ia64) for general use. Right now they also suffer from making the sysadmin pick at boot time how much memory to allocate as huge pages (while it is possible to break huge pages into normal pages, going in the reverse direction requires a memory defragmenter ...

A device that cannot wake up is unusable. Shouldn't the pm core disconnect() such a device? Regards Oliver --

IMO you must always keep the ordering invariant. If a parent returns an error the PM core must not wake its children. Regards Oliver --

Then why return an error? If a driver returns an error I would assume that Exactly. But we need to define what happens in these cases. If we simply ignore the errors, the drivers must be able to deal with IO to half suspended devices. Regards Oliver --

Why? You can trigger it from user space via sysfs and in many cases suspending to disk will disconnect all devices on a bus, so I'd say a failure to resume is just a limited subcase of a device vanishing during sleep. Regards Oliver --

I'm agreeing here, but one of the previous Alan's comments suggests he has a differing opinion. Alan? I'm considering to make the PM core skip the resuming of the children of devices that failed to resume and skip calling ->complete() for that devices and their children. Thanks, Rafael --

Yes, of course. -- Any sufficiently difficult bug is indistinguishable from a feature. --

Except container_of() works, which is a nice thing to know, and it already mentions rb_entry() as another way to do it. If someone could explain _why_ If I wanted abstraction for its own sake I'd be using C++ to implement a And this can't be done with container_of()? Again, I don't care much either way, I just want to know what the point is of choosing one over the other that makes changing what's there worth bothering with. You're changing the documentation to hide the fact that ...

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 ...

Fix a typo. Merged one is attached too. Signed-off-by: Yaozu (Eddie) Dong <eddie.dong@intel.com> --- drivers/xen/events_old.c 2008-03-25 14:31:40.503525471 +0800 +++ drivers/xen/events.c 2008-03-25 14:19:39.841851430 +0800 @@ -37,7 +37,7 @@ #include <xen/interface/xen.h> #include <xen/interface/event_channel.h> =20 -#include "xen-ops.h" +#include <xen/xen-ops.h> =20 /* * This lock protects updates to the following mapping and reference-count

How do you want to manage this work? I'm currently basing off Ingo+tglx's x86.git tree. Would you like me to track these kinds of common-code changes in my tree, while you maintain a separate This should include <linux/percpu.h> rather than assuming it has already been included. J --

I tried HEAD from yesterday, but resume still fails. So it looks like I need to start a git bisect. Regards, Tino --

Hi Greg, This still has the same conflicts, but they are papered over by my use of git-rerere (which remembers my previous merge fixup and applies it for This one seems to be fixed. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

On Tue, 25 Mar 2008 12:43:22 +0000 I guess so. It's quite unusual. --

Added linux-raid to cc - this is not an XFS problem Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --

Suspending IO is not supposed to be needed in APM case, try ACPI. (We could work around this.. You should be able to reuse kernel/power/main.c to stop all user processes, then stop the drivers...) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Thanks, merged. --

Thanks, merged. --

Nice work, thanks. I've merged it. --

It's obviously going to be faster. The kthread approach needs an IPI *and* a context switch on the destination CPU. For broadcast situations, it is also going to be faster, because it can use platform specific broadcast IPIs The only weird atomicity requirements of smp_call_function is due to its terribly unscalable design. Once you have the producer provide its own data (or accept -ENOMEM failures), then there is no problem. It's then even possible to use it from interrupt context with ...

which excerpt specifically are you talking about ? the only ESR mention I see in setup_local_APIC() is this: /* Pound the ESR really hard over the head with a big hammer - mbligh */ if (esr_disable) { apic_write(APIC_ESR, 0); apic_write(APIC_ESR, 0); apic_write(APIC_ESR, 0); apic_write(APIC_ESR, 0); } which seems more like a disablement. My testings that triggered that were with qemu, with ...

... basically for the original Pentium and Pentium/MMX APIC you only had to read the ESR to get at the bits. The read would clear them as well as a side-effect. Although at that stage already it was mentioned in the spec that for future compatibility a write of zero beforehand (ignored as the register was r/o) should be performed. Which indeed became a requirement from PentiumPro onwards as with these processors it was the write that copied the internal error latches into the visible ...

Okay. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --

There is still the additional seek. Large xattrs tend to be out of line from the inode. -Andi --

Ok. The timer got delayed. It got delayed because it is initialized as a deferrable timer, which is obviously wrong. Sigh, I signed off on that commit myself without thinking about the consequences. Ouch. revert: 1077f5a917b7c630231037826b344b2f7f5b903f --- kernel/time/clocksource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/kernel/time/clocksource.c =================================================================== --- ...

Is it just me who feels this comment that says "in_atomic() is not a way to tell if we are in atomic reliably and cannot be used for such and such" very reader-unfriendly? Ok, maybe the macro is not reliable and is not meant to be used for the purpose its name seems to suggest (at least to a non-kernel person). An inevitable question is, then what is it good for? What's the right situation to use this macro? I guess an additional comment "even if this says no, you could still be in atomic, ...

The "right situation" would appear to be "you're deep in the mm code and really know what you're doing." It is not a useful way for code to determine whether it's running in atomic context - as was discussed elsewhere in the thread, that information really needs to be passed in by the caller. The point being that "you just *might* be in atomic context, where sleeping would be a bad idea, but I can't tell you" really isn't all that useful. It's a trap which can only lead to incorrect ...

From: Randy Dunlap <randy.dunlap@oracle.com> Prevent failed randconfig builds with KVM_CLOCK being enabled on Voyager or VISWS. build-rand9.out: Using /local/linsrc/next-20080325 as source for kernel build-rand9.out: from /local/linsrc/next-20080325/include/linux/irqflags.h:46, build-rand9.out: from include2/asm/system.h:11, build-rand9.out: from include2/asm/processor.h:21, build-rand9.out: from ...

Wow, that's a lot of dump files. :) I was worried that in the "blank" case we may see the same register dump as in the working case, but thankfully they're different. In fact, in all the dumps after 0 in the 2.6.25-blank case, both pipes are disabled and the LCD itself is disabled. The important bits: @@ -24,7 +24,7 @@ (II): DVOB_SRCDIM: 0x00000000 (II): DVOC_SRCDIM: 0x00000000 (II): PP_CONTROL: 0x00000001 (power target: on) -(II): PP_STATUS: ...

From: Krzysztof Halasa <khc@pm.waw.pl> Kyzysztof, this is the way you behave every time your patches don't get looked at as quickly as you would like them to. And this behavior does not trigger us maintainers to stop everything we're doing and apply your patches. In fact it makes us want to review your patches even less. Sending a healthy ping asking if your patches need to be resent, etc., is one thing. But this isn't what you're doing here. --

Hi, So are we leaving the generic-HDLC+PPP in broken state for 2.6.25, aren't we? If we do, perhaps a "|| BROKEN" in drivers/net/wan/Kconfig would make sense? Any attempt to use it will cause kernel panic immediately (PPP with generic HDLC only; drivers using syncppp.c directly are not affected). I can make that trivial Kconfig patch of course. -- Krzysztof Halasa --

You have the direct increment and the function call in phys_pud_init. The function is always called with pages=0 because nothing ever increments pages. Thanks, tglx --

This should especially boost performance on 32 bit. Have you numbers for -- | 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) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas ...

warning: passing argument 2 of 'rdmsrl_safe' from incompatible pointer type Thanks, tglx --

Nothing obvious. We could add it, but then would need to add a (imho ugly) vendor check there first. Yes the type has to be updated after the earlier inline change. Easiest you just do the trivial change yourself. -Andi --

Hi Andrew, Can you please also add/merge this patch as well? It fixes bugs in gxfb-add-power-management-functionality.patch (currently in your tree). Two suspend/resume fixes: - we weren't saving/restoring the palette correctly; I wasn't setting PAL_ADDRESS correctly. - the original GP restore code had an off-by-one bug that I happily reproduced in this code. This fixes that, which fixes the RASTER_MODE register not getting set. And drop an unnecessary ...

According to the tcrypt numbers you've posted it is getting "slightly" slower on encryption/decryption of 64+ bytes. How did you measure your "almost no performance penalty"? Sebastian --

a) doesn't appear to have been Cc'd to stable@kernel.org until now (fell through one crack) b) there was outstanding request from greg for clarification of the issue for 2.6.24 (fell through another crack) Please just explicitly send the fixes to stable@kernel.org and Cc Nick. I'm actually disinclined to take 0d71bd5993b630a989d15adc2562a9ffe41cd26d which seems to primarily just remove the WARN_ON(), although that is assuming it is indeed no longer triggered with just the race ...

Oh, by the way, note that it only disabled mmap for CONFIG_ALPHA_MIATA due to your report of es18xx working fine on the XP1000, so you'll have to change that to CONFIG_ALPHA_DP264 for the XP1000 to actually test it there: (or just delete SNDRV_PCM_INFO_MMAP from the info structures in the driver as Takashi earlier instructed) Rene.

Right, got that. On the PWS600au it shows the same problems that Bob describes! When I play it with aplay (through the es1887) I get the last "pal" repeated at the end. When I play it with sox (also through the es1887) I get the words "current event" repeated at the end. Playing through the CM8738 also repeats the words "current event" at the end when playing with sox. But using aplay through the CM8738 only results in silence and aplay hangs. A ctrl-c successfully breaks it. I ...

Fixed, I'll provide a new patch ASAP. Thanks, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --

Fixed, I'll provide a new patch ASAP. Thanks, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 --

Ben Dooks agreed to become my co-maintainer for the i2c subsystem. In particular, Ben will help with drivers for embedded systems, of which my experience is inexistent. Thanks Ben and welcome on board! Signed-off-by: Jean Delvare <khali@linux-fr.org> --- Ben, please give by your ack on this patch, then I will push it upstream. MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.25-rc6.orig/MAINTAINERS 2008-03-21 10:58:23.000000000 +0100 +++ ...

On Wed, 26 Mar 2008 00:31:19 +0100 (CET) Just disable the mmio patch on all systems - we know it doesn't work, we know what work needs to be done, it should remain off for everyone until that work is done. It should never have been merged in the first place and I think my statement to that effect has been proven nicely. Alan --

Sorry for the late response, but I was pretty busy the last couple of weeks. I'm thinking about something like this (based on http://patchwork.ozlabs.org/linuxppc/patch?id=16282 to 16284): This patch implements various helpers to support OF bindings for the i2c API. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/of/Kconfig | 6 +++ drivers/of/Makefile | 1 + drivers/of/i2c.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++ ...

I just checked the forums and apparently you mean that 8 replies to your topic including the answer about "it has been fixed" in 2.1.0 counts as 'ignored'... For reference: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=4512&highlight= and yes the following topic was unanswered http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=4572&highlight= --

El Tue, 25 Mar 2008 14:41:22 +0100 Fair enough; english is not my mother tongue so maybe i sounded Well my opinion is that instead of the webpage the mailing list should be the one being logged. Something like this (maybe use another define becouse DRV_PROJECT may be used elsewhere i havn't checked): diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h index 6c72542..2791f67 100644 --- a/drivers/net/wireless/rt2x00/rt2x00.h +++ ...

This issue has been resolved for 2.6.26. The fix for this bug is of such a scale You mean http://rt2x00.serialmonkey.com/phpBB2/index.php? 'ignored' is not the right word, more likely overlooked. There are quite a lot of messages and I don't always have time to answer them all. So there is no need to be upset about such thing, simply posting a reminder is usually What pointer? And rt2400-devel is the mailinglist for rt2x00... The MAINTAINERS file in the kernel tree indicates 2 mailinglists ...