linux-kernel mailing list

FromSubjectsort iconDate
Pavel Machek Mar 25, 1:23 pm 2008
Benjamin Herrenschmidt
[PATCH] pata_sil680: Only enable MMIO on Cell blades
There have been reported regressions of the SIL 680 driver when using MMIO, so this makes it only try MMIO on Cell blades where it's known to be necessary (the host bridge doesn't do PIO on these). We'll try to find the root problem with MMIO separately. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- drivers/ata/pata_sil680.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- linux-work.orig/drivers/ata/pata_sil680.c 2008-03-26 10:43:20.000000000 ...
Mar 25, 4:50 pm 2008
Alan Cox
Re: [PATCH] pata_sil680: Only enable MMIO on Cell blades
On Wed, 26 Mar 2008 10:50:41 +1100 Acked-by: Alan Cox <alan@redhat.com> --
Mar 25, 4:49 pm 2008
J.C. Pizarro
Re: larger default page sizes...
But there is a general problem of larger pages in systems that don't support them natively (in hardware) depending in how it's implemented the memory manager in the kernel: "Doubling the soft page size implies halfing the TLB soft-entries in the old hardware". "x4 soft page size=> 1/4 TLB soft-entries, ... and so on." Assuming one soft double-sized page represents 2 real-sized pages, one replacing of one soft double-sized page implies replacing 2 TLB's entries containing the ...
Mar 25, 4:47 pm 2008
NeilBrown
Re: r-o bind in nfsd
While I have no desire to defend that particular design, saying "tasteless" without suggesting an alternate approach does appear somewhat unhelpful. NeilBrown --
Mar 25, 4:29 pm 2008
Alexey Dobriyan
2.6.24.4: RIP: [<0000000000000000>] _stext+0x7fdf7000/0x20
I was trying to setup NAT, and oops happened during interface restart (&quot;/etc/init.d/net.eth0 restart: in gentoo speak). Much rule adding and flushing necessary to setup NAT was before that. atl1 0000:03:00.0: eth0 link is up 100 Mbps full duplex atl1 0000:03:00.0: eth0 link is down atl1 0000:03:00.0: eth0 link is up 100 Mbps full duplex Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [&lt;0000000000000000&gt;] _stext+0x7fdf7000/0x20 PGD 17cd79067 PUD 17d4f4067 PMD 0 ...
Mar 25, 4:14 pm 2008
Thorsten Kranzkowski
`.exit.text' referenced in section `.rodata'
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: &quot;saved_config&quot; [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 ...
Mar 25, 3:39 pm 2008
Christian Kujau
2.6.25-rc6: BUG: unable to handle kernel NULL pointer de ...
Hi, 2.6.25-rc6 is a strong beast :) Another[0] BUG is printed and the box is still alive: BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [&lt;c0179114&gt;] __d_lookup+0x94/0x150 *pde = 00000000 Oops: 0000 [#1] Modules linked in: fuse sha256_generic xt_tcpudp ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ftp nf_nat nf_conntrack_ftp xt_conntrack nf_conntrack iptable_filter ip_tables ipt_ULOG x_tables nfsd lockd nfs_acl auth_rpcgss exportfs tun sunrpc twofish_i586 ...
Mar 25, 4:08 pm 2008
devzero
some minor issues with 2.6.25-rc6-git7-default
here are some (probably more or less minor) issues i have found in /var/log/messages &amp; 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: ...
Mar 25, 4:00 pm 2008
Andrew Morton
Re: some minor issues with 2.6.25-rc6-git7-default
There are many physmap-flashes in the tree. Is this one As the hardware probe failed, why did we ever register anything which needs uh, &quot;known problem&quot;: multiple rtc drivers are being run. I don't really understand why we haven't been able to fix this - there have yay, I fixed one. --- a/net/9p/trans_fd.c~a +++ a/net/9p/trans_fd.c @@ -1522,7 +1522,7 @@ static int __init p9_trans_fd_init(void) v9fs_register_trans(&amp;p9_unix_trans); v9fs_register_trans(&amp;p9_fd_trans); ...
Mar 25, 4:42 pm 2008
Rafael J. Wysocki
Re: some minor issues with 2.6.25-rc6-git7-default
Well, Andrew should be CCed too ... Thanks, Rafael --
Mar 25, 4:10 pm 2008
Len Brown
acpi_ps_execute_method OOPS (Re: some minor issues with ...
On Tuesday 25 March 2008, devzero@web.de wrote: any idea when this started happening? Any chance you can snag the output from acpidump and attach it to a sighting here?: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI thanks, --
Mar 25, 4:37 pm 2008
Andrew Morton
Re: [Bug 10328] New: [regression] performance drop for glx
(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) --
Mar 25, 3:28 pm 2008
NeilBrown
Re: [opensuse] nfs_update_inode: inode X mode changed, Y to Z
What we need is for the &quot;filehandle&quot; to be stable and unique. By 'stable' I mean that every time I get the filehandle for a particular file, I get the same string of bytes. By 'uniqie' I mean that if I get two filehandles for two different files, they must differ in at least one bit. If a file is deleted and the inode is re-used for a new file, then the old and new files are different and must have different file handles. The filehandle is traditionally generated from the inode number and a ...
Mar 25, 4:09 pm 2008
Josef 'Jeff' Sipek
Re: [opensuse] nfs_update_inode: inode X mode changed, Y to Z
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 &lt;&lt; args.mp-&gt;m_sb.sb_inodelog); 294 for (i = 0; i &lt; ninodes; i++) { 295 free = XFS_MAKE_IPTR(args.mp, fbuf, i); 296 ...
Mar 25, 3:13 pm 2008
Mike Travis
[PATCH 02/10] init: move setup of nr_cpu_ids to as early ...
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: 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 # ia64 Cc: Tony Luck &lt;tony.luck@intel.com&gt; # powerpc Cc: Paul Mackerras &lt;paulus@samba.org&gt; Cc: Anton Blanchard &lt;anton@samba.org&gt; # sparc Cc: David S. Miller &lt;davem@davemloft.net&gt; Cc: William L. Irwin ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 06/10] x86: reduce memory and stack usage in inte ...
* 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: ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 09/10] x86: oprofile: remove NR_CPUS arrays in ar ...
Change the following arrays sized by NR_CPUS to be PERCPU variables: static struct op_msrs cpu_msrs[NR_CPUS]; static unsigned long saved_lvtpc[NR_CPUS]; 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: Philippe Elie &lt;phil.el@wanadoo.fr&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- All changes were transparent except ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 10/10] sched: Remove fixed NR_CPUS sized arrays i ...
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 ...
Mar 25, 3:07 pm 2008
Mike Travis
[PATCH 08/10] net: remove NR_CPUS arrays in net/core/dev.c v2
Remove the fixed size channels[NR_CPUS] array in net/core/dev.c and dynamically allocate array based on nr_cpu_ids. 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: David S. Miller &lt;davem@davemloft.net&gt; Cc: Alexey Kuznetsov &lt;kuznet@ms2.inr.ac.ru&gt; Cc: James Morris &lt;jmorris@namei.org&gt; Cc: Patrick McHardy &lt;kaber@trash.net&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- v2: fixed logic ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 07/10] cpu: change cpu_sys_devices from array to ...
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 &lt;travis@sgi.com&gt; --- 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 ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 04/10] acpi: change processors from array to per_ ...
Change processors from an array sized by NR_CPUS to a per_cpu variable. 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: Len Brown &lt;len.brown@intel.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- drivers/acpi/processor_core.c | 18 ++++++++---------- drivers/acpi/processor_idle.c | 8 ++++---- drivers/acpi/processor_perflib.c | 18 +++++++++--------- ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 03/10] cpufreq: change cpu freq arrays to per_cpu ...
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 &lt;davej@codemonkey.org.uk&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- drivers/cpufreq/cpufreq.c | 45 +++++++++++++++++++++------------------- ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 05/10] cpumask: Add cpumask_scnprintf_len function
Add a new function cpumask_scnprintf_len() to return the number of characters needed to display &quot;len&quot; 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 ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 01/10] x86_64: Cleanup non-smp usage of cpu maps v2
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 &lt;ak@suse.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Christoph Lameter &lt;clameter@sgi.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- This patch was ...
Mar 25, 3:06 pm 2008
Mike Travis
[PATCH 00/10] NR_CPUS: third reduction of NR_CPUS memory ...
Wii, isn't this fun...! This is a resubmission of yesterday's patches based on the x86.git/latest tree. Yes, it _is_ a maze of twisty litle passages. ;-) Patches that are actually different are marked &quot;v2&quot;. (I did not recalculate the memory usages changes but I did reverify the defconfig and akpm2 configs with both 255 and 4096 NR_CPUS.) ................... Here's the third round of removing static allocations of arrays using NR_CPUS to size the length. The change is to use PER_CPU ...
Mar 25, 3:06 pm 2008
J.C. Pizarro
What means Hugepage? 8KiB,16KiB,..,2MiB or 4MiB?
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. --
Mar 25, 3:03 pm 2008
H. Peter Anvin
Re: What means Hugepage? 8KiB,16KiB,..,2MiB or 4MiB?
On x86, it means 2/4 MiB, or even 1 GiB in some very strange circumstances. Other architectures might be different. -hpa --
Mar 25, 3:59 pm 2008
Pekka J Enberg
[PATCH] slab: fix cache_cache bootstrap in kmem_cache_init()
From: Daniel Yeisley &lt;dan.yeisley@unisys.com&gt; Commit 556a169dab38b5100df6f4a45b655dddd3db94c1 (&quot;slab: fix bootstrap on memoryless node&quot;) 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 &lt;mel@csn.ul.ie&gt; Cc: Olaf Hering &lt;olaf@aepfle.de&gt; Cc: Christoph Lameter &lt;clameter@sgi.com&gt; Signed-off-by: Dan Yeisley ...
Mar 25, 2:59 pm 2008
Joerg Schilling
Re: Burning CDs as user produces coasters (Plextor drive)
One of the known bugs in &quot;wodium&quot; is that it tries to keep you missinformed about the fact that you need root privileges in order to write CDs on Linux. The official cdrecord does not have this problem, it informs you early about missing root privileges. I recommend you to get a recent original from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ compile it and install it suid root. Readcd and cdda2wav also need root privileges in order to work. BTW: at the Linuxtage in Chemnitz, I got a ...
Mar 25, 2:40 pm 2008
Marcus Better
Re: [Bugme-new] [Bug 10327] New: keyboard stops respondi ...
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 --
Mar 25, 2:43 pm 2008
Andrew Morton
Re: [Bugme-new] [Bug 10327] New: keyboard stops respondi ...
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 25 Mar 2008 14:22:51 -0700 (PDT) So it's not an ill-advised disable_irq(). I guess the first question is: did the ifdown just kill the keyboard, or did more things die? Perhaps you could try ifdown eth0 ; sleep 5 ; ifup eth0 and see if the machine recovers? (I am just maxed out on bug reports at present - could someone please take this up and see if we can get it ...
Mar 25, 2:39 pm 2008
J.C. Pizarro
Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
$ 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 ...
Mar 25, 2:39 pm 2008
Chris Snook
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
All the more reason to use an interface that allows you to pick and choose the data you want, like /sys. -- Chris --
Mar 25, 4:14 pm 2008
Chris Snook
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
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 --
Mar 25, 2:57 pm 2008
Chris Snook
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
Then use dmidecode. It's all in one place, and everyone expects it to be far It's precisely that sort of weirdness we want to be able to catch at a glance. These days, there is no possible way to make /proc/cpuinfo satisfy everyone and still be compact. That's why we mostly leave it alone and put all the fun stuff in /sys, which is much better suited to the ever-increasing complexity of modern hardware. If we refactor /proc/cpuinfo, it will break all sorts of things that use that ...
Mar 25, 3:59 pm 2008
J.C. Pizarro
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
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 ;) --
Mar 25, 4:10 pm 2008
J.C. Pizarro
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
Thanks, but there is not easier manner to print the properties of hw-caches unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/ that they are only numbers without symbolic fields. /proc/cpuinfo doesn't give a general summary because it gives superfluous info. I think that it's better to refactorize /proc/cpuinfo still more. ( ... fields common to all present processors known by the kernel .... [ to warn if the values are differents between cores ...
Mar 25, 3:50 pm 2008
Glauber Costa
[PATCH 18/20] x86: unify dma_mapping_error
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 &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 19/20] x86: move ARCH_HAS_DMA_DECLARE_COHERENT_ME ...
define it conditionally to i386 Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- include/asm-x86/dma-mapping.h | 14 ++++++++++++++ include/asm-x86/dma-mapping_32.h | 12 ------------ 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 352433b..9548b19 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -202,4 +202,18 @@ dma_cache_sync(struct device *dev, void *vaddr, ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 20/20] x86: delete the arch-specific dma-mapping ...
all the code that is left is ready to be merged as-is in dma-mapping.h Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 14/20] x86: move dma_cache_sync to common header
they are the same in both architectures. Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- include/asm-x86/dma-mapping.h | 6 ++++++ include/asm-x86/dma-mapping_32.h | 7 ------- include/asm-x86/dma-mapping_64.h | 7 ------- 3 files changed, 6 insertions(+), 14 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index b5a413a..70a5ede 100644 --- a/include/asm-x86/dma-mapping.h +++ b/include/asm-x86/dma-mapping.h @@ -183,4 +183,10 @@ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 15/20] x86: move dma_supported and dma_set_mask t ...
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 &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 17/20] x86: provide a bad_dma_address symbol for i386
It's initially 0, since we don't expect any DMA there. Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- arch/x86/kernel/pci-dma_32.c | 4 ++++ include/asm-x86/dma-mapping.h | 2 ++ include/asm-x86/dma-mapping_64.h | 1 - 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/pci-dma_32.c b/arch/x86/kernel/pci-dma_32.c index 453b4bd..55ab3c8 100644 --- a/arch/x86/kernel/pci-dma_32.c +++ b/arch/x86/kernel/pci-dma_32.c @@ -14,6 +14,10 @@ #include ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 16/20] x86: align to clflush size
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 &lt;gcosta@redhat.com&gt; --- 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 +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 13/20] x86: move dma_map_page and dma_unmap_page ...
They are similar enough to do this move. the macro version is ugly, and we use inline functions instead Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- include/asm-x86/dma-mapping.h | 14 ++++++++++++++ include/asm-x86/dma-mapping_32.h | 15 --------------- include/asm-x86/dma-mapping_64.h | 4 ---- 3 files changed, 14 insertions(+), 19 deletions(-) diff --git a/include/asm-x86/dma-mapping.h b/include/asm-x86/dma-mapping.h index 3ea3802..b5a413a 100644 --- ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 12/20] x86: move alloc and free coherent to commo ...
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 &lt;gcosta@redhat.com&gt; --- 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 --- ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 09/20] x86: move dma_sync_single_range_for_device ...
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 14 ++++++++++++++ include/asm-x86/dma-mapping_32.h | 8 -------- include/asm-x86/dma-mapping_64.h | 12 ------------ 4 files changed, 15 insertions(+), 20 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index c501599..4512c30 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 10/20] x86: move dma_sync_sg_for_cpu to common header
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 11/20] x86: move dma_sync_sg_for_device to common ...
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 | 12 ------------ 4 files changed, 12 insertions(+), 19 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index d876600..033d94e 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 06/20] x86: move dma_sync_single_for_cpu to commo ...
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 08/20] x86: move dma_sync_single_range_for_cpu to ...
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 | 12 ------------ 4 files changed, 12 insertions(+), 19 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index 3648824..c501599 100644 --- a/arch/x86/kernel/pci-base_32.c +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 07/20] x86: move dma_sync_single_for_device to co ...
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 0/20] dma_ops for i386
Hello, Here there is a series of 20 patches that lays the foundations for using dma_ops in i386 in the very same way x86_64, as well as many other architectures already do. The functions themselves for i386 are placed in a pci-base_32.c, but just a few among them are actually implemented. Most were no-ops anyway. Also, as I said, this is by no means a complete coverage of dma_ops. there are still some call sites to be patches in pci-dma_32.c (although I don't really plan to change them, ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 05/20] x86: move dma_unmap_sg to common header
i386 gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 +++ ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 03/20] x86: move dma_unmap_single to common header
i386 base does not need it, so it gets an empty function Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- arch/x86/kernel/pci-base_32.c | 1 + include/asm-x86/dma-mapping.h | 10 ++++++++++ include/asm-x86/dma-mapping_32.h | 7 ------- include/asm-x86/dma-mapping_64.h | 8 -------- 4 files changed, 11 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index b613d73..a8a7c7f 100644 --- ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 02/20] x86: implement dma_map_single through dma_ops
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 &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 04/20] x86: move dma_map_sg to common header
the old i386 implementation is moved to pci-base_32.c Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- arch/x86/kernel/pci-base_32.c | 19 +++++++++++++++++++ include/asm-x86/dma-mapping.h | 8 +++++++- include/asm-x86/dma-mapping_32.h | 20 -------------------- include/asm-x86/dma-mapping_64.h | 7 ------- 4 files changed, 26 insertions(+), 28 deletions(-) diff --git a/arch/x86/kernel/pci-base_32.c b/arch/x86/kernel/pci-base_32.c index a8a7c7f..2474152 100644 --- ...
Mar 25, 2:36 pm 2008
Glauber Costa
[PATCH 01/20] x86: move dma_ops struct definition to dma ...
take it off the x86_64 specific header Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:36 pm 2008
York Sun
[PATCH 2/2 v3] Add DIU platform code for MPC8610HPCD
Add platform code to support Freescale DIU. The platform code includes framebuffer memory allocation, pixel format, monitor port, etc. Signed-off-by: York Sun &lt;yorksun@freescale.com&gt; --- This patch enables Freescale DIU driver for MPC8610HPCD board. arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 +++++++++++++++++++++++---- arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 ++++++++++++++++++++++++- arch/powerpc/sysdev/fsl_soc.c | 41 ++++++ ...
Mar 25, 2:27 pm 2008
York Sun
[PATCH 1/2 v3] Driver for Freescale 8610 and 5121 DIU
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 ...
Mar 25, 2:27 pm 2008
York Sun
V3 Patch - Driver for Freescale 8610 and 5121 DIU
The following two patches are the 3rd version of the DIU patch for Freescale 8610 and 5121. It fixed the issues according to the feedback from Andrew Morton. Andrew, incremental patches are available if requested. Regards, York --
Mar 25, 2:27 pm 2008
Scott Wood
Re: [PATCH 1/2 v3] Driver for Freescale 8610 and 5121 DIU
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 --
Mar 25, 3:19 pm 2008
Dave Hansen
kvm causing memory corruption? ~2.6.25-rc6
I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. I've had some lockups doing similar things over the last month or two, but figured it was something really stupid I was doing, and never really connected the dots. Now, I've hooked up a serial console and reproduced it with a fresh boot and not much else going on at all on the machine. Machine is a ...
Mar 25, 2:12 pm 2008
Glauber Costa
[PATCH 2/2] [PATCH] move apic declarations to mach_apic.h
take them out of the x86_64-specific asm/mach_apic.h Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 2:10 pm 2008
Luck, Tony
What if a TLB flush needed to sleep?
ia64 processors have a &quot;ptc.g&quot; instruction that will purge a TLB entry across all processors in a system. On current cpus there is a limitation that only one ptc.g instruction may be in flight at a time, so we serialize execution with code like this: spin_lock(&amp;ptcg_lock); ... execute ptc.g spin_unlock(&amp;ptcg_lock); The architecture allows for more than one purge at a time. So (without making any declarations about features of unreleased processors) it seemed like time to update ...
Mar 25, 1:49 pm 2008
Alan Cox
Re: What if a TLB flush needed to sleep?
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 --
Mar 25, 2:47 pm 2008
Török Edwin
gcc-4.3 considers unaligned accesses on X86 as undefined
Hello x86 architecture maintainers, GCC-4.3 now considers that it is undefined behaviour to access memory through an int* that is not aligned to sizeof(int). At -O3 it generates vectorized code that _relies_ on the fact that pointers are always aligned (unless you use packed attributes, etc.), and the resulting code crashes if the pointer is unaligned. (-O3 -msse on 32-bit, and simply -O3 on 64-bit since -msse is default) See this gcc bugreport: ...
Mar 25, 1:51 pm 2008
H. Peter Anvin
Re: gcc-4.3 considers unaligned accesses on X86 as undefined
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 --
Mar 25, 1:56 pm 2008
Alan Cox
Re: gcc-4.3 considers unaligned accesses on X86 as undefined
On Tue, 25 Mar 2008 22:51:09 +0200 FPU/MMX/SSE are not available or usable for the kernel anyway fortunately in this case. Alan --
Mar 25, 2:11 pm 2008
Jarod Wilson
[PATCH] firewire: fw-ohci: plug dma memory leak in AR handler
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 ...
Mar 25, 1:47 pm 2008
Stefan Richter
Re: [PATCH] firewire: fw-ohci: plug dma memory leak in A ...
Looks good and initial testing here is fine. I don't have a board with IOMMU though. Will look over it once more tomorrow, then submit it. -- Stefan Richter -=====-==--- --== ==--= http://arcgraph.de/sr/ --
Mar 25, 3:29 pm 2008
J.C. Pizarro
Poor performance now? Please, put weighted velocities ct ...
[1] &quot;Performance changes between 2.6.13 and 2.6.23&quot; 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=&gt; more interactivity. [2] &quot;Re: Serious performance regression in Wine applications and Linux ...
Mar 25, 1:29 pm 2008
J.C. Pizarro
Re: Poor performance now? Please, put weighted velocitie ...
I forgot this link, thanks! It seems that they don't make ++ of counters in each switch ocurr. I don't know how they record the switches. The current scheduler don't take the count or the velocity of ctxts Luck boy ;) ! --
Mar 25, 1:50 pm 2008
Ray Lee
Re: Poor performance now? Please, put weighted velocitie ...
There are already counters recording the switches: My parents were married. --
Mar 25, 1:38 pm 2008
Ken Moffat
Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
Hi, on one of my boxes, I've got a problem with gdm and kernels newer than 2.6.24 (tested on 2.6.24.2, 2.6.24.4). If I try to restart or shut down from gdm, the window disappears but the X background remains and the box stays in runlevel 5 until I switch to a tty and shut it down (as root) or give it a 3-fingered salute to reboot. The same with 2.6.25-rc6-git8. The only oddity in the logs is a large block of Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message: 'GET_CONFIG ...
Mar 25, 1:07 pm 2008
dcn
[Patch 4/5] run drivers/misc/xp through scripts/Lindent
Ran patches through scripts/Lindent. Signed-off-by: Dean Nelson &lt;dcn@sgi.com&gt; --- 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 ...
Mar 25, 12:25 pm 2008
dcn
[Patch 3/5] prepare XPC and XPNET for future support of ...
Prepared XPC and XPNET for future support of SGI's UV architecture. Made changes so it compiles on x86_64. Added support for up to 256 partitions. Cleaned up BTE error conversion for is64 sn2. Signed-off-by: Dean Nelson &lt;dcn@sgi.com&gt; --- arch/ia64/sn/kernel/setup.c | 4 drivers/misc/Kconfig | 2 drivers/misc/xp/Makefile | 5 drivers/misc/xp/xp.h | 382 ++++++++++---------- drivers/misc/xp/xp_main.c | 181 ++++++--- ...
Mar 25, 12:25 pm 2008
Dean Nelson
Re: [Patch 5/5] run drivers/misc/xp through scripts/chec ...
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); --
Mar 25, 1:05 pm 2008
dcn
[Patch 5/5] run drivers/misc/xp through scripts/checkpatch.pl
Addressed issues raised by scripts/checkpatch.pl. Removed unnecessary curly braces. Eliminated uses of volatiles and use of kernel_thread() and daemonize(). Signed-off-by: Dean Nelson &lt;dcn@sgi.com&gt; --- drivers/misc/xp/xp_main.c | 68 ++++------ drivers/misc/xp/xp_sn2.c | 23 +-- drivers/misc/xp/xp_uv.c | 2 drivers/misc/xp/xpc.h | 116 ++++++++--------- drivers/misc/xp/xpc_channel.c | 243 +++++++++++++++--------------------- ...
Mar 25, 12:25 pm 2008
dcn Mar 25, 12:25 pm 2008
Dean Nelson
Re: [Patch 0/5] prepare XPC and XPNET to support SGI UV
It looks like the 2nd patch of this set has been blocked from the mailing list because of its size. At least that's my assumption. The size of the five patches are as follows (listed in patch order): -rw-r--r-- 1 dcn os1 4880 2008-03-25 14:05 uncached-pages -rw-r--r-- 1 dcn os1 471050 2008-03-25 14:10 move-xp -rw-r--r-- 1 dcn os1 203046 2008-03-25 14:14 generic-xp -rw-r--r-- 1 dcn os1 163868 2008-03-25 14:17 Lindent -rw-r--r-- 1 dcn os1 49723 2008-03-25 14:46 checkpatch.pl The ...
Mar 25, 1:14 pm 2008
dcn
[Patch 0/5] prepare XPC and XPNET to support SGI UV
This set of five patches moves XPC and XPNET to drivers/misc/xp in preparation for enabling X86_64 support. --
Mar 25, 12:25 pm 2008
Andreas Schwab
Re: [Patch 0/5] prepare XPC and XPNET to support SGI UV
$ git diff -M or &quot;git config --global diff.renames true&quot; to make it permanent. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 &quot;And now for something completely different.&quot; --
Mar 25, 4:04 pm 2008
Luck, Tony
RE: [Patch 0/5] prepare XPC and XPNET to support SGI UV
Part 2 (which I got since you addressed it to me directly as well as to the list) has a couple of &quot;Space in indent is follwed by a tab&quot; 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 &quot;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 &amp; add which is needed for patch(1) ...
Mar 25, 3:49 pm 2008
Ingo Molnar Mar 25, 1:06 pm 2008
Cyrill Gorcunov
[PATCH] x86: entry_32.S - use flags from processor-flags.h
By including processor-flags.h we are allowed to use predefined macroses instead of keeping own ones Signed-off-by: Cyrill Gorcunov &lt;gorcunov@gmail.com&gt; --- 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 ...
Mar 25, 12:16 pm 2008
David Howells
[PATCH 1/2] AFS: Add a MAINTAINERS record for AFS
Add a MAINTAINERS record for AFS Signed-off-by: David Howells &lt;dhowells@redhat.com&gt; --- MAINTAINERS | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 73883b8..41d226e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -163,6 +163,12 @@ M: A2232@gmx.net L: linux-m68k@lists.linux-m68k.org S: Maintained +AFS FILESYSTEM &amp; AF_RXRPC SOCKET DOMAIN +P: David ...
Mar 25, 12:03 pm 2008
David Howells
[PATCH 2/2] AFS: prevent double cell registration
kafs doesn't check if the cell already exists - so if you do an echo &quot;add newcell.org 1.2.3.4&quot; &gt;/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 &lt;svens@stackframe.org&gt; Signed-off-by: David Howells &lt;dhowells@redhat.com&gt; --- fs/afs/cell.c | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) diff --git a/fs/afs/cell.c ...
Mar 25, 12:03 pm 2008
David Howells
Add missing consts to xattr function arguments
Add missing consts to xattr function arguments. Signed-off-by: David Howells &lt;dhowells@redhat.com&gt; --- fs/xattr.c | 41 ++++++++++++++++--------------- include/linux/security.h | 46 ++++++++++++++++++++--------------- include/linux/syscalls.h | 30 ++++++++++++----------- include/linux/xattr.h | 6 ++--- security/commoncap.c | 6 ++--- security/dummy.c | 13 +++++----- ...
Mar 25, 11:52 am 2008
Bill Davidsen
Re: RAID-1 performance under 2.4 and 2.6
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 &lt;davidsen@tmr.com&gt; &quot;We have more to fear from the bungling of the incompetent than from the machinations of the wicked.&quot; - from Slashdot --
Mar 25, 3:47 pm 2008
Emmanuel Florac
Re: RAID-1 performance under 2.4 and 2.6
Sure, however my application may behave similarly to dd, or worse, some external entity I don't have control upon (read : an annoying customer) may use dd as a benchmark and draw fallacious asumptions I need to sort out :) -- -------------------------------------------------- Emmanuel Florac www.intellique.com -------------------------------------------------- --
Mar 25, 3:09 pm 2008
Bill Davidsen
Re: RAID-1 performance under 2.4 and 2.6
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 &quot;noatime&quot; 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 ...
Mar 25, 3:37 pm 2008
Emmanuel Florac
RAID-1 performance under 2.4 and 2.6
I post there because I couldn't find any information about this elsewhere : on the same hardware ( Athlon X2 3500+, 512MB RAM, 2x400 GB Hitachi SATA2 hard drives ) the 2.4 Linux software RAID-1 (tested 2.4.32 and 2.4.36.2, slightly patched to recognize the hardware :p) is way faster than 2.6 ( tested 2.6.17.13, 2.6.18.8, 2.6.22.16, 2.6.24.3) especially for writes. I actually made the test on several different machines (same hard drives though) and it remained consistent across the board, with ...
Mar 25, 11:43 am 2008
Bill Davidsen
Re: RAID-1 performance under 2.4 and 2.6
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* ...
Mar 25, 4:42 pm 2008
Chris Snook
Re: RAID-1 performance under 2.4 and 2.6
dd uses unaligned stack-allocated buffers, and defaults to block sized I/O. To call this inefficient is a gross understatement. Modern applications which care about streaming I/O performance use large, aligned buffers which allow the kernel to efficiently optimize things, or they use direct I/O to do it themselves, or they make use of system calls like fadvise, madvise, splice, etc. that inform the kernel how they intend to use the data or pass the work off to the kernel completely. dd ...
Mar 25, 4:13 pm 2008
Chris Snook
Re: RAID-1 performance under 2.4 and 2.6
It means you shouldn't use dd as a benchmark. -- Chris --
Mar 25, 3:00 pm 2008
Andrew Morton
Re: [PATCH] vfs: Fix lock inversion in drop_pagecache_sb()
On Tue, 25 Mar 2008 19:12:27 +0100 hrm. So we have a random ref on an inode without holding inode_lock. If we race with invalidate_list() we end up with an inode stuck on s_inodes and &quot;Self-destruct in 5 seconds. Have a nice day...&quot;, don't we? --
Mar 25, 12:53 pm 2008
Trond Myklebust
Re: [PATCH] vfs: Fix lock inversion in drop_pagecache_sb()
Calling drop_pagecache_sb() without having a reference to 'sb'? Surely not... Trond --
Mar 25, 3:01 pm 2008
Jan Kara
[PATCH] vfs: Fix lock inversion in drop_pagecache_sb()
Fix longstanding lock inversion in drop_pagecache_sb by dropping inode_lock before calling __invalidate_mapping_pages(). We just have to make sure inode won't go away from under us by keeping reference to it and putting the reference only after we have safely resumed the scan of the inode list. A bit tricky but not too bad... Signed-off-by: Jan Kara &lt;jack@suse.cz&gt; CC: Fengguang Wu &lt;wfg@mail.ustc.edu.cn&gt; CC: David Chinner &lt;dgc@sgi.com&gt; --- fs/drop_caches.c | 8 +++++++- 1 files changed, ...
Mar 25, 11:12 am 2008
Daniel Yeisley
[PATCH] list_add corruption in slab.c
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 &lt;dan.yeisley@unisys.com&gt; --- 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 @@ ...
Mar 25, 9:57 am 2008
Oliver Pinter
Re: [PATCH] list_add corruption in slab.c
thanks for the fast answer -- Thanks, Oliver --
Mar 25, 2:42 pm 2008
Pekka Enberg
Re: [PATCH] list_add corruption in slab.c
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 --
Mar 25, 11:45 am 2008
Oliver Pinter
Re: [PATCH] list_add corruption in slab.c
Hi Pekka this patch for 2.6.22? (http://repo.or.cz/w/linux-2.6.22.y-op.git) --8&lt;-- /* 1) create the cache_cache */ INIT_LIST_HEAD(&amp;cache_chain); list_add(&amp;cache_cache.next, &amp;cache_chain); cache_cache.colour_off = cache_line_size(); cache_cache.array[smp_processor_id()] = &amp;initarray_cache.cache; cache_cache.nodelists[node] = &amp;initkmem_list3[CACHE_CACHE]; --&gt;8-- from 2.6.22's slab.c -- Thanks, Oliver
Mar 25, 2:27 pm 2008
Daniel Yeisley
Re: [PATCH] list_add corruption in slab.c
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 &lt;dan.yeisley@unisys.com&gt; --- 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 @@ ...
Mar 25, 1:44 pm 2008
Pekka Enberg
Re: [PATCH] list_add corruption in slab.c
Hi Oliver, No. It fixes the following commit which is not in nor is it required for 2.6.22: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=556a16... --
Mar 25, 2:38 pm 2008
Pekka Enberg
Re: [PATCH] list_add corruption in slab.c
Hi Daniel, Yeah, but the second change is needed; otherwise we forget to fix up some of the bootstrap caches. &gt; Signed-off-by: Dan Yeisley &lt;dan.yeisley@unisys.com&gt; Reviewed-by: Pekka Enberg &lt;penberg@cs.helsinki.fi&gt; 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 --
Mar 25, 2:13 pm 2008
Chris Snook
Re: [patch] srat, x86_64: Add support for nodes spanning ...
Is this hunk a leftover from your testing? You're not using the config option anywhere, and there isn't really anything in this patch that would justify making this a separate config option in mainline. -- Chris --
Mar 25, 10:28 am 2008
Suresh Siddha
[patch] srat, x86_64: Add support for nodes spanning oth ...
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 &lt;suresh.b.siddha@intel.com&gt; --- 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 ...
Mar 25, 10:14 am 2008
Suresh Siddha
Re: [patch] srat, x86_64: Add support for nodes spanning ...
Its the generic -mm code which needs this. Please refer to early_pfn_in_nid() and its usage in memmap_init_zone() thanks, suresh --
Mar 25, 10:38 am 2008
Alex Chiang
[PATCH 0/4, v12] PCI, ACPI: Physical PCI slot objects
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 --
Mar 25, 10:09 am 2008
Alex Chiang
[PATCH 1/4] Construct one fakephp slot per pci slot
Register one slot per slot, rather than one slot per function. Change the name of the slot to fake%d instead of the pci address. Signed-off-by: Alex Chiang &lt;achiang@hp.com&gt; Signed-off-by: Matthew Wilcox &lt;matthew@wil.cx&gt; --- drivers/pci/hotplug/fakephp.c | 85 ++++++++++++++-------------------------- 1 files changed, 30 insertions(+), 55 deletions(-) diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c index 94b6401..6c14b4d 100644 --- ...
Mar 25, 10:12 am 2008
Alex Chiang
[PATCH 2/4] Export kobject_rename for pci_hotplug_core
Export kobject_rename() to fix the following link error. This happens when pci_hotplug_core driver is compiled as a kernel module. ERROR: &quot;kobject_rename&quot; [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 &lt;kaneshige.kenji@jp.fujitsu.com&gt; Acked-by: Alex Chiang &lt;achiang@hp.com&gt; --- lib/kobject.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff ...
Mar 25, 10:12 am 2008
Alex Chiang
[PATCH 3/4] Introduce pci_slot
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 ...
Mar 25, 10:13 am 2008
Alex Chiang
[PATCH 4/4] ACPI PCI slot detection driver
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 -&gt; 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 -&gt; v10: Allow an hp driver to ...
Mar 25, 10:14 am 2008
Scott Wood
Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
Shouldn't this depend on the user enabling GPIO support? Some 8xx boards are very memory-constrained, so we don't want to be making the kernel even bigger than it already is unless it's actually needed. -Scott --
Mar 25, 10:16 am 2008
Jochen Friedrich
[PATCH] [POWERPC] CPM1: implement GPIO LIB API
Implement GPIO LIB API on CPM1 Freescale SoC. Signed-off-by: Jochen Friedrich &lt;jochen@scram.de&gt; --- 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 --- ...
Mar 25, 9:56 am 2008
Sanders, Rob M.
RE: Performance changes between 2.6.13 and 2.6.23
-----Original Message----- From: madrabbit@gmail.com on behalf of Ray Lee Sent: Tue 3/25/2008 12:41 PM To: Sanders, Rob M. Cc: linux-kernel@vger.kernel.org; bart.vanassche@gmail.com Subject: Re: Performance changes between 2.6.13 and 2.6.23 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 ...
Mar 25, 9:44 am 2008
Roel Kluin
Re: [PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) ...
Sorry for the triple mail, it appeared to fail twice. --
Mar 25, 9:08 am 2008
Roel Kluin
[PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) in ...
from include/linux/ieee80211.h:274: #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 --- ! has a higher priority than &amp; Signed-off-by: Roel Kluin &lt;12o3l@tiscali.nl&gt; --- 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 ...
Mar 25, 9:03 am 2008
Roel Kluin
[PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) in ...
from include/linux/ieee80211.h:274: #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 --- ! has a higher priority than &amp; Signed-off-by: Roel Kluin &lt;12o3l@tiscali.nl&gt; --- 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 ...
Mar 25, 9:03 am 2008
Chatre, Reinette
RE: [PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) ...
I see. The patch is small and I thus assume a merge conflict will be easy to resolve. Yet ... I do not know what is really involved in the upstream code movements, while I know that you do. If you say it is better to wait until stable then I am ok with it. Thanks Reinette --
Mar 25, 11:26 am 2008
Chatre, Reinette
RE: [PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) ...
This patch has already been acked and merged into wireless-testing, and afaik already pushed further upstream. Reinette --
Mar 25, 9:30 am 2008
John W. Linville
Re: [PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) ...
Yes, but FWIW the problem exists in the 2.6.25 stream as well. I've been holding-back a patch to fix it there, trying to decide if it is worth creating the merge conflict to fix it there. I'm inclined to think it is better to let things lay as they are and send that patch for the -stable series once 2.6.25 ships. Any thoughts on that? John -- John W. Linville linville@tuxdriver.com --
Mar 25, 10:42 am 2008
Roel Kluin
[PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) in ...
from include/linux/ieee80211.h:274: #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 --- ! has a higher priority than &amp; Signed-off-by: Roel Kluin &lt;12o3l@tiscali.nl&gt; --- 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 ...
Mar 25, 9:03 am 2008
Tomas Winkler
Re: [PATCH][RESEND] wireless: convert !X &amp; Y to !(X &amp; Y) ...
On Tue, Mar 25, 2008 at 8:26 PM, Chatre, Reinette I have to find the patch but I believe we've published a fix for this long before this particular patch was born. Anyhow if HT is enabled in 2.6.25 I would prefer a conflict then a bug. Thanks Tomas --
Mar 25, 11:59 am 2008
Sosnowski, Maciej
RE: [patch 51/76] ioat: fix ack handling, driver must en ...
Acked-by: Maciej Sosnowski &lt;maciej.sosnowski@intel.com&gt; --------------------------------------------------------------------- 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). ...
Mar 25, 8:55 am 2008
Carl Love
[Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
This patch fixes a bug in the code that records the SPU data and context switches. The buffer_mutex lock must be held when the kernel is adding data to the buffer between the kernel and the OProfile daemon. The lock is not being held in the current code base. This patch fixes the bug using work queues. The data to be passed to the daemon is caputured by the interrupt handler. The workqueue function is invoked to grab the buffer_mutex lock and add the data to the buffer. Signed-off-by: ...
Mar 25, 8:58 am 2008
Thomas Klein
[PATCH 2.6.24-stable] ehea: Fix IPv6 support
Indicate that HEA calculates IPv4 checksums only Signed-off-by: Thomas Klein &lt;tklein@de.ibm.com&gt; --- 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 &lt;asm/io.h&gt; #define DRV_NAME &quot;ehea&quot; -#define DRV_VERSION &quot;EHEA_0083&quot; +#define DRV_VERSION &quot;EHEA_0083a&quot; ...
Mar 25, 8:56 am 2008
Marin Mitov
[BUG] unsolicited IRQ disabling at the IO-APIC leading t ...
WAS: net: tx timeouts with skge, 8139too, dmfe drivers/NICs Hi all, I am observing rare freezes(blocking) of eth0 with: NETDEV WATCHDOG: eth0: transmit timed out in dmesg output. The problem has been already described in a previous message: http://lkml.org/lkml/2008/2/25/312 with some additional observations, as described in: http://lkml.org/lkml/2008/3/12/96 Recently I found that the IRQ# used by the driver/NIC has been somehow disabled/masked at the IO-APIC, blocking the ...
Mar 25, 8:15 am 2008
Petr Tesarik
[PATCH] Discard notification signals when a tracer exits
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-&gt;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 &lt;ptesarik@suse.cz&gt; --- exit.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/kernel/exit.c +++ b/kernel/exit.c @@ ...
Mar 25, 7:31 am 2008
Petr Tesarik
Re: [PATCH] Discard notification signals when a tracer exits
Oh, and here is a testing script for the first hunk. It fails on all kernels I have tried. The second hunk can also be tested if you run strace on the traced process instead of attaching to a running one, but I didn't figure out how to get the PID of the traced process within a
Mar 25, 7:37 am 2008
Oleg Nesterov
Re: [PATCH] Discard notification signals when a tracer exits
Additional note. Suppose that the tracee dequeues the &quot;good&quot; signal, notices PT_PTRACED and calls ptrace_stop(). We set TASK_TRACED under -&gt;siglock, without holding tasklist_lock. At this moment you kill strace, it clears -&gt;exit_code. The tracee notices it is not traced any longer and returns to get_signal_to_deliver(). Since -&gt;exit_code is cleared, the &quot;right&quot; 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 ...
Mar 25, 9:33 am 2008
Roland McGrath
Re: [PATCH] Discard notification signals when a tracer exits
I think that's wrong. When the tracer dies unceremoniously, the tracee should continue as if it had not been traced. Your change makes it swallow a normal signal waiting to be delivered, and then resume as if noone had ever sent a signal. There is indeed a longstanding problem for tracing-induced signals (e.g. SIGTRAP for single-step or exec). One can be queued but not yet delivered while the tracer detaches or dies, and then it gets delivered to the unsuspecting process without any ...
Mar 25, 3:38 pm 2008
Oleg Nesterov
Re: [PATCH] Discard notification signals when a tracer exits
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 -&gt;exit_code and then you kill(ptracer, SIGKILL). If we really need this, _perhaps_ it is better to change do_syscall_trace(), so that ...
Mar 25, 9:16 am 2008
Sanders, Rob M.
RE: Performance changes between 2.6.13 and 2.6.23
Bart, Each process is single threaded, although each process is built with the -lpthread library. For this particular application I would expect the bottleneck to be in I/O (between processes) bound. I hadn't thought about trying to boot YDL4 using the new kernel, I'll try that, and I'll look at the lmench2 and interbench. Thanks.... Rob -----Original Message----- From: Bart Van Assche [mailto:bart.vanassche@gmail.com] Sent: Tue 3/25/2008 9:25 AM To: Sanders, Rob M. Cc: ...
Mar 25, 6:52 am 2008
Bart Van Assche
Re: Performance changes between 2.6.13 and 2.6.23
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 ...
Mar 25, 7:23 am 2008
Michael Meyer
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
Can this be achieved during runtime also? And is it possible to switch back to SMP after that? Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go --
Mar 25, 9:38 am 2008
Andi Kleen
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
P0 should also work fine with cpu hotplug. At least in theory. -Andi --
Mar 25, 10:57 am 2008
Len Brown
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
this above is the baseline, yes? it is same as if you used no boot param Please post the contents of # grep . /sys/devices/system/cpu/cpu*/cpufreq/* and also grep . /proc/acpi/processor/*/power My guess that the maxcpus=1 case benefits from turbo mode, aka EIDA. That benefit, however, is subject to this bug: http://bugzilla.kernel.org/show_bug.cgi?id=5471 because for a single thread to run faster than the marketing MHz, the other thread must be in deep-idle, which is prevented by the ...
Mar 25, 4:27 pm 2008
Luciano Rocha
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
maxcpus=3D1 should turn off the SMP alternative and switch to UP only, optimising some locks and instructions. --=20 Luciano Rocha &lt;luciano@eurotux.com&gt; Eurotux Inform=E1tica, S.A. &lt;http://www.eurotux.com/&gt;
Mar 25, 7:08 am 2008
Michael Meyer
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
--- Wander Winkelhorst &lt;w.winkelhorst@gmail.com&gt; Intel Core 2 Duo E6600 (2.4 Ghz). I do not think that it is capable of dynamically overclocking. $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 1600.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : ...
Mar 25, 10:56 am 2008
Andi Kleen
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
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 --
Mar 25, 10:16 am 2008
Wander Winkelhorst
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
What kind of CPU are you using? Some Intel CPU's do &quot;funny stuff&quot;, like dynamically overclocking itself when working on a single thread, or using all of the 2nd level cache instead of sharing it with the second core. Regards, Wander Winkelhorst. --
Mar 25, 10:49 am 2008
Michael Meyer
Re: performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; / ...
I had the following time values: maxcpus=1: real 0m1.642s user 0m1.528s sys 0m0.068s maxcpus=2 and echo 1 &gt; /sys/devices/system/cpu/cpu1/online: real 0m2.579s user 0m4.096s sys 0m0.160s maxcpus=2 and echo 0 &gt; /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 --
Mar 25, 10:23 am 2008
Michael Meyer
performance differences: &quot;maxcpus=1&quot; vs. &quot;echo 0 &gt; /sys/ ...
Hi, what is the difference between booting a dual core machine with &quot;maxcpus=1&quot; or by deactivating the second core at run time with &quot;echo 0 &gt; /sys/devices/system/cpu/cpu1/online&quot;? I observed a funny behaviour of apache ant: although it uses javac which is single threaded, a compile run with &quot;maxcpus=1&quot; is actually faster than a compile run with both cores activated. But with the second core deactivated using &quot;echo 0 &gt; /sys/devices/system/cpu/cpu1/online&quot; it is even slower than with both ...
Mar 25, 6:47 am 2008
Greg Freemyer
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 ...
Mar 25, 6:51 am 2008
Ric Wheeler
Re: What to do about the 2TB limit on HDIO_GETGEO ?
I think that there are many embedded applications (lots of them linux based) which have large amounts of storage behind low power, low cost 32 bit CPU's. Think of the home/small office NAS boxes that you can get from bestbuy or other big box stores. Those devices today have 4 S-ATA drives (each of which can be 1TB in size). Also, if you have a very low end box, it can still access really large storage over iSCSI or a SAN which will present as a local, large device. Over time, even ...
Mar 25, 7:31 am 2008
Ric Wheeler
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 ...
Mar 25, 8:48 am 2008
Mark Lord
Re: What to do about the 2TB limit on HDIO_GETGEO ?
.. Yeah. Except Dell will undoubtedly have them in desktops within 2 years, and tons of people (myself included) still use 32-bit (K)Ubuntu on our systems, simply for the better binary compatibility that it is perceived to give with things like browser plugins and stuff. Using sysfs interfaces might be a good alternative, if they were easier to use, but drives are not directly accessible there using the dev_t value from stat(2). Instead, software has to search everything inside ...
Mar 25, 6:34 am 2008
Andrew Paprocki
Re: What to do about the 2TB limit on HDIO_GETGEO ?
I can attest to this. I hear from a reliable source (manufacturer) that 2TB 3.5&quot; 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 --
Mar 25, 8:25 am 2008
Matthew Wilcox
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Don't those devices run into trouble with fsck? The amount of memory you need to fsck a device is obviously going to depend on the filesystem, but it has to grow with device size, and I'm not sure that 4GB is enough virtual address space to fsck 2TB. -- Intel are signing my paycheques ... these opinions are still mine &quot;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.&quot; --
Mar 25, 8:34 am 2008
Theodore Tso
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 ...
Mar 25, 9:47 am 2008
Theodore Tso
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Whoops, screwed up my math. The block bitmap for a 2TB filesystem is 64 megs, not 512 megs. 2*41 / 2**12 / 2**3 == 2**26, or 64mb. E2fsck in the worst case will allocate 5 inode bitmaps and 3 block bitmaps, plus various arrays for directory blocks and keeping track of refcounts (which are optimized for counnts of 0 and 1, so lots of hard links will blow up your memory usage, although we do have a tdb option which helps in that particular case). So I'd say that most of the time 3GB of ...
Mar 25, 1:51 pm 2008
trance
informacio!
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 ...
Mar 24, 7:40 pm 2008
Bart Van Assche
Re: Performance changes between 2.6.13 and 2.6.23
Is this a singlethreaded or a multithreaded application ? Is this application CPU-bound or IO-bound ? Does it rely a lot on memory allocation ? I'm not sure this will tell you the cause, but what might help is to compile and run lmbench2 and interbench, and to compare the results for the two kernel versions. Make sure that only the kernel version differs between the two test runs, and that all other components (a.o. libc and libpthread) stay the same. Booting the old YDL with the new kernel ...
Mar 25, 6:25 am 2008
Ray Lee
Re: Performance changes between 2.6.13 and 2.6.23
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 &quot;echo 5 &gt; /proc/sys/kernel/sched_features&quot; and see if that makes any difference? --
Mar 25, 9:41 am 2008
Sanders, Rob M.
Performance changes between 2.6.13 and 2.6.23
Hello all, I've been lurking on the digest for some time (don't want to receive full lkml traffic at work) and saw the posts about Wine performance regressions in 2.6.24. Some of what I saw there, particularly Andi Kleen's responses, mirror something that I see on my box at home. I had emailed Andi directly since I only read the digest, and I'm posting this here at his suggestion. Please CC: rms@zai.com with any replies, as I'm only getting the lkml digest. I'm running on a dual 2GHZ G5 ...
Mar 25, 5:34 am 2008
Andi Kleen
Re: [PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c ...
This is likely a code pessimization because &quot;current&quot; is inline assembler and many gcc versions cannot CSE it. -Andi --
Mar 25, 5:08 am 2008
Robert P. J. Day
[PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c more ...
Rewrite these source files more simply by deleting the superfluous &quot;tsk&quot; task_struct pointer and rephrasing in terms of the &quot;current&quot; task pointer. Signed-off-by: Robert P. J. Day &lt;rpjday@crashcourse.ca&gt; --- in addition to making the code slightly simpler, this makes it easier to read since there's more information in: set_current_state(TASK_UNINTERRUPTIBLE); as opposed to: set_task_state(tsk, TASK_UNINTERRUPTIBLE); if it's not clear what &quot;tsk&quot; refers to. compile ...
Mar 25, 4:02 am 2008
Robert P. J. Day
Re: [PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c ...
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, ...
Mar 25, 5:42 am 2008
Andrew Morton
Re: [PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c ...
On Tue, 25 Mar 2008 08:42:48 -0400 (EDT) A crude measyure is /usr/bin/size. Your patch increased rwsem-spinlock.o from 1595 bytes of text up to 1629. A text size increase isn't necessarily always a bad thing, but it does need to be monitored, understood, explained, etc. --
Mar 25, 12:14 pm 2008
Andi Kleen
Re: [PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c ...
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 --
Mar 25, 5:36 am 2008
Robert P. J. Day
Re: [PATCH] RWSEM: Rewrite rwsem.c and rwsem-spinlock.c ...
i'm not sure what this means -- which of the transformations in that patch is considered unsafe? here's a typical simplification: - tsk = current; - set_task_state(tsk, TASK_UNINTERRUPTIBLE); + set_current_state(TASK_UNINTERRUPTIBLE); there's all sorts of usage of set_current_state() throughout the tree. how is simplifying the code in these two files in exactly the same way any different? or am i missing something because this involves semaphores? rday p.s. ...
Mar 25, 5:27 am 2008
Jean Delvare
[GIT PULL] i2c fixes for 2.6.25
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): ...
Mar 25, 3:43 am 2008
Remy Bohmer
[Question]: About FAT patent
Hello All, I found this site: http://www.theregister.co.uk/2006/01/11/microsoft_wins_patent_case/ Is the FAT support in the kernel sensible to this? And if so, why is it still in the kernel? Kind Regards, Remy --
Mar 25, 3:25 am 2008
Shard Gupta
Allocating memory in the form of 'BITS'
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 --
Mar 25, 3:23 am 2008
Scott Lovenberg
Re: Allocating memory in the form of 'BITS'
If you want to set every bit to zero, you could use calloc(); otherwise, I think you'll need to use a bitmask and &quot;&lt;&lt;&quot;, &quot;&gt;&gt;&quot; (bit shift left, right). You could also probably do a bitwise '&amp;' and '|'. --
Mar 25, 3:36 am 2008
Avi Kivity
[GIT PULL] KVM fixes for 2.6.25-rc6
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: ...
Mar 25, 1:38 am 2008
Al Viro
[git pull] vfs patches
misc VFS fixes for 2.6.25. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus Shortlog: Al Viro (5): restore export of do_kern_mount() sanitize hppfs double dput() on failure exit in tiny-shmem double iput() on failure exit in hugetlb get stack footprint of pathname resolution back to relative sanity Christoph Hellwig (1): check for null vfsmount in dentry_open() Dave Hansen (2): hppfs pass vfsmount to ...
Mar 25, 1:17 am 2008
Linus Torvalds
Re: [git pull] vfs patches
Pulled. And looking at the diffs, I see sequences like dget(save.dentry); mntget(save.mnt); ... path_put(&amp;save); which looks very strange compared to the natural sequence: path_get(&amp;save); .. path_put(&amp;save); and yes, I realize the code was just moved (and the reason for the mixing is that the &quot;path_put()&quot; 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 ...
Mar 25, 9:05 am 2008
Al Viro
Re: [git pull] vfs patches
*nod* Keep in mind that there's a lot more coming post-.25; FWIW, there's another bunch of patches that probably ought to go before .25 (mount expiry stuff; I'll do a bit of reordering and probably ask to pull tomorrow). The next couple of cycles is going to get interesting around fs/{namei,namespace,pnode,super,dentry}.c --
Mar 25, 11:00 am 2008
Bart Van Assche
Re: Kernel compilation: make halts with error message &quot;* ...
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. --
Mar 25, 8:15 am 2008
Sam Ravnborg
Re: Kernel compilation: make halts with error message &quot;* ...
Thanks for letting us know. And using 'colon' in the path is a &quot;don't do that&quot; thing that we will not try to check for. Sam --
Mar 25, 11:22 am 2008
Bart Van Assche
Kernel compilation: make halts with error message &quot;*** t ...
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 ...
Mar 25, 1:15 am 2008
Robert P. J. Day
list splicing and list POISONing
based on a conversation we've been having on the newbies list, i'm curious about the rationale behind list &quot;POISON&quot;ing. from &lt;linux/list.h&gt;, when you splice one list into another, the head element from the original list is left hanging in space with its original prev and next pointer values unchanged: === static inline void __list_splice(struct list_head *list, struct list_head *head) { struct list_head *first = list-&gt;next; struct ...
Mar 25, 12:15 am 2008
Randy Dunlap
Re: linux-next: Tree for March 25 (ocfs2 build)
ocfs2 link/build problem with CONFIG_OCFS2_FS=y CONFIG_OCFS2_FS_O2CB=m ERROR: &quot;dlmunlock&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: &quot;dlm_setup_eviction_cb&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: &quot;dlm_register_eviction_cb&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: &quot;dlm_register_domain&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: &quot;dlm_unregister_domain&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] undefined! ERROR: &quot;dlm_unregister_eviction_cb&quot; [fs/ocfs2/ocfs2_stack_o2cb.ko] ...
Mar 25, 2:39 pm 2008
Stephen Rothwell
linux-next: Tree for March 25
Hi all, I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git (tar balls at http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. There were a few merge ...
Mar 24, 11:52 pm 2008
H. Peter Anvin
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
OK, note previous question: what is the motivation for having this as a whitelist (as opposed to a blacklist)? -hpa --
Mar 25, 6:38 am 2008
H. Peter Anvin
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
By the way, I want to clarify: I didn't mean it was *intended* as vendor-lockin, just that it's an undesirable effect of this. -hpa --
Mar 25, 4:01 pm 2008
H. Peter Anvin
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
Yes, using a whitelist of this type is wrong, IMO, and smells faintly of vendor-lockin. -hpa --
Mar 25, 1:38 pm 2008
H. Peter Anvin
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
That doesn't seem like it's specific to PAT? -hpa --
Mar 25, 4:06 pm 2008
Ingo Molnar
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
thanks, applied - we need this to widen the testing scope of the PAT changes. Ingo --
Mar 25, 3:58 am 2008
Venki Pallipadi
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
Main reason for white-list at this point is not to be side-tracked by real or potential erratas on older CPUs. Focussing on getting the support for this feature on current and future CPUs. If older CPUs have survived all these days without this feature, they should be doing OK. Other reason being the amount of testing we get on those older systems. I mean, any regression on some specific CPU is hard to find unless it is being tested or someone audits all the errata documents to prepare the ...
Mar 25, 12:08 pm 2008
Yinghai Lu
[PATCH] x86: pat cpu feature bit setting for known cpus
[PATCH] x86: pat cpu feature bit setting for known cpus Signed-off-by: Yinghai Lu &lt;yhlu.kernel@gmail.com&gt; 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-&gt;x86_vendor) { + case X86_VENDOR_AMD: + if (c-&gt;x86 &gt;= 0xf &amp;&amp; c-&gt;x86 &lt;= ...
Mar 24, 11:24 pm 2008
Pallipadi, Venkatesh
RE: [PATCH] x86: pat cpu feature bit setting for known cpus
Trimming of e820 memory is already done by Jesse's patch here commit 99fc8d424bc5d80 Are you referring to similar thing? Thanks, Venki --
Mar 25, 4:38 pm 2008
Ingo Molnar
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
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 --
Mar 25, 1:08 pm 2008
Yinghai Lu Mar 25, 11:03 am 2008
Yinghai Lu
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
if the PAT works, we may need to trim the memory according to MTRR, right? YH --
Mar 25, 4:05 pm 2008
Yinghai Lu
Re: [PATCH] x86: pat cpu feature bit setting for known cpus
could page table to set WRBACK the range that is not covered by MTRR in e820.. YH --
Mar 25, 4:08 pm 2008
Greg KH
[GIT PATCH] PCI fixes for 2.6.25-rc6 git tree
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 ...
Mar 24, 11:06 pm 2008
Greg Kroah-Hartman
[PATCH 2/2] driver core: debug for bad dev_attr_show() r ...
From: Andrew Morton &lt;akpm@linux-foundation.org&gt; Try to find the culprit who caused http://bugzilla.kernel.org/show_bug.cgi?id=10150 Cc: &lt;balajirrao@gmail.com&gt; Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt; Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt; --- drivers/base/core.c | 5 +++++ fs/sysfs/file.c | 8 +++++++- 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 7de543d..24198ad 100644 --- ...
Mar 24, 11:16 pm 2008
Greg KH
[GIT PATCH] driver core fixes against 2.6.25-rc6 git
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 ...
Mar 24, 11:05 pm 2008
Greg Kroah-Hartman
[PATCH 1/2] UIO: add pgprot_noncached() to UIO mmap code
From: Jean-Samuel Chenard &lt;jsamch@gmail.com&gt; Mapping of physical memory in UIO needs pgprot_noncached() to ensure that IO memory is not cached. Without pgprot_noncached(), it (accidentally) works on x86 and arm, but fails on PPC. Signed-off-by: Jean-Samuel Chenard &lt;jsamch@gmail.com&gt; Signed-off-by: Hans J Koch &lt;hjk@linutronix.de&gt; Cc: stable &lt;stable@kernel.org&gt; Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt; --- drivers/uio/uio.c | 2 ++ 1 files changed, 2 insertions(+), 0 ...
Mar 24, 11:16 pm 2008
Greg KH
[GIT PATCH] USB fixes for 2.6.25-rc6 git
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 ...
Mar 24, 11:04 pm 2008
Neil Brown
Re: 2.6.24.3 kernel panic in md raid1d queue_delayed_work_on
blk_remove_plug is always called with interrupts disabled. So why there are &quot;do_IRQ&quot; and similar calls further up the stack is surprising. However the list of function names is only indicative, not ^^^^^^ This shows that it died on a &quot;BUG&quot; or &quot;BUG_ON&quot; call. Did you see the text of that? Why do you say there was &quot;a kernel panic in queue_delayed_work_on&quot;. What exactly provided that information? --
Mar 24, 10:29 pm 2008
Atsushi Tsuji
[PATCH] kill_something_info: don't take tasklist_lock fo ...
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 ...
Mar 24, 9:27 pm 2008
Oleg Nesterov
Re: [PATCH] kill_something_info: don't take tasklist_loc ...
Hmm. Yes, group_send_sig_info() doesn't need tasklist_lock. But we take tasklist_lock to &quot;freeze&quot; the tasks list, so that we can't miss a new forked process. Same for __kill_pgrp_info(), we take tasklist to kill the whole group &quot;atomically&quot;. However. Is it really needed? copy_process() returns -ERESTARTNOINTR if signal_pending(), and the new task is always placed at the tail of the list. Looks like nobody can escape the signal, at least fatal or SIGSTOP. If the signal is ...
Mar 25, 6:56 am 2008
Alex Chiang
[PATCH 4/4] ACPI PCI slot detection driver
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 -&gt; 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 -&gt; v10: Allow an hp driver to ...
Mar 24, 9:17 pm 2008
Alex Chiang
[PATCH 2/4] Export kobject_rename for pci_hotplug_core
From: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt; Export kobject_rename() to fix the following link error. This happens when pci_hotplug_core driver is compiled as a kernel module. ERROR: &quot;kobject_rename&quot; [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 &lt;kaneshige.kenji@jp.fujitsu.com&gt; Acked-by: Alex Chiang &lt;achiang@hp.com&gt; --- lib/kobject.c | 1 ...
Mar 24, 9:16 pm 2008
Kenji Kaneshige
Re: [PATCH 4/4] ACPI PCI slot detection driver
Acked-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt; Thanks, Kenji Kaneshige --
Mar 24, 9:50 pm 2008
Kenji Kaneshige
Re: [PATCH 3/4] Introduce pci_slot
Acked-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt; Thanks, Kenji Kaneshige --
Mar 24, 9:49 pm 2008
Alex Chiang
[PATCH 0/4, v11] PCI, ACPI: Physical PCI slot objects
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 ...
Mar 24, 9:13 pm 2008
Alex Chiang
[PATCH 1/4] Construct one fakephp slot per pci slot
Register one slot per slot, rather than one slot per function. Change the name of the slot to fake%d instead of the pci address. Signed-off-by: Alex Chiang &lt;achiang@hp.com&gt; Signed-off-by: Matthew Wilcox &lt;matthew@wil.cx&gt; --- drivers/pci/hotplug/fakephp.c | 85 ++++++++++++++-------------------------- 1 files changed, 30 insertions(+), 55 deletions(-) diff --git a/drivers/pci/hotplug/fakephp.c b/drivers/pci/hotplug/fakephp.c index 94b6401..6c14b4d 100644 --- ...
Mar 24, 9:15 pm 2008
Alex Chiang
[PATCH 3/4] Introduce pci_slot
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 ...
Mar 24, 9:17 pm 2008
Mark Lord Mar 25, 6:37 am 2008
Greg Freemyer
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 ...
Mar 25, 10:45 am 2008
Greg KH
Re: What to do about the 2TB limit on HDIO_GETGEO ?
&quot;should&quot;? why? Is this some new requirement that everyone needs? I've _never_ seen anyone ask for the ability to find sysfs devices by major:minor number in O(1) time. Is this somehow a place where such optimization is warranted? thanks, greg k-h --
Mar 25, 2:20 pm 2008
Randy Dunlap
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Ah, there's some sanity. :) --- ~Randy --
Mar 25, 12:34 pm 2008
Mark Lord
Re: What to do about the 2TB limit on HDIO_GETGEO ?
.. So long as we only add things, and not remove them, then any software that scans /sys/block/ shouldn't care, really. But yes, it could go elsewhere, too. Perhaps a /sys/dev/ directory, populated with symbolic links (or hard links?) back to the /sys/block/ entries, something like this: /sys/dev/block/8:0 -&gt; ../../../block/sda /sys/dev/block/8:1 -&gt; ../../../block/sda/sda1 /sys/dev/block/8:2 -&gt; ../../../block/sda/sda2 ... That's just a suggestion, really. And what about ...
Mar 25, 10:37 am 2008
Matthew Wilcox
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 &quot;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.&quot; --
Mar 25, 11:09 am 2008
H. Peter Anvin
Re: What to do about the 2TB limit on HDIO_GETGEO ?
It's not so much an issue of a few tens of lines of user space code, but rather the fact that something that should be O(1) is currently O(n). -hpa --
Mar 25, 1:36 pm 2008
James Bottomley
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Perhaps I've missed something, but surely geometry doesn't make sense on a &gt;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 --
Mar 25, 8:17 am 2008
Greg KH
Re: What to do about the 2TB limit on HDIO_GETGEO ?
How does this have anything to do with boot times? Do you really have a foolish shell script that iteratorates over every single disk in the sysfs tree for every disk? What does it do that for? I thought we were talking about 2TB disks here, with a proposed new ioctl, not foolishness of boot scripts... --
Mar 25, 4:00 pm 2008
Mark Lord
What to do about the 2TB limit on HDIO_GETGEO ?
(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 &quot;unsigned long&quot;, 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 ...
Mar 24, 9:02 pm 2008
Randy Dunlap
Re: What to do about the 2TB limit on HDIO_GETGEO ?
It's implemented. Not sure about how well used/tested it is. config EFI_PARTITION bool &quot;EFI GUID Partition support&quot; depends on PARTITION_ADVANCED select CRC32 help Say Y here if you would like to use hard disks under Linux which were partitioned using EFI GPT. --- ~Randy --
Mar 25, 10:52 am 2008
Andrew Morton
Re: What to do about the 2TB limit on HDIO_GETGEO ?
That sounds useful. But you're the one who has investigated this - please make a recommendation? --
Mar 24, 9:19 pm 2008
H. Peter Anvin
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Any time you want to get the sysfs information for a filesystem which is I pointed out that having a way to map device numbers to sysfs directories would have the same effect, *and* would be usable for other purposes. I'd rather see that than a new ioctl, and another, and another... ioctl()s are also nasty since they're generally root-only (or rather, device-owner only). Since the information is already in sysfs, there is no benefit to this hiding. Otherwise one could consider a ...
Mar 25, 4:05 pm 2008
H. Peter Anvin
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 --
Mar 25, 6:55 am 2008
James Bottomley
Re: What to do about the 2TB limit on HDIO_GETGEO ?
But I think where this is leading is that you've been using the geometry call, but all you really want to know is the actual partition start in sector units, so a new BLKGETPARTSTART (or something) ioctl that was designed to return a u64 would work for you? That sounds reasonable to me; so not a HDIO_GETGEO64 which gets us into trouble with geometries, but a simple ioctl that gives you exactly what you're looking for. James --
Mar 25, 12:32 pm 2008
H. Peter Anvin
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 --
Mar 25, 2:26 pm 2008
Greg KH
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Again, a simple udev rule will give you that today if you really want it... And I think 'udevinfo' can be used to retrieve this information as well. thanks, greg k-h --
Mar 25, 4:22 pm 2008
H. Peter Anvin
Re: What to do about the 2TB limit on HDIO_GETGEO ?
Probably a better thing to have would be a way to look up block devices in sysfs by device number. -hpa --
Mar 24, 10:13 pm 2008
Mark Lord
Re: What to do about the 2TB limit on HDIO_GETGEO ?
.. I haven't thought much about problems with the virtual geometry, because, as you say, we really don't care about it for the most part. We use LBA values from the partition tables rather than CHS. I suppose those also likely to be 32-bit limited. The &quot;partition offset&quot;, or &quot;starting sector&quot; is the important bit of information for most things. And that's currently available from HDIO_GETGEO, and from /sys/block/XXX/XXXn/start, if sysfs is mounted. We just need an easy way to get it, ...
Mar 25, 10:31 am 2008
Greg KH
Re: What to do about the 2TB limit on HDIO_GETGEO ?
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 --
Mar 25, 12:25 pm 2008
Neil Brown
Re: 2.6.24.3 bug in sysfs with md.
$ git describe 8118a859dc7abd873193986c77a8d9bdb877adc8 v2.6.24-rc3-412-g8118a85 Yes, I think that would be best. Thanks, --
Mar 24, 8:52 pm 2008
Neil Brown
Re: FW: [PATCH 008 of 9] md: Fix possible raid1/raid10 d ...
Can I assume you mean conf-&gt;nr_pending == conf-&gt;nr_queued ?? Yes, it is after reschedule_retry which increments -&gt;nr_queued, but also after conf-&gt;nr_queued--; in raid1d when the request is removed from the queue. Does that make sense? NeilBrown --
Mar 24, 8:41 pm 2008
Paul Mackerras
Please pull powerpc.git merge branch
Linus, Please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge once more. Kumar sent me a defconfig update for the Freescale platforms, and there is another 1-line fix from Grant Likely that only affects MPC5200B machines. Thanks, Paul. arch/powerpc/boot/dts/lite5200b.dts | 2 arch/powerpc/configs/ep8248e_defconfig | 74 +++++++--- arch/powerpc/configs/ep88xc_defconfig | 56 +++++-- ...
Mar 24, 8:32 pm 2008
Stephen Rothwell
What do you want from linux-next?
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/
Mar 24, 8:11 pm 2008
James Morris
Re: What do you want from linux-next?
AFAIK, this is also in linux-next. - James -- James Morris &lt;jmorris@namei.org&gt; --
Mar 25, 2:34 pm 2008
Josh Boyer
Re: What do you want from linux-next?
PowerPC is included as powerpc-next in the linux-next tree. josh --
Mar 25, 5:38 am 2008
Andrew Morton
Re: What do you want from linux-next?
afacit it's already working. The level of merge and build errors in the subsystem trees this time around is a tiny fraction of what it was at the same stage in 2.6.24-rcX. otoh perhaps this is because Ingo got tired of There are 60 or 80 &quot;susbsytem&quot; trees hosted in -mm at present: ... # spi # mfd # vt # kprobes # quota # i4l # i2o # ecryptfs # autofs # rtc # gpio # fbdev # md # pnp # ext2 # ext3 # ufs # udf # reiserfs # fat # documentation # cgroups # memcgroup # ...
Mar 24, 9:32 pm 2008
Randy.Dunlap
Re: What do you want from linux-next?
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 --
Mar 24, 8:59 pm 2008
Tetsuo Handa
Re: r-o bind in nfsd
I think link_path_walk() is not a good place to insert new LSM hooks for pathname based access control (AppArmor and TOMOYO) purpose because (1) The kernel don't know what operation (open/create/truncate etc.) will be done at the moment of link_path_walk(). (2) Not all operations call link_path_walk() before these operations are done. For example, ftruncate() doesn't call link_path_walk(). (3) The rename() and link() operations handle two pathnames. But, it is not ...
Mar 25, 4:45 am 2008
Neil Brown
Re: r-o bind in nfsd
The layers within the VFS are probably not very clearly defined, but I think one can fairly clearly see a difference between a &quot;filesystem&quot; layer and a &quot;namespace&quot; 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 &quot;namespace&quot; layer. The heart of this layer is probably link_path_walk. It allows mounts to ...
Mar 24, 7:52 pm 2008
NeilBrown
Re: r-o bind in nfsd
But do you want to impose path-name based controls to ftruncate? Surely once you have a file open for write (not O_APPEND), then no other permission is required to truncate the file, is it? If it is, then maybe the 'struct file' should be tagged at open time Not an insolvable problem. One could imagine an implementation where a TYPE_RENAME_FROM security check produced a cookie that was consumed by a TYPE_RENAME_TO security check. The cookie could then be used by the security module ...
Mar 25, 3:32 pm 2008
Jeff Garzik
[git patches] libata fixes
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 ...
Mar 24, 7:50 pm 2008
Mike Travis
[PATCH 12/12] cpu/node mask: reduce stack usage using MA ...
Replace usages of CPU_MASK_NONE, CPU_MASK_ALL, NODE_MASK_NONE, NODE_MASK_ALL to reduce stack requirements for large NR_CPUS and MAXNODES counts. Based on linux-2.6.25-rc5-mm1 # x86 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: H. Peter Anvin &lt;hpa@zytor.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- arch/x86/kernel/cpu/cpufreq/powernow-k8.c | 6 +++--- arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 4 ++-- arch/x86/kernel/genapic_flat_64.c ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 11/12] cpumask: reduce stack pressure in cpu_core ...
Return pointer to requested cpumask for cpu_coregroup_map() functions. Based on linux-2.6.25-rc5-mm1 # sparc Cc: David S. Miller &lt;davem@davemloft.net&gt; Cc: William L. Irwin &lt;wli@holomorphy.com&gt; # x86 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: H. Peter Anvin &lt;hpa@zytor.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- arch/x86/kernel/smpboot_32.c | 6 +++--- arch/x86/kernel/smpboot_64.c | 6 +++--- include/asm-sparc64/topology.h | 2 ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 06/12] cpumask: create pointer to node_to_cpumask ...
Create a simple macro to always return a pointer to the node_to_cpumask(node) value. This relies on compiler optimization to remove the extra indirection: #define node_to_cpumask_ptr(v, node) \ cpumask_t _##v = node_to_cpumask(node), *v = &amp;_##v For those systems with a large cpumask size, then a true pointer to the array element is used: #define node_to_cpumask_ptr(v, node) \ cpumask_t *v = &amp;(node_to_cpumask_map[node]) A node_to_cpumask_ptr_next() macro is provided to access ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 10/12] cpumask: reduce stack usage in build_sched ...
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 &lt;= 128, then stack space is used instead. Based on linux-2.6.25-rc5-mm1 Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- 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) ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 08/12] cpumask: pass temp cpumask variables in in ...
Pass pointers to temporary cpumask variables instead of creating on the stack. Based on linux-2.6.25-rc5-mm1 Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- kernel/sched.c | 218 ++++++++++++++++++++++++++++++++------------------------- 1 file changed, 126 insertions(+), 92 deletions(-) --- linux-2.6.25-rc5.orig/kernel/sched.c +++ linux-2.6.25-rc5/kernel/sched.c @@ -1739,17 +1739,17 @@ find_idlest_group(struct sched_domain *s * find_idlest_cpu - find ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 09/12] sched: fix memory leak in build_sched_domains
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 &lt;mingo@elte.hu&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- kernel/sched.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- linux-2.6.25-rc5.orig/kernel/sched.c +++ ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 07/12] cpumask: reduce stack usage in SD_x_INIT i ...
Remove empty cpumask_t (and all non-zero/non-null) variables in SD_*_INIT macros. Use memset(0) to clear. Also, don't inline the initializer functions to save on stack space in build_sched_domains(). Based on linux-2.6.25-rc5-mm1 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: H. Peter Anvin &lt;hpa@zytor.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- One checkpatch warning that I think can't be removed: ERROR: Macros with complex values should be ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 04/12] cpumask: pass cpumask by reference to acpi ...
Pass cpumask_t variables by reference in acpi-cpufreq functions. Based on linux-2.6.25-rc5-mm1 Cc: Len Brown &lt;len.brown@intel.com&gt; Cc: Dave Jones &lt;davej@codemonkey.org.uk&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- 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 @@ ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 05/12] init: move large array from stack to _init ...
Move large array &quot;struct bootnode nodes&quot; from stack to _initdata section. Based on linux-2.6.25-rc5-mm1 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: H. Peter Anvin &lt;hpa@zytor.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- arch/x86/mm/numa_64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.25-rc5.orig/arch/x86/mm/numa_64.c +++ linux-2.6.25-rc5/arch/x86/mm/numa_64.c @@ -381,9 +381,10 @@ static int __init ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 02/12] cpumask: pass pointer to cpumask for set_c ...
Instead of passing by value, the &quot;newly allowed cpus&quot; 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 &quot;silently&quot; pass the 2nd arg as a pointer, but you lose in the situation where you already have a pointer to the new ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 03/12] cpumask: reduce stack pressure in sched_affinity
Remove local and passed cpumask_t variables in kernel/sched.c Based on linux-2.6.25-rc5-mm1 Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: Paul Jackson &lt;pj@sgi.com&gt; Cc: Cliff Wickman &lt;cpw@sgi.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- arch/x86/kernel/cpu/mcheck/mce_amd_64.c | 46 ++++++++++++++++---------------- include/linux/sched.h | 2 - kernel/compat.c | 2 - kernel/rcupreempt.c | 4 +- kernel/sched.c ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 00/12] cpumask: reduce stack pressure from local/ ...
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 &quot;newly allowed&quot; cpumask. This removes 10784 bytes of stack usage but is an ABI change. * Add node_to_cpumask_ptr that returns pointer to ...
Mar 24, 7:31 pm 2008
Mike Travis
[PATCH 01/12] cpumask: Convert cpumask_of_cpu to static array
Here is a simple patch to use a per cpu cpumask instead of constructing one on the stack. Conditioned by NR_CPUS &gt; BITS_PER_LONG as if less than or equal, cpumask_of_cpu() generates a simple unsigned long. But the macro is changed to generate an lvalue so a pointer to cpumask_of_cpu can be provided. This removes 25552 bytes of stack usage, as well as reduces the code generated for each usage. Based on linux-2.6.25-rc5-mm1 Signed-off-by: Christoph Lameter ...
Mar 24, 7:31 pm 2008
Erez Zadok
non-idempotent Makefile in 2.6.25-rc6?
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 ...
Mar 24, 7:29 pm 2008
Mike Travis Mar 25, 8:02 am 2008
Mike Travis
[PATCH 08/10] net: remove NR_CPUS arrays in net/core/dev.c
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 &lt;davem@davemloft.net&gt; Cc: Alexey Kuznetsov &lt;kuznet@ms2.inr.ac.ru&gt; Cc: James Morris &lt;jmorris@namei.org&gt; Cc: Patrick McHardy &lt;kaber@trash.net&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- net/core/dev.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) --- linux-2.6.25-rc5.orig/net/core/dev.c +++ ...
Mar 24, 7:20 pm 2008
Alexey Dobriyan Mar 24, 10:57 pm 2008
Mike Travis
[PATCH 02/10] init: move setup of nr_cpu_ids to as early ...
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 &lt;tony.luck@intel.com&gt; # powerpc Cc: Paul Mackerras &lt;paulus@samba.org&gt; Cc: Anton Blanchard &lt;anton@samba.org&gt; # sparc Cc: David S. Miller &lt;davem@davemloft.net&gt; Cc: William L. Irwin &lt;wli@holomorphy.com&gt; # x86 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: H. Peter Anvin ...
Mar 24, 7:19 pm 2008
Mike Travis
[PATCH 06/10] x86: reduce memory and stack usage in inte ...
* 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 linux-2.6.25-rc5-mm1 Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Ingo Molnar &lt;mingo@redhat.com&gt; Cc: H. Peter Anvin &lt;hpa@zytor.com&gt; Cc: Andi ...
Mar 24, 7:20 pm 2008
Mike Travis
[PATCH 07/10] cpu: change cpu_sys_devices from array to ...
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 &lt;travis@sgi.com&gt; --- 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 ...
Mar 24, 7:20 pm 2008
Mike Travis
[PATCH 09/10] x86: oprofile: remove NR_CPUS arrays in ar ...
Change the following arrays sized by NR_CPUS to be PERCPU variables: static struct op_msrs cpu_msrs[NR_CPUS]; static unsigned long saved_lvtpc[NR_CPUS]; Also some minor complaints from checkpatch.pl fixed. Based on linux-2.6.25-rc5-mm1 Cc: Philippe Elie &lt;phil.el@wanadoo.fr&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- All changes were transparent except for: static void nmi_shutdown(void) { + struct op_msrs *msrs = &amp;__get_cpu_var(cpu_msrs); nmi_enabled = 0; ...
Mar 24, 7:20 pm 2008
Mike Travis
[PATCH 10/10] sched: Remove fixed NR_CPUS sized arrays i ...
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 ...
Mar 24, 7:20 pm 2008
Mike Travis
[PATCH 03/10] cpufreq: change cpu freq arrays to per_cpu ...
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 linux-2.6.25-rc5-mm1 Cc: Dave Jones &lt;davej@codemonkey.org.uk&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- drivers/cpufreq/cpufreq.c | 45 +++++++++++++++++++++------------------- drivers/cpufreq/cpufreq_stats.c | 24 ++++++++++----------- drivers/cpufreq/freq_table.c | 12 +++++----- 3 files ...
Mar 24, 7:19 pm 2008
Mike Travis
[PATCH 05/10] cpumask: Add cpumask_scnprintf_len function
Add a new function cpumask_scnprintf_len() to return the number of characters needed to display &quot;len&quot; 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 &lt;pj@sgi.com&gt; Signed-off-by: Mike Travis ...
Mar 24, 7:19 pm 2008
Mike Travis
[PATCH 04/10] acpi: change processors from array to per_ ...
Change processors from an array sized by NR_CPUS to a per_cpu variable. Based on linux-2.6.25-rc5-mm1 Cc: Len Brown &lt;len.brown@intel.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- drivers/acpi/processor_core.c | 18 ++++++++---------- drivers/acpi/processor_idle.c | 8 ++++---- drivers/acpi/processor_perflib.c | 18 +++++++++--------- drivers/acpi/processor_throttling.c | 14 +++++++------- include/acpi/processor.h | 2 +- 5 files changed, 29 ...
Mar 24, 7:19 pm 2008
Mike Travis
[PATCH 01/10] x86_64: Cleanup non-smp usage of cpu maps v4
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 &lt;ak@suse.de&gt; Cc: Ingo Molnar &lt;mingo@elte.hu&gt; Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt; Cc: Christoph Lameter &lt;clameter@sgi.com&gt; Signed-off-by: Mike Travis &lt;travis@sgi.com&gt; --- This patch was moved from the zero-based percpu variables patchset to here. --- arch/x86/kernel/genapic_64.c | 2 + ...
Mar 24, 7:19 pm 2008
Mike Travis
[PATCH 00/10] NR_CPUS: third reduction of NR_CPUS memory usage
Here's the third round of removing static allocations of arrays using NR_CPUS to size the length. The change is to use PER_CPU variables in place of the static tables, or allocate the array based on nr_cpu_ids. In addition, there's a cleanup of x86 non-smp code, the movement of setting nr_cpu_ids to setup_per_cpu_areas() so it's available as soon as possible, and a new function cpumask_scnprintf_len() to return the number of characters needed to display &quot;len&quot; cpumask bits. Affected ...
Mar 24, 7:19 pm 2008
Steven Rostedt
2.6.24.4-rt4
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 ...
Mar 24, 7:11 pm 2008
Joe Perches
[PATCH] scripts/Lindent - support gnu indent v2.2.10
The new version of indent supports positioning labels in column 1 using &quot;-il0&quot; http://www.nabble.com/Release-2.2.10-of-GNU-Indent-td15990700.html Add &quot;-il0&quot; if indent version &gt;= 2.2.10 Signed-off-by: Joe Perches &lt;joe@perches.com&gt; diff --git a/scripts/Lindent b/scripts/Lindent index 9468ec7..9c4b3e2 100755 --- a/scripts/Lindent +++ b/scripts/Lindent @@ -1,2 +1,18 @@ #!/bin/sh -indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1 &quot;$@&quot; +PARAM=&quot;-npro -kr -i8 -ts8 -sob -l80 -ss -ncs ...
Mar 24, 5:47 pm 2008
Alan Cox
Re: [PATCH] scripts/Lindent - support gnu indent v2.2.10
On Mon, 24 Mar 2008 17:47:34 -0700 Acked-by: Alan Cox &lt;alan@redhat.com&gt; Although I suspect some people may dislike that. --
Mar 25, 12:26 pm 2008
Randy Dunlap
Re: Silence two kerneldoc warnings in kernel/audit.c
I've sent the same patch to the audit people... so acked-by me. --- ~Randy --
Mar 24, 5:33 pm 2008
Dave Jones
Silence two kerneldoc warnings in kernel/audit.c
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 &lt;davej@codemonkey.org.uk&gt; --- 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 /** * ...
Mar 24, 5:27 pm 2008
Ingo Molnar
Re: [PATCH FIXED] x86: only enable interrupts when kerne ...
thanks Jeremy - will give it a shot. Ingo --
Mar 25, 3:56 am 2008
H. Peter Anvin
Re: [PATCH] x86: enable PAT for amd k8 and fam10h
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 --
Mar 24, 6:29 pm 2008
H. Peter Anvin
Re: [PATCH] x86: enable PAT for amd k8 and fam10h
Yes, which in turn should be merged with the 32-bit code in cpu/*.c. Personally I would prefer a blacklist rather than a whitelist, but that's nitpicking. -=hpa --
Mar 24, 9:45 pm 2008
Yinghai Lu
Re: [PATCH] x86: enable PAT for amd k8 and fam10h
PAT patches in x86.git latest, only support some intel CPUs. if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &amp;&amp; (boot_cpu_data.x86 == 0xF || (boot_cpu_data.x86 == 6 &amp;&amp; boot_cpu_data.x86_model &gt;= 15))) { if (cpu_has_pat) { return 1; } } should be moved to setup_64.c? YH --
Mar 24, 7:22 pm 2008
David Miller
Re: + netdev-cassini-use-shorter-list_splice_init-macro- ...
From: Andrew Morton &lt;akpm@linux-foundation.org&gt; I'll try to remember to create the next net tree at a suitable time or move over to a more predictable naming convention, perhaps something like net-next-2.6 :-) --
Mar 24, 5:14 pm 2008
Andrew Morton
Re: + netdev-cassini-use-shorter-list_splice_init-macro- ...
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. --
Mar 24, 5:00 pm 2008
Dave Airlie
Re: [2.6.25-rc6] possible regression: X server dying
Looks like a GL screensaver kicks in and blows away your X server sw-GL.. not sure how a new kernel could cause this though.. memory layout changes maybe.. --
Mar 24, 5:53 pm 2008
Ingo Molnar
Re: [PATCH] x86: PAT bug fix for attribute type check af ...
that needs a KERN_INFO, and should be labeled &quot;Warning: ...&quot;. Ingo --
Mar 25, 7:33 am 2008
Ilpo Järvinen
Re: [PATCH net-2.6] [TCP]: Must count fack_count also wh ...
&gt; &gt; On Mon, 03 Mar 2008 15:53:12 +0200, Ilpo J
Mar 25, 2:24 pm 2008
Jens Axboe
Re: [PATCH 0/5] Generic smp_call_function(), improvement ...
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 --
Mar 25, 11:00 am 2008
Jens Axboe
Re: [PATCH 0/5] Generic smp_call_function(), improvement ...
Doh, that was a pretty silly typo. Thanks, I've merged it with the patch! So now I/we just need to figure out why the hack to call init_call_single_data() is needed. You seem to imply it was being called too late, I thought perhaps too early. Where did you stick the init_call_single_data() call in? -- Jens Axboe --
Mar 25, 1:12 am 2008
Luck, Tony
RE: [PATCH 0/5] Generic smp_call_function(), improvement ...
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 ...
Mar 25, 9:48 am 2008
Ingo Molnar Mar 25, 9:33 am 2008
Glauber Costa
Re: [PATCH 2/2] [PATCH] move apic declarations to mach_apic.h
Problem is that local apic is not always present. I'm sending a replacement. --
Mar 25, 2:10 pm 2008
Ingo Molnar
Re: [PATCH 1/2] move ipi definitions to mach_ipi.h
this trivially doesnt build on 32-bit, for multiple reasons... Ingo --
Mar 25, 8:06 am 2008
Ingo Molnar Mar 25, 7:37 am 2008
Ingo Molnar Mar 25, 7:37 am 2008
Ingo Molnar
Re: [PATCH 2/2] [PATCH] move apic declarations to mach_apic.h
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
Mar 25, 12:58 pm 2008
Glauber Costa
[PATCH 0/2] get rid of mach_apic.h
yeah, the last patch sent was totally brown paper bag. I sent a previous version from the wrong machine, sorry. ingo, the new testing also unveiled a new catch, so I'm resending _both_ patches. please ignore both of them from the last run, and apply these instead --
Mar 25, 9:28 am 2008
Glauber Costa
[PATCH 1/2] [PATCH] move ipi definitions to mach_ipi.h
take them out of the x86_64-only asm/mach_apic.h Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 ++++++++++ ...
Mar 25, 9:28 am 2008
Glauber Costa
[PATCH 2/2] [PATCH] move apic declarations to mach_apic.h
take them out of the x86_64-specific asm/mach_apic.h Signed-off-by: Glauber Costa &lt;gcosta@redhat.com&gt; --- 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 ...
Mar 25, 9:28 am 2008
Andi Kleen
Re: [RFC 8/8] x86_64: Support for new UV apic
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 --
Mar 25, 11:06 am 2008
Jack Steiner
Re: [RFC 8/8] x86_64: Support for new UV apic
Will do (assuming it doesn't ripple thru too much code eliminating Deleted the memset. Should not be depending on poison values. Was useful Not sure that I understand why. The overhead of UV is minimal &amp; we want UV enabled in all distro kernels. OTOH, small embedded systems probably want to eliminate every last bit of unneeded code. By factored, do you means something like: is_uv_legacy_system() is_us_non_unique_apicid_system() ... Or maybe: Thanks for the careful ...
Mar 25, 10:56 am 2008
Andi Kleen
Re: [RFC 8/8] x86_64: Support for new UV apic
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 ...
Mar 25, 3:25 am 2008
Jack Steiner
Re: [RFC 8/8] x86_64: Support for new UV apic
Long term, I think that makes sense. However, I think that should be a separate series of patches since there are significant differences between the 32-bit and 64-bit genapic structs. --- jack --
Mar 25, 9:31 am 2008
Ingo Molnar
Re: [RFC 8/8] x86_64: Support for new UV apic
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 --
Mar 25, 7:30 am 2008
Jack Steiner
Re: [RFC 6/8] x86_64: Define the macros and tables for t ...
Most of the macros will never be used by generic kernel code, but we have UV-specific drivers that will use the information (GRU, XPC and XPMEM drivers). All of these are getting very close to being ready to Me either :-) I fixed the comment &quot;... BIOS code that runs with virtual == physical&quot; However, then I read the rest of your comments &amp; will take the approach of defining __va() in the BIOS code. That eliminates the need for --- jack --
Mar 25, 9:19 am 2008
Andi Kleen
Re: [RFC 6/8] x86_64: Define the macros and tables for t ...
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 --
Mar 25, 3:11 am 2008
Christoph Hellwig
Re: [RFC 5/8] x86_64: Add UV specific header for MMR def ...
Which is still not an excuse for the crap in there. Please submit a proper header with the needed defintions and shift &amp; mask defintions and helpers instead of the bitfields. --
Mar 25, 1:27 am 2008
Jack Steiner Mar 25, 6:45 am 2008
Andi Kleen
Re: [RFC 5/8] x86_64: Add UV specific header for MMR def ...
Not sure why you indent that? Normally it is not. I personally would consider it cleaner to put these into a asm-x86/uv/ sub directory -Andi --
Mar 25, 3:06 am 2008
Andi Kleen
Re: [RFC 5/8] x86_64: Add UV specific header for MMR def ...
bitfields are only problematic on portable code, which this isn't. -Andi --
Mar 25, 3:04 am 2008
Jack Steiner Mar 25, 6:33 am 2008
Len Brown
Re: [RFC 4/8] x86_64: Parsing for ACPI "SAPIC" table
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 --
Mar 24, 9:03 pm 2008
Jack Steiner
Re: [RFC 1/8] x86_64: Change GET_APIC_ID() from an inlin ...
Sorry - I meant to add to the patches that they are based on linux-2.6.25-rc5-mm1. Was the change to smpboot.c made in -rc6?? --- jack --
Mar 24, 6:37 pm 2008
Yinghai Lu Mar 24, 7:18 pm 2008
Zhang, Rui
Re: [PATCH 4/5] drivers/acpi: elide a non-zero test on a ...
Hi, Julia, I guess you didn't fix this one, right? Len, please apply this patch.:) Check the return value of thermal zone device registration correctly. Signed-off-by: Zhang Rui &lt;rui.zhang@intel.com&gt; --- drivers/acpi/thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/drivers/acpi/thermal.c =================================================================== --- linux-2.6.orig/drivers/acpi/thermal.c +++ linux-2.6/drivers/acpi/thermal.c @@ -1125,7 ...
Mar 25, 1:30 am 2008
Julia Lawall
Re: [PATCH 4/5] drivers/acpi: elide a non-zero test on a ...
&gt; And the return value of thermal_zone_device_register is also misused. Indeed, I missed that one. --
Mar 25, 1:41 am 2008
Julia Lawall
Re: [PATCH 4/5] drivers/acpi: elide a non-zero test on a ...
I did that one in a separate patch ([PATCH 5/5]), since it is in a different directory. Your patch is certainly more concise, but perhaps it is a little strange to put an &quot;else&quot; on an if where the &quot;then&quot; branch ends with a return or goto? That doesn't seem to be done very often anyway. --
Mar 25, 1:35 am 2008
Zhang, Rui
Re: [PATCH 4/5] drivers/acpi: elide a non-zero test on a ...
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 &lt;rui.zhang@intel.com&gt; --- drivers/acpi/fan.c | 3 +-- drivers/acpi/processor_core.c | 3 +-- drivers/acpi/thermal.c | 2 +- drivers/acpi/video.c | ...
Mar 25, 12:50 am 2008
Julia Lawall
Re: [PATCH 4/5] drivers/acpi: elide a non-zero test on a ...
Indeed, I did not fix this one. So your patch should be used in this case. --
Mar 25, 1:51 am 2008
Zhang, Rui Mar 25, 1:31 am 2008
Rafael J. Wysocki
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
Thanks. I'd like to fix the problem with dpm_list_mtx vs the disabling of interrupts you pointed out in the other message, though. Rafael --
Mar 25, 1:39 pm 2008
Oliver Neukum
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
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 --
Mar 25, 4:55 am 2008
Alan Stern
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
There is no such locking. It's perfectly legal for a device to be unregistered between prepare() and suspend(). I suppose it wouldn't hurt to add a general comment explaining that a device can be unregistered at any time except when one of its methods is running. Alan Stern --
Mar 25, 7:24 am 2008
Rafael J. Wysocki
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
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 --
Mar 25, 1:35 pm 2008
Alan Stern
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
I don't think so. What I have in mind is situations where there accessed has already been synchronized by other means, while the prepare() method is running. For example: Task 0 Task 1 ------ ------ -&gt;prepare() is called Waits for currently-running registration in task 1 to finish Does other stuff Receives a request to register a new child under dev Sees that dev-&gt;power.state is still DPM_ON, so goes ahead with the child's ...
Mar 25, 8:06 am 2008
Alan Stern
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
I don't see anything else to change. ACK. Alan Stern --
Mar 25, 8:12 am 2008
Oliver Neukum
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
I see no locking that would would prevent disconnect() in the window between This is better documented explicitly. Regards Oliver --
Mar 25, 6:37 am 2008
Rafael J. Wysocki
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
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 --
Mar 25, 5:40 am 2008
Alan Stern
Re: [RFC][PATCH] PM: Introduce new top level suspend and ...
The driver isn't supposed to prevent calls to its own probe(). The comment means that the subsystem -- or the rest of the kernel generally -- is supposed to avoid binding a driver to the device (thereby calling the probe routine), assuming the device isn't already bound. I don't expect this sort of thing to be very common. Mostly it happens when new kernel modules are loaded and new drivers are registered; we will have to block module loading during a sleep transition. It also happens when ...
Mar 25, 7:29 am 2008
Bjoern Olausson
Re: Burning CDs as user produces coasters (Plextor drive)
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 --
Mar 24, 6:46 pm 2008
Andi Kleen
Re: Fixing the main programmer thinko with the device model
&lt;heretic thought&gt;Has anybody ever considered just doing away with the problematic and bug prone and tricky reference counts for kobjects and switch to a simple garbage collector for them? -Andi --
Mar 25, 2:57 am 2008
Alan Mayer
Re: [PATCH] x86_64: resize NR_IRQS for large machines
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 -- --
Mar 25, 9:24 am 2008
Pavel Machek
Re: [PATCH] x86_64: resize NR_IRQS for large machines
This is very ugly. Why not include it unconditionally -- with guard in apicdef.h? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Mar 25, 4:10 pm 2008
Ingo Molnar
Re: [PATCH] x86_64: resize NR_IRQS for large machines
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 --
Mar 25, 9:19 am 2008
Balbir Singh
Re: [RFC][-mm] Memory controller add mm->owner
I've been looking at zap_threads, I suspect we'll end up implementing a similar loop, which makes me very uncomfortable. Adding code for the least possible scenario. It will not get invoked for CLONE_THREAD, but will get invoked for the case when CLONE_VM is set without CLONE_THREAD. I'll try and experiment a bit more and see what I come up with -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --
Mar 25, 4:41 am 2008
Balbir Singh
Re: [RFC][-mm] Memory controller add mm->owner
I kept that as a template for freeing up code. I'll remove that since OK Thanks for the review Balbir --
Mar 25, 8:48 am 2008
Li Zefan
Re: [RFC][-mm] Memory controller add mm->owner
Where is this function used? I don't see the corresponding one --
Mar 24, 6:26 pm 2008
Martin B. Andersen
Re: MMC/SD: data CRC errors and unknown SCR version on 2.6.14
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 --
Mar 25, 8:59 am 2008
David Chinner
Re: [RFC PATCH] freeze feature ver 1.0
Can you please split this into two patches - one which introduces the generic functionality *without* the timeout stuff, and a second patch that introduces the timeouts. I think this timeout stuff is dangerous - it adds significant complexity and really does not protect against anything that can't be done in userspace. i.e. If your system is running well enough for the timer to fire and unfreeze the filesystem, it's running well enough for you to do &quot;freeze X; sleep Y; unfreeze X&quot;. If you ...
Mar 24, 6:33 pm 2008
Roland McGrath
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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 ...
Mar 25, 3:00 pm 2008
Oleg Nesterov
Re: [PATCH] ptrace: it is fun to strace /sbin/init
I think we can't do this. From my /etc/inittab: c1:1235:respawn:/sbin/agetty 38400 tty1 linux If /sbin/agetty exits, we shouldn't reap it. /sbin/init should notice the death of login, and respawn the new child. Thanks to all for replies! I'll re-send this patch as one-liner, without any boot params or sysctls, and with long CC list. I hope someone (not me) will make a final authoritative decision ;) Oleg. --
Mar 25, 10:42 am 2008
Pavel Machek
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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 --
Mar 25, 7:47 am 2008
Stephen Smalley
Re: [PATCH] ptrace: it is fun to strace /sbin/init
Depends on the bounding set. Didn't it used to be the case that only init had CAP_SETPCAP (until the meaning of it was changed by the filesystem capability support)? Might want to double check with e.g. the vservers folks that they weren't relying in any way on special handling of init. -- Stephen Smalley National Security Agency --
Mar 25, 7:37 am 2008
Krzysztof Halasa Mar 25, 7:58 am 2008
Andi Kleen
Re: [PATCH] ptrace: it is fun to strace /sbin/init
We don't actually have that many ways for hard deadlocks even Sure, but if the deadlocks can be avoided on the kernel level (just making sure the children are already reaped) then it would be even better. -Andi --
Mar 25, 7:35 am 2008
Herbert Poetzl
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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, --
Mar 25, 12:07 pm 2008
Andi Kleen
Re: [PATCH] ptrace: it is fun to strace /sbin/init
There is no unresolvable deadlock no. -Andi --
Mar 25, 7:56 am 2008
Serge E. Hallyn
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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 --
Mar 25, 11:06 am 2008
Serge E. Hallyn
Re: [PATCH] ptrace: it is fun to strace /sbin/init
Still thinking it through, but it seems like special casing init isn't useful. There are likely to be other tasks with all capabilities set which the malicious task could just as well ptrace to do his mischief, right? thanks, -serge --
Mar 25, 6:40 am 2008
Krzysztof Halasa
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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 --
Mar 25, 7:16 am 2008
Krzysztof Halasa
Re: [PATCH] ptrace: it is fun to strace /sbin/init
Hopefully someone will write the details down to enable root to be very careful. -- Krzysztof Halasa --
Mar 25, 7:30 am 2008
Andi Kleen
Re: [PATCH] ptrace: it is fun to strace /sbin/init
The problem is that you can deadlock if you are not very careful. -Andi --
Mar 25, 7:22 am 2008
Pavel Machek
Re: [PATCH] ptrace: it is fun to strace /sbin/init
No problem from me... (..but do not introduce command line option or sysctl. It is not worth it). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/ --
Mar 25, 2:55 pm 2008
Andi Kleen
Re: [PATCH] ptrace: it is fun to strace /sbin/init
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 --
Mar 25, 3:00 am 2008
Stephen Smalley
Re: [PATCH] ptrace: it is fun to strace /sbin/init
Not an issue for SELinux (we apply an orthogonal check based on security context, so we can already block ptrace of init independent of whether root/CAP_SYS_PTRACE can do it). I'm not sure though as to whether people using capabilities have ever relied on this special protection of init (e.g. custom init spawns children with lesser capabilities and relies on the fact that they cannot ptrace init to effectively re-gain those capabilities, even if they possess CAP_SYS_PTRACE). -- Stephen ...
Mar 25, 5:03 am 2008
Peter Zijlstra
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
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 [ ...
Mar 25, 10:19 am 2008
Joe Perches
Re: [PATCH 019/148] include/asm-x86/cpufeature.h: checkp ...
the _CF or the newly line-broken comment? --
Mar 25, 11:27 am 2008
Joe Perches
Re: [PATCH 134/148] include/asm-x86/uaccess_64.h: checkp ...
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. --
Mar 25, 11:29 am 2008
Jörn
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
Disagreement between checkpatch and maintainers preferred style. I've had a patch that fixed a bug and - while in the region - &quot;cleaned up&quot; the style for a single line. This line no longer matches the rest of the file and creates the kind of visual distraction you complain about. In short, for a file with an active maintainer whatever the maintainer prefers should be done. Doing a full checkpatch sweep against a maintainers wishes is madness, doing a partial &quot;cleanup&quot; is worse. Of course ...
Mar 25, 4:11 am 2008
Ingo Molnar Mar 25, 8:30 am 2008
David Miller
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
From: Ingo Molnar &lt;mingo@elte.hu&gt; I can't because I pacified it to cut down the review noise for the patch in question last time it happened. I can tell you one more example of things I strongly disagree with that it does, for example, such as telling me how to document spinlocks in datastructures. It wants a comment right above the spinlock_t member, but this totally ignores that perhaps I put a huge comment explaining the locking semantics elsewhere. It's a black and white tool in a ...
Mar 25, 2:42 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
could you please give me a file name as an example that i could double-check myself? Thanks, Ingo --
Mar 25, 1:44 am 2008
Ingo Molnar
Re: [PATCH 134/148] include/asm-x86/uaccess_64.h: checkp ...
yeah - 64-bit allyesconfig (with DEBUG_INFO disabled - it just slows down the build) should trigger most of the problems. nevertheless i have most of your other patches in x86.git/latest right now, you can pick it up via: that's a nice trick - i never figured out a good way to skip such type of build differences. Ingo --
Mar 25, 1:17 pm 2008
David Miller
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
From: Ingo Molnar &lt;mingo@elte.hu&gt; 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. --
Mar 25, 4:09 pm 2008
David Miller
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
From: Ingo Molnar &lt;mingo@elte.hu&gt; Ingo, this is devolving into a &quot;code I maintain is great, code you maintain sucks, checkpatch says so&quot; kind of discussion, please stop. You're not making any friends by making your arguments this way. --
Mar 25, 4:11 pm 2008
Ingo Molnar
Re: [PATCH 001/148] include/asm-x86/acpi.h: checkpatch c ...
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 --
Mar 25, 1:51 am 2008
Ingo Molnar
Re: [PATCH 0/148] include/asm-x86: checkpatch cleanups - ...
btw., i'd prefer to see more structural cleanups as well. For example, to convert macros that generate code (i.e. just about everything except constants) to inlines. For example in include/asm-x86/processor.h, to convert get_debugreg/set_debugreg or task_pt_regs to inline functions. Ingo --
Mar 25, 2:00 am 2008
Ingo Molnar
Re: [PATCH 134/148] include/asm-x86/uaccess_64.h: checkp ...
hm, you apparently never built this on 64-bit x86? The above has a trivial typo. Ingo --
Mar 25, 8:25 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
you picked an borderline case without showing the full effects of your choice of style - but still even in this example you are wrong i believe. Look at how inconsistent this looks: for (i=0; i&lt;10; i++) { l = 10; if (k &lt;= 10) k = 11; } (the inconsistent 'i=0' versus 'l = 10') so in your style we'd have to write it as: for (i=0; i&lt;10; i++) { l=10; if (k&lt;=10) k=11; } which, on one hand, looks unprofessional (in fixed width font), but on the other hand, ...
Mar 25, 6:38 am 2008
Paolo Ciarrocchi
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
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 &quot;rules&quot; learning from my mistakes and in the end it worked well so i think the problem is in how ...
Mar 25, 11:23 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
Joe should not have spammed lkml like this - but let me take up the general issue of checkpatch that you touch upon - even if the incident actually, my experience has been that 99% of the arch/x86 sparse annotations dont fix any &quot;real&quot; issue but remove a warning. The remaining 1% still very much makes it worth though (they can prevent a security hole, a bad bug, endianness incompatibility, etc.), so we've taken a large amount of sparse annotations in arch/x86 in the past few months - ...
Mar 25, 3:48 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
well, once a subsystem is &quot;checkpatch-clean&quot; (which my challenge above obviously assumes), there's no such &quot;partial style&quot; 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 ...
Mar 25, 5:24 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
firstly, this warning from checkpatch.pl is off by default. There are 3 checkpatch warning categories: ERROR, WARNING, CHECK. spinlock_t without a warning is in this third category and you wont even see that warning unless you very explicitly do: checkpatch.pl --subjective Secondly, even about this &quot;checkpatch.pl --subjective&quot; check you are wrong. As someone who had to decode (way!) too many lockdep backtraces in various kernel code that i didnt author and didnt maintain, i can ...
Mar 25, 6:05 am 2008
Jörn
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
I disagree with that assertion. My favorite example of where CodingStyle has gone too far is this: for (i=0; i&lt;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 ...
Mar 25, 6:12 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
and let me give an example with the your very own code that you wrote and maintain, drivers/mtd/devices/block2mtd.c: errors lines of code errors/KLOC drivers/mtd/devices/block2mtd.c 10 490 20.4 that's pretty OK code, but not perfect, the 10 errors are: ERROR: do not use C99 // comments ERROR: need spaces around that '=' (ctx:VxV) ERROR: need spaces around that '&lt;' (ctx:VxV) ERROR: do not use C99 // comments ...
Mar 25, 6:45 am 2008
Jörn
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
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. &lt;adds Andy to Cc:&gt; (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) &lt; super-&gt;s_segsize; ) { Actual code is this: for (seg_ofs = ...
Mar 25, 9:07 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
we dont actually do that for newbies and newbies are in fact happy to write cleaner code - so the rest of your argument which depends on this premise fails. (Most of the time i fix it up silently myself or if a style error comes in a pattern, i ask the person to send future patches with that small detail fixed.) my experience with checkpatch.pl is the exact opposite of what you fear: it _widened_ the contributor base: a good number of newbies felt encouraged that an objective piece of ...
Mar 25, 7:03 am 2008
Andi Kleen
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
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 --
Mar 25, 10:28 am 2008
Ingo Molnar
Re: [PATCH 019/148] include/asm-x86/cpufeature.h: checkp ...
both :) Line-breaking in macros isnt done like that. And the _CF thing: +#if defined _CF +#undef _CF +#endif +#define _CF(word, bit) ((word) * 32 + (bit)) looks quite ugly - either we have such a macro in which case it should be a generic define somewhere that doesnt override anything else, or we shouldnt do it. I also had to fix some other typos that broke the 64-bit build. I ended up skipping the whole cpufeatures.h patch - could you please re-do and re-send ...
Mar 25, 1:15 pm 2008
Andi Kleen
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
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 ...
Mar 25, 5:26 am 2008
Ingo Molnar
Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch ...
ok, so i'll have to come up with some hard data about code you maintain i guess - please provide contrary data if you have it. Using the &quot;code-quality&quot; script mentioned at: http://people.redhat.com/mingo/x86.git/README on the Sparc64 tree: $ code-quality `find arch/sparc64/ include/asm-sparc64/ -name '*.c'` | tee ~/quality-sparc.txt $ sort -n -k 4 ~/quality-sparc.txt | tail -20 shows the following &quot;20 worst files&quot;: errors ...
Mar 25, 6:17 am 2008
Kai
Re: Serious performance regression in Wine applications ...
On Sat, 22 Mar 2008 21:47:52 -0700, &quot;Ray Lee&quot; &lt;ray-lk@madrabbit.org&gt; 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. --
Mar 25, 5:12 am 2008
Ray Lee
Re: Serious performance regression in Wine applications ...
Andi's idea of looking for excessive context switches is good -- I didn't see a response to that one. Other than that, if you're only noticing the issue in 3d games, then it could be several things (not just the scheduler). Even just a few bisects (or testings of nightly snapshots) would help narrow it down. Ray --
Mar 25, 8:49 am 2008
Sergei Shtylyov
Re: [PATCH 3/8] ide: remove IDE_HFLAG_NO_AUTOTUNE host flag
Acked-by: Sergei Shtylyov &lt;sshtylyov@ru.mvista.com&gt; MBR, Sergei --
Mar 25, 9:49 am 2008
Ingo Molnar
Re: [patch 0/4] x86 - relocate_kernel cleanup
as long as your work against x86.git/latest you shouldnt be worried about any clashes. Ingo --
Mar 25, 8:57 am 2008
Cyrill Gorcunov
Re: [patch 0/4] x86 - relocate_kernel cleanup
[Ingo Molnar - Tue, Mar 25, 2008 at 04:57:00PM +0100] | | * Cyrill Gorcunov &lt;gorcunov@gmail.com&gt; wrote: | | &gt; You know, Peter, I'm a bit scared that these flags are in number of | &gt; 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 - --
Mar 25, 10:34 am 2008
Ingo Molnar
Re: [patch 0/4] x86 - relocate_kernel cleanup
thanks Cyrill, i've applied all four patches of yours. Ingo --
Mar 25, 8:59 am 2008
Ingo Molnar Mar 25, 8:49 am 2008
Jan Kara
Re: ext3 lockdep warning in 2.6.25-rc6
Actually, I have a fix for that - attached. Can you try it? Thanks. -- Jan Kara &lt;jack@suse.cz&gt; SuSE CR Labs
Mar 25, 11:29 am 2008
Jeff Garzik Mar 24, 8:53 pm 2008
Tejun Heo
Re: [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotpl ...
Okay, updated. Please pull from http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=shortlog;h=cleanup-sht-ops git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata-dev.git cleanup-sht-ops It's now on top of the current #upstream-fixes (4cde32fc) and contains the followings. * prefer-hardreset patchset * PCI-device-should-be-powered-up-before-being-accssed patch * cleanup-sht-ops patchset Thanks. -- tejun --
Mar 24, 8:32 pm 2008
Tejun Heo
Re: [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotpl ...
Heh... me refreshing the patchset again. Doing it right now. -- tejun --
Mar 24, 7:37 pm 2008
Jeff Garzik Mar 24, 7:31 pm 2008
Jeff Garzik
Re: [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotpl ...
I just merged it into #upstream-fixes (answering your question)... what is your preferred method of sync'ing at this point? Jeff --
Mar 24, 7:32 pm 2008
Jens Axboe Mar 25, 12:04 pm 2008
Thomas Meyer
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
All i get is: [ 1175.600768] ACPI: PCI Interrupt 0000:0c:03.0[A] -&gt; GSI 19 (level, low) -&gt; IRQ 19 no ioremap debug offset. --
Mar 25, 2:02 pm 2008
Ingo Molnar
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
that's weird. If you do the modprobe from a VGA console and do a 'dmesg -n 8', do you get any ioremap printk shortly before the hard lockup? Ingo --
Mar 25, 1:11 pm 2008
Stefan Richter
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
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/ --
Mar 25, 10:06 am 2008
Ingo Molnar
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
basically, old ioremap did this: [ 162.485605] ACPI: PCI Interrupt 0000:0c:03.0[A] -&gt; GSI 19 (level, low) -&gt; IRQ 19 [ 162.485695] ioremap: 00000000(00000800) =&gt; f8978000 the theory (fact?) was that the zero physical address there (the '00000000') was some 4GB+ address truncated down to 32-bits. OTOH, before this system worked for you before, i start to suspect that ioremap is a red herring here and that it's the code that gets to that physical address (which is ioremap-ed) is at ...
Mar 25, 1:29 pm 2008
Thomas Meyer
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
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 &gt;TAbort- &lt;TAbort- &lt;MAbort- &gt;SERR- &lt;PERR- INTx- ...
Mar 25, 3:02 pm 2008
Linus Torvalds
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
Ok, so it didn't use to be at the 4GB mark. This seems to be a PCI and resource alloc issue. It would be really interesting to see where the 4GB allocation started. Ie ignore anything else (warnings, driver loadings etc), and _just_ look at lspci -vv output for where the memory got allocated. Did you already bisect that and I just missed it? Linus --
Mar 25, 2:47 pm 2008
Ingo Molnar
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
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 +++ ...
Mar 25, 12:31 am 2008
Benjamin Herrenschmidt
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
On other platforms however, you can have mmio above 32 bits without support for 64 bits BARs: the entire PCI bus mmio region can be mapped up there. That happens for example with 4xx embedded PowerPC. We deal with it just fine, provided that nothing tries to stick a resource value into an unsigned long but uses resource_size_t instead. Unfortunately, it's a common bug, I've fixing drivers regulary. It also appears that the iomap code on various archs is buggy too, including the generic ...
Mar 25, 4:33 pm 2008
Ingo Molnar
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
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 --
Mar 25, 9:50 am 2008
Thomas Meyer
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
See file attachments of this bug: http://bugzilla.kernel.org/show_bug.cgi?id=10080 and compare lspci -vv from 2.6.25 and 2.6.24: 2.6.25: 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 &gt;TAbort- &lt;TAbort- &lt;MAbort- &gt;SERR- &lt;PERR- INTx- Latency: 248 (3000ns ...
Mar 25, 2:08 pm 2008
Thomas Meyer
Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: ...
The kernel boots, but hangs at &quot;populating dev tree with devices usings uevents&quot;. 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
Mar 25, 11:32 am 2008
Thomas Gleixner Mar 25, 1:19 am 2008
Jeff Garzik
Re: [SCSI] fix media change events for polled devices
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 --
Mar 24, 8:09 pm 2008
James Bottomley
Re: [SCSI] fix media change events for polled devices
Well, it's open source ... this interface has had a better passage than I think the current hack is the simplest way to fix up 2.6.25, given the lateness in the -rc cycle ... we can do a far better job in 2.6.26 and still be backwards compatible with the 2.6.25 hack. In fact, I committed to Kay that we would ... although if you want to do it instead, that would be easier for me. Thanks, James --
Mar 24, 8:18 pm 2008
Paul E. McKenney
Re: [PATCH,RFC] Initialize call_rcu_sched sooner
This passes smoke tests, so have incorporated it. Thank you, Mathieu!!! --
Mar 25, 11:49 am 2008
Mathieu Desnoyers
Re: [PATCH,RFC] Initialize call_rcu_sched sooner
Initialize call_rcu_sched sooner so it can be used in module_init stage. (needed for LTTng) Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@polymtl.ca&gt; --- init/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-lttng/init/main.c =================================================================== --- linux-2.6-lttng.orig/init/main.c 2008-03-25 08:49:02.000000000 -0400 +++ linux-2.6-lttng/init/main.c 2008-03-25 08:49:20.000000000 -0400 @@ -738,13 +738,13 ...
Mar 25, 5:53 am 2008
Andreas Herrmann
Re: [PATCH] - Increase max physical memory size of x86_64
Shouldn't this be increased to 48? AMD family 10h CPUs actually support 48 bits for the physical address. Regards, Andreas --
Mar 25, 9:41 am 2008
Chris Snook
Re: [PATCH] - Increase max physical memory size of x86_64
The only advantage 44 bits has over 48 bits is that it allows us to uniquely identify 4k physical pages with 32 bits, potentially allowing for tighter packing of certain structures. Do we have any code that does this, and if so, is it a worthwhile optimization? Personally, I think we should support the full capability of the hardware, but I don't have a 17 TB Opteron box to test with. -- Chris --
Mar 25, 2:02 pm 2008
Jack Steiner
Re: [PATCH] - Increase max physical memory size of x86_64
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 --
Mar 25, 9:54 am 2008
Peter Zijlstra
Re: Scalability requirements for sysv ipc
Ouch, I guess hrtimers are just way expensive on some hardware... --
Mar 25, 9:13 am 2008
Nadia Derbey
Re: Scalability requirements for sysv ipc
Hi, Here is what I could find on my side: ============================================================= lkernel@akt$ cat tst3/res_new/output [root@akt tests]# echo 32768 &gt; /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 ...
Mar 25, 9:00 am 2008
Mike Galbraith
Re: Scalability requirements for sysv ipc
After manually reverting 3e148c79938aa39035669c1cfa3ff60722134535, 2.6.25.git scaled linearly, but as you noted, markedly down from earlier kernels with this benchmark. 2.6.24.4 with same revert, but all 2.6.25.git ipc changes piled on top still performed close to 2.6.22, so I went looking. Bisection led me to.. 8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f Author: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt; Date: Fri Jan 25 ...
Mar 25, 8:50 am 2008
Mike Galbraith
Re: Scalability requirements for sysv ipc
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 --
Mar 25, 11:31 am 2008
Ingo Molnar
Re: [PATCH] x86_64: early memtest to find bad ram
not that i know of - feel free. Ingo --
Mar 25, 4:00 am 2008
Andi Kleen Mar 25, 12:52 am 2008
Andi Kleen
Re: [13/14] vcompound: Use vcompound for swap_map
Not when the trick of getting high order, returning left over pages is used. I meant just updating the GFP_COMPOUND code to always use number of pages instead of order so that it could deal with a compound where the excess pages are already returned. That is not actually that much work (I reimplemented this recently for dma alloc and it's &lt; 20 LOC) Of course the full rewrite would be also great, agreed :) -Andi --
Mar 25, 10:55 am 2008
Christoph Lameter
Re: [13/14] vcompound: Use vcompound for swap_map
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. --
Mar 25, 10:45 am 2008
Christoph Lameter Mar 25, 10:51 am 2008
David Miller
Re: larger default page sizes...
From: Paul Mackerras &lt;paulus@samba.org&gt; 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. --
Mar 25, 4:32 pm 2008
Andi Kleen
Re: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
Hard to test all cases. Static checking would be better. Or just not do it? I didn't think order 1 failures were that big a problem. -Andi --
Mar 25, 11:07 am 2008
David Miller
Re: larger default page sizes...
From: Paul Mackerras &lt;paulus@samba.org&gt; Please read the rest of my responses in this thread, you can have your HPC cake and eat it too. --
Mar 24, 9:15 pm 2008
Christoph Lameter
Re: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
We could add debugging code to virt_to_page (or __pa) to catch these uses. --
Mar 25, 10:55 am 2008
Christoph Lameter
RE: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
Interesting.... Never realized we were doing these tricks with DTR. --
Mar 25, 12:25 pm 2008
Andi Kleen
Re: larger default page sizes...
Do you have some idea where the improvement mainly comes from? Is it TLB misses or reduced in kernel overhead? Ok I assume both play together but which part of the equation is more important? -Andi --
Mar 25, 5:05 am 2008
Paul Mackerras
Re: larger default page sizes...
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 ...
Mar 25, 2:27 pm 2008
Paul Mackerras
Re: larger default page sizes...
It's not just HPC, as I pointed out, it's pretty much everything, including kernel compiles. And &quot;use hugepages&quot; is a pretty inadequate answer given the restrictions of hugepages and the difficulty of using them. How do I get gcc to use hugepages, for instance? Using 64k pages gives us a performance boost for almost everything without the user having to do anything. If the hugepage stuff was in a state where it enabled large pages to be used for mapping an existing program, where possible, ...
Mar 25, 4:50 am 2008
Peter Chubb
Re: larger default page sizes...
&gt;&gt;&gt;&gt;&gt; &quot;David&quot; == David Miller &lt;davem@davemloft.net&gt; writes: David&gt; From: Christoph Lameter &lt;clameter@sgi.com&gt; Date: Tue, 25 Mar David&gt; Transparent automatic hugepages are definitely doable, I don't David&gt; 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 ...
Mar 25, 4:41 pm 2008
David Miller
Re: larger default page sizes...
From: Christoph Lameter &lt;clameter@sgi.com&gt; Transparent automatic hugepages are definitely doable, I don't know why you think this requires application changes. People want these larger pages for HPC apps. --
Mar 25, 4:22 pm 2008
David Miller
Re: larger default page sizes...
From: Peter Chubb &lt;peterc@gelato.unsw.edu.au&gt; 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. --
Mar 25, 4:49 pm 2008
Christoph Lameter
Re: larger default page sizes...
No its not fixable. You are doing linear optimizations to a slowdown that grows exponentially. Going just one order up for page size reduces the These hacks have limitations. F.e. they do not deal with I/O and require application changes. --
Mar 25, 10:48 am 2008
Dave Hansen
Re: larger default page sizes...
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 --
Mar 25, 11:27 am 2008
Luck, Tony
RE: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
Pinning TLB entries on ia64 is done using TR registers with the &quot;itr&quot; instruction. Currently we have the following pinned mappings: itr[0] : maps kernel code. 64MB page at virtual 0xA000000100000000 dtr[1] : maps kernel data. 64MB page at virtual 0xA000000100000000 itr[1] : maps PAL code as required by architecture dtr[1] : maps an area of region 7 that spans kernel stack page size is kernel granule size (default 16M). This mapping needs to be reset on a context ...
Mar 25, 12:09 pm 2008
Andi Kleen
Re: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
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 --
Mar 25, 12:51 am 2008
Christoph Lameter
RE: [11/14] vcompound: Fallbacks for order 1 stack alloc ...
I thought the only pinned TLB entry was for the per cpu area? How does it pin the TLB? The expectation is that a single TLB covers the complete stack area? Is that a feature of fault handling? --
Mar 25, 10:42 am 2008
Luck, Tony
RE: larger default page sizes...
&quot;large&quot; pages, or &quot;super&quot; pages perhaps ... but Linux &quot;huge&quot; 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 ...
Mar 25, 4:49 pm 2008
Paul Mackerras
Re: larger default page sizes...
The performance advantage of using hardware 64k pages is pretty I just tried a kernel compile on a 4.2GHz POWER6 partition with 4 threads (2 cores) and 2GB of RAM, with two kernels. One was configured with 4kB pages and the other with 64kB kernels but they were otherwise identically configured. Here are the times for the same kernel compile (total time across all threads, for a fairly full-featured config): 4kB pages: 444.051s user + 34.406s system time 64kB pages: 419.963s user + ...
Mar 24, 8:29 pm 2008
Oliver Neukum
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
A device that cannot wake up is unusable. Shouldn't the pm core disconnect() such a device? Regards Oliver --
Mar 25, 2:49 am 2008
Rafael J. Wysocki
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
Well, if -&gt;resume() returns an error, the driver already knows there's a problem and it can act upon that, at least in principle. However, the PM core probably shouldn't try to resume the children of a failing device. Also, if -&gt;resume_noirq() fails, it probably is not a good idea to call -&gt;resume() and -&gt;complete() for the same device and for it's children. Thanks, Rafael --
Mar 25, 6:06 am 2008
Oliver Neukum
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
IMO you must always keep the ordering invariant. If a parent returns an error the PM core must not wake its children. Regards Oliver --
Mar 25, 1:49 pm 2008
Oliver Neukum
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
Yes, that makes sense. You are right. Regards Oliver --
Mar 25, 12:48 pm 2008
Oliver Neukum
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
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 --
Mar 25, 6:15 am 2008
Alan Stern
Re: [linux-pm]
It's not safe for the PM core to do such things unilaterally. The decision to unregister a device should be made by the driver or the subsystem. (The only problem is that it's impossible to unregister a device from within its suspend or resume methods. Perhaps there should be a way for the driver to tell the PM core that the core should unregister the device as soon as the method returns. I don't know if such a facility The PM core prints a warning in the system log whenever an ...
Mar 25, 7:19 am 2008
Oliver Neukum
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
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 --
Mar 25, 7:24 am 2008
Alan Stern
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
But these disconnects aren't done by the PM core; they are done by I'll go along with that. If a device vanishes during sleep, the PM core isn't responsible for unregistering it -- the device's subsystem is. Alan Stern --
Mar 25, 7:33 am 2008
Rafael J. Wysocki
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
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 -&gt;complete() for that devices and their children. Thanks, Rafael --
Mar 25, 1:56 pm 2008
Rafael J. Wysocki
Re: [linux-pm] [RFC][PATCH] PM: Introduce new top level
Still, if -&gt;resume() returns an error, does it make sense, from the PM core's point of view, to execute -&gt;complete() for that device, for example? If you think it does, that behavior should be clearly documented (I didn't think about that before). Thanks, Rafael --
Mar 25, 1:41 pm 2008
Avi Kivity
Re: 2.6.25-rc5-git5 KVM memory not freed
Yes, of course. -- Any sufficiently difficult bug is indistinguishable from a feature. --
Mar 24, 11:21 pm 2008
Ian Abbott
Re: [PATCH] Corrections to Documentation/rbtree.txt
I don't know the rationale, but all the code I can see uses rb_entry() and not container_of(). The only rationale I can think of is that it abstracts away from the nodes being embedded in the data a little bit. (But not by much - in particular, an implementation of rb trees that stored data in the node explicitly would only need a single parameter in its rb_entry() accessor. I like the approach taken in include/linux/elevator.h that uses the rb_entry() macro to create a specialized ...
Mar 25, 4:02 am 2008
Rob Landley
Re: [PATCH] Corrections to Documentation/rbtree.txt
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 ...
Mar 25, 11:24 am 2008
Ian Abbott
Re: [PATCH] Corrections to Documentation/rbtree.txt
I forgot to mention this in my earlier post, but while we're on the subject, it might be worth renaming the 'node' variable in the 'my_search()' and iteration examples to avoid confusion in the use of the rb_entry() (or container_of() macro), for example in 'my_search()', instead of: struct rb_node *node = root-&gt;rb_node; while (node) { struct mytype *data = rb_entry(node, struct mytype, node); I think this is clearer: struct rb_node *pn = root-&gt;rb_node; while (pn) { struct ...
Mar 25, 4:29 am 2008
Johannes Berg
[PATCH/RFC v5] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS ...
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 &lt;johannes@sipsolutions.net&gt; Acked-by: Sam Ravnborg ...
Mar 25, 7:11 am 2008
Nick Piggin
Re: [PATCH] Fix data leak in nobh_write_end.
Thanks for finding this. I guess it was a thinko as to the semantics of PageMappedToDisk on my behalf... Reviewed-by: Nick Piggin &lt;npiggin@suse.de&gt; --
Mar 25, 2:22 am 2008
Dong, Eddie
RE: Xen common code across architecture
Fix a typo. Merged one is attached too. Signed-off-by: Yaozu (Eddie) Dong &lt;eddie.dong@intel.com&gt; --- 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 &lt;xen/interface/xen.h&gt; #include &lt;xen/interface/event_channel.h&gt; =20 -#include &quot;xen-ops.h&quot; +#include &lt;xen/xen-ops.h&gt; =20 /* * This lock protects updates to the following mapping and reference-count
Mar 24, 11:35 pm 2008
Dong, Eddie
RE: Xen common code across architecture
Jeremy/Andrew: Isaku Yamahata, I and some other IA64/Xen community memebers are working together to enable pv_ops for IA64 Linux. This patch is a preparation to=20 move common arch/x86/xen/events.c to drivers/xen (contents are identical) against mm tree, it is based on Yamahata's IA64/pv_ops patch serie. In case you want to have a brief view of whole pv_ops/IA64 patch serie,=20 please refer to IA64 Linux mailinglist. Thanks, Eddie =09 Move events.c to drivers/xen for IA64/Xen ...
Mar 24, 11:13 pm 2008
Jeremy Fitzhardinge
Re: Xen common code across architecture
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 &lt;linux/percpu.h&gt; rather than assuming it has already been included. J --
Mar 25, 8:08 am 2008
Ingo Molnar Mar 25, 8:50 am 2008
Tino Keitel
Re: 2.6.25-rc6 hangs at resume after suspend to RAM on M ...
I tried HEAD from yesterday, but resume still fails. So it looks like I need to start a git bisect. Regards, Tino --
Mar 25, 4:13 pm 2008
Greg KH
Re: linux-next: Tree for March 20
I'll be sending this to Linus after -rc1 comes out, so it's fine that it Glad to hear it. greg k-h --
Mar 25, 12:31 am 2008
Stephen Rothwell
Re: linux-next: Tree for March 20
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/
Mar 24, 11:48 pm 2008
Jan Kara
Re: BUG: at fs/inotify.c:182 set_dentry_child_flags() - second
Here, the check itself has been racy (and producing bogus warnings) and is already removed in current Linus's tree. Thanks for report. Honza -- Jan Kara &lt;jack@suse.cz&gt; SuSE CR Labs --
Mar 25, 11:20 am 2008
Andrew Morton
Re: [PATCH 2/2 v2] Add DIU platform code for MPC8610HPCD
On Tue, 25 Mar 2008 12:43:22 +0000 I guess so. It's quite unusual. --
Mar 25, 12:18 pm 2008
Andy Whitcroft
Re: [PATCH 2/2 v2] Add DIU platform code for MPC8610HPCD
This seems like it might be detectable, does this seem like something we should try an report? WARNING: arguments for function declarations should follow identifier #7: FILE: Z110.c:7: Yeah, we did only look for explicitly extern'd declarations. But this form seems detectable, will be in v0.17. WARNING: externs should be avoided in .c files #2: FILE: Z110.c:2: +int __init preallocate_diu_videomemory(void); -apw --
Mar 25, 5:43 am 2008
David Chinner
Re: xfs+md(raid5) xfssyncd & kswapd & pdflush hung in d-state
Added linux-raid to cc - this is not an XFS problem Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --
Mar 24, 8:29 pm 2008
Pavel Machek
Re: APM crashes when IO is going on
Kernel should recover from lost interrupt. Can you track down this regression? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Mar 25, 1:46 am 2008
Pavel Machek
Re: APM crashes when IO is going on
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 --
Mar 25, 1:49 am 2008
Alex Chiang Mar 24, 8:31 pm 2008
Alex Chiang Mar 24, 8:31 pm 2008
Alex Chiang Mar 24, 8:31 pm 2008
Alex Chiang Mar 24, 8:31 pm 2008
Alex Chiang
Re: [PATCH 11/16] PCI slot: Remove useless release handl ...
Thanks, this was a good change. I've tested and merged it. This prevents multiple hotplug drivers from claiming the same slot. + if (pci_slot-&gt;hotplug) { + dbg(&quot;%s: already claimed\n&quot;, __func__); + pci_destroy_slot(pci_slot); + slot-&gt;hotplug = NULL; The above is needed if pci_slot is loaded, and you wish to repeatedly load/unload acpiphp/pciehp/other hp drivers. Thanks, --
Mar 24, 8:08 pm 2008
Alex Chiang Mar 24, 8:31 pm 2008
Thomas Klein
Re: [PATCH] ehea: Fix IPv6 support
Agreed. I'll send a patch. Thomas --
Mar 25, 8:41 am 2008
Nick Piggin
Re: [PATCH 0/5] Generic smp_call_function(), improvement ...
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 ...
Mar 25, 1:00 am 2008
Andi Kleen
Re: [PATCH 45/79] [PATCH] fix apic acking of irqs
iirc a lot of the ESR weirdness was on NUMAQ only, which is down to one of two last machines running Linux which will hopefully die soon ... -Andi --
Mar 25, 5:40 am 2008
Glauber Costa
Re: [PATCH 45/79] [PATCH] fix apic acking of irqs
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 ...
Mar 25, 6:42 am 2008
Glauber Costa
Re: [PATCH 45/79] [PATCH] fix apic acking of irqs
I just tested in some real i386 that I have around here, and the reading of EOI does not seem to be illegal. (Well, at least in those I've tested). OTOH, ignoring the read in qemu makes the tree boot just okay. So I agree with you now, we might well fix qemu, and revert this patch. --
Mar 25, 3:39 pm 2008
Maciej W. Rozycki
Re: [PATCH 45/79] [PATCH] fix apic acking of irqs
... 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 ...
Mar 25, 8:48 am 2008
Laurent Vivier
[PATCH] Modify Network Block Device (nbd) to be able to ...
This patch allows to use partitions with network block devices (NBD). A new parameter is introduced to define how many partition we want to be able to manage per network block device. This parameter is &quot;max_part&quot;. For instance, to manage 63 partitions / loop device, we will do: [on the server side] # nbd-server 1234 /dev/sdb [on the client side] # modprobe nbd max_part=63 # ls -l /dev/nbd* brw-rw---- 1 root disk 43, 0 2008-03-25 11:14 /dev/nbd0 brw-rw---- 1 root disk 43, 64 ...
Mar 25, 3:34 am 2008
Russell King
Re: tick-common.c hack for s390 needed
Okay. Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt; -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
Mar 25, 12:30 pm 2008
Thomas Gleixner
Re: tick-common.c hack for s390 needed
That patch makes a lot of sense and resolves all the issues. I push it through hrt.git and add the GENERIC_HARDIRQS dependency which was requested by Heiko. Thanks, --
Mar 25, 12:09 pm 2008
Andi Kleen
Re: [PATCH prototype] [0/8] Predictive bitmaps for ELF e ...
There is still the additional seek. Large xattrs tend to be out of line from the inode. -Andi --
Mar 25, 12:54 am 2008
John W. Linville
Re: [PATCH] net/mac80211/: Use time_* macros
These two patches are already queues for 2.6.26. John -- John W. Linville linville@tuxdriver.com --
Mar 25, 11:32 am 2008
Thomas Gleixner
Re: 2.6.25-rc5-git6: Reported regressions from 2.6.24
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 =================================================================== --- ...
Mar 25, 1:06 am 2008
Jean Delvare
Re: use of preempt_count instead of in_atomic() at leds-gpio.c
Andrew explained that in_atomic() could deadlock if called in a condition where it is unreliable (although I did not understand the details). Documenting that a &quot;yes&quot; from in_atomic() can always be trusted, would invite driver authors to still use it, when my understanding is that they still shouldn't. If drivers shouldn't use in_atomic() at all then I think that the long-term solution is to move its definition out of &lt;linux/hardirq.h&gt;. But of course this means fixing all the drivers that ...
Mar 25, 3:39 am 2008
Junio C Hamano
Re: use of preempt_count instead of in_atomic() at leds-gpio.c
Is it just me who feels this comment that says &quot;in_atomic() is not a way to tell if we are in atomic reliably and cannot be used for such and such&quot; 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 &quot;even if this says no, you could still be in atomic, ...
Mar 25, 1:52 am 2008
David Brownell
Re: use of preempt_count instead of in_atomic() at leds-gpio.c
I _almost_ hate bringing this lovely flamage back onto $SUBJECT ... but what's the resolution for the leds-gpio.c issue? I've not seen a merge notice for the patch I submitted a week ago now: http://marc.info/?l=linux-kernel&amp;m=120597839009399&amp;w=2 Just a &quot;leaning...&quot; comment: http://marc.info/?l=linux-kernel&amp;m=120606104619198&amp;w=2 Seems to me that by now there ought to be resolution on at least one of the issues brought up on this thread. :) - Dave --
Mar 25, 4:20 pm 2008
Jonathan Corbet
Re: use of preempt_count instead of in_atomic() at leds- ...
The &quot;right situation&quot; would appear to be &quot;you're deep in the mm code and really know what you're doing.&quot; 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 &quot;you just *might* be in atomic context, where sleeping would be a bad idea, but I can't tell you&quot; really isn't all that useful. It's a trap which can only lead to incorrect ...
Mar 25, 6:44 am 2008
Felipe Balbi
Re: [PATCH 01/18] MMC: OMAP: Remove some opcodes from ho ...
On Fri, Mar 14, 2008 at 9:36 PM, Carlos Aguiar You should update this patch and remove the '#include -- Best Regards, Felipe Balbi felipebalbi@users.sourceforge.net --
Mar 25, 2:58 am 2008
Randy Dunlap
[PATCH v2] x86: don't allow KVM_CLOCK on Voyager or Visual WS
From: Randy Dunlap &lt;randy.dunlap@oracle.com&gt; 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 ...
Mar 25, 4:08 pm 2008
Justin Madru
Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
Well, the upgrade went ok, and compiling the reg_dumper using the libpciaccess .deb from Bryce worked. Then I tried to add to the boot scripts a call to reg_dumper... ...To make a long story short... I somehow killed my boot scripts! Anyways, I did a fresh reinstall of Ubuntu 8.4 Beta. I'm still getting the blank screen problem with the 2.6.25-rc6 kernel, so I guess it wasn't a Ubuntu software problem (or I hope not, because that could be really hard to find). What I did was created a script ...
Mar 24, 8:07 pm 2008
Jesse Barnes
Re: [Regression: 2.6.25-rc5: Blank Screen: Intel 945]
Wow, that's a lot of dump files. :) I was worried that in the &quot;blank&quot; 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: ...
Mar 25, 1:08 pm 2008
Jeff Garzik
Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
In your original email you said I guess it should go into 2.6.25, not sure about &quot;stable&quot; series. I will appreciate any feedback, review and/or test results. At the time of the posting 2.6.25-rc6 had already been released, which seems like an inappropriate time for all that new code, which has been given so little exposure to real world testing. Certainly your original message said PPP panics, but without even minimal testing how do we know that your new code doesn't have equally ...
Mar 25, 7:55 am 2008
David Miller
Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
From: Krzysztof Halasa &lt;khc@pm.waw.pl&gt; 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. --
Mar 25, 4:14 pm 2008
Krzysztof Halasa
Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
Well, there was something like &quot;minimal testing&quot;, and it doesn't panic 100% like the old code does. But the probability that it won't work correctly is quite high. IOW: the new version is certainly better than the old one, though it's Actually Frame Relay and other protocols are not affected, the PPP patch doesn't change them a bit, it's a different module. The new code only affect PPP protocol. I'm fine with the Kconfig patch, actually I'm not sure what is better at this time - a ...
Mar 25, 8:50 am 2008
Krzysztof Halasa
Re: [PATCH v2] Re: WAN: new PPP code for generic HDLC
Hi, So are we leaving the generic-HDLC+PPP in broken state for 2.6.25, aren't we? If we do, perhaps a &quot;|| BROKEN&quot; 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 --
Mar 25, 7:39 am 2008
Thomas Gleixner
Re: [PATCH] CPA: Add statistics about state of direct ma ...
Also I asked to move the update function to pageattr.c where we have the variable, so we dont need to make it global and can change the update via function call with pages = 0 ? Thanks, tglx --
Mar 25, 8:40 am 2008
Thomas Gleixner
Re: [PATCH] CPA: Add statistics about state of direct ma ...
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 --
Mar 25, 9:16 am 2008
Joerg Roedel
Re: [PATCH] [6/7] Split large page mapping for AMD TSEG
-- | AMD Saxony Limited Liability Company &amp; 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 McCoy --
Mar 25, 4:56 am 2008
Joerg Roedel
Re: [PATCH] [4/7] Don't use large pages to map the first ...
This should especially boost performance on 32 bit. Have you numbers for -- | AMD Saxony Limited Liability Company &amp; 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 ...
Mar 25, 4:31 am 2008
Andi Kleen
Re: [PATCH] CPA: Add statistics about state of direct ma ...
Didn't get that one. Can you clarify? -Andi --
Mar 25, 9:14 am 2008
Thomas Gleixner
Re: [PATCH] [6/7] Split large page mapping for AMD TSEG
warning: passing argument 2 of 'rdmsrl_safe' from incompatible pointer type Thanks, tglx --
Mar 25, 9:44 am 2008
Andi Kleen Mar 25, 4:39 am 2008
Andi Kleen
Re: [PATCH] [6/7] Split large page mapping for AMD TSEG
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 --
Mar 25, 9:54 am 2008
Andi Kleen
Re: [PATCH] CPA: Add statistics about state of direct ma ...
All comments addressed now hopefully. -Andi --- CPA: Add statistics about state of direct mapping v4 Add information about the mapping state of the direct mapping to /proc/meminfo. I chose /proc/meminfo because that is where all the other memory statistics are too and it is a generally useful metric even outside debugging situations. A lot of split kernel pages means the kernel will run slower. This way we can see how many large pages are really used for it and how many are ...
Mar 25, 10:01 am 2008
Andres Salomon
[PATCH] gxfb: two suspend/resume fixes
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 ...
Mar 25, 8:30 am 2008
Helge Hafting
Re: 2.6.25-rc5-mm1 shutdown crash
Andrew Morton wrote: The problem seems to be solved in 2.6.25-rc6. Helge Hafting --
Mar 25, 5:23 am 2008
Sebastian Siewior
Re: [PATCH -mm crypto] AES: remove crypto_fl_tab and rep ...
According to the tcrypt numbers you've posted it is getting &quot;slightly&quot; slower on encryption/decryption of 64+ bytes. How did you measure your &quot;almost no performance penalty&quot;? Sebastian --
Mar 25, 4:33 pm 2008
Chr
Re: inotify fixes in stable
Done...! I took both patches from the current git-tree. hmm, Nick said that the debug code is racy and &quot;not very good at finding problems&quot; either... But as long as the real fix has a _real_ change to get Regards, Christian --
Mar 25, 6:15 am 2008
Chris Wright
Re: inotify fixes in stable
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 ...
Mar 24, 5:42 pm 2008
Rene Herman
Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx brok ...
Thanks much for the quick reply. That's good to hear. As indicated, Bob seemed to be experiencing something else but this is pretty fundamental so I'll not try to comment on his case any further until he's had a chance to test this as well. Takashi -- over to you for Michael's issue? His PWS600AU (MIATA) system soils itself badly when using SNDRV_PCM_INFO_MMAP. His XP1000 works fine and I haven't the faintest clue if switching on CONFIG_ALPHA_MIATA is the proper switch, nor if outright ...
Mar 24, 5:29 pm 2008
Rene Herman
Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx brok ...
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.
Mar 24, 7:46 pm 2008
Rene Herman
Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx brok ...
Lovely, so different problem between you and Bob. When you (either of you) have some time for it again, could you try: $ sox asskickd.wav -w -t alsa hw $ sox asskickd.wav -w -r 44100 -t alsa hw $ sox asskickd.wav -w -r 44100 -c 2 -t alsa hw and report if things start working? First transforms into 16-bit, second Not a clue. Takashi -- is it possible that Bob wasn't using mmap to being with if he didn't do anything specific to not do so? And perhaps you guys have firmware settable ...
Mar 24, 7:22 pm 2008
Michael Cree
Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx brok ...
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 &quot;pal&quot; repeated at the end. When I play it with sox (also through the es1887) I get the words &quot;current event&quot; repeated at the end. Playing through the CM8738 also repeats the words &quot;current event&quot; 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 ...
Mar 24, 6:22 pm 2008
Rodolfo Giometti
Re: [PATCH 5/7] PPS: serial clients support.
Fixed. I'll send a new patch ASAP. 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 --
Mar 25, 3:38 am 2008
Rodolfo Giometti
Re: [PATCH 1/7] LinuxPPS core support.
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 --
Mar 25, 3:48 am 2008
Rodolfo Giometti
Re: [PATCH 1/7] LinuxPPS core support.
I can add a wait_event_interruptible in order to allow userland to I don't understand the problem... this code as been added in order to avoid the case where a pps_event() is called while a process executes the pps_unregister_source(). If more processes try to execute this code the first which enters will execute idr_remove() which prevents Here my proposal. It could be enought? :) diff --git a/drivers/pps/kapi.c b/drivers/pps/kapi.c index 6cac7b8..34b3b22 100644 --- ...
Mar 25, 7:44 am 2008
Rodolfo Giometti
Re: [PATCH 1/7] LinuxPPS core support.
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 --
Mar 25, 3:53 am 2008
Huang, Ying
Re: [PATCH -mm] kexec jump -v9
On Fri, 2008-03-21 at 15:12 -0400, Vivek Goyal wrote: I think the ELF_NOTES mechanism is sufficient for communication between two kernel. Because it can be written from user space tool in the kernel A (/sbin/kexec via sys_kexec_load), and read from user space tool in the kernel B (via /proc/vmcore). It can be used as user space communication mechanism. So I think it may be not necessary to communicate with initrd. If we want to load the hibernated image with sys_kexec_load (/sbin/kexec -l), ...
Mar 25, 12:25 am 2008
Jean Delvare
Re: [i2c] Wanted: i2c subsystem co-maintainer
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 &lt;khali@linux-fr.org&gt; --- 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 +++ ...
Mar 25, 1:50 am 2008
Christopher S. Aker Mar 24, 6:37 pm 2008
Alan Cox
Re: [PATCH] Work around breakage introduced in pata_sil6 ...
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 --
Mar 25, 4:36 pm 2008
Guennadi Liakhovetski
[PATCH] Work around breakage introduced in pata_sil680 b ...
pata_sil680 is broken on Linkstation amd Kurobox HG machines since 2.6.24. Work around the breakage until a real fix is found. Signed-off-by: Guennadi Liakhovetski &lt;g.liakhovetski@gmx.de&gt; --- How about the one below? I'd really like to get it in for 2.6.25 to avoid a second broken stable kernel on these machines. Ben, please verify that your cell machines still work. Thanks Guennadi diff --git a/drivers/ata/pata_sil680.c b/drivers/ata/pata_sil680.c index 503245a..75179ff ...
Mar 25, 4:31 pm 2008
Jochen Friedrich
Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Fr ...
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 &lt;jochen@scram.de&gt; --- drivers/of/Kconfig | 6 +++ drivers/of/Makefile | 1 + drivers/of/i2c.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++ ...
Mar 25, 11:46 am 2008
Alejandro Riveira
Re: Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
El Tue, 25 Mar 2008 14:46:28 +0100 Different kernel version the problem persisted and i thought i let people know that there was still an issue. If that makes me a &quot;forum spammer&quot; then i am one. Anyway it seems that I am only wasting your time so I stop here. Thanks for your time and work. --
Mar 25, 8:46 am 2008
Ivo van Doorn
Re: Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
I just checked the forums and apparently you mean that 8 replies to your topic including the answer about &quot;it has been fixed&quot; in 2.1.0 counts as 'ignored'... For reference: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=4512&amp;highlight= and yes the following topic was unanswered http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=4572&amp;highlight= --
Mar 25, 6:46 am 2008
Ivo van Doorn
Re: Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
Well DRV_PROJECT is the link to the website, that contains more information about the project. When people want to report bugs they can choose to use the bugzilla, forum or mailinglist. So I don't see a big point in replacing the link. Ivo --
Mar 25, 8:35 am 2008
Alejandro Riveira
Re: Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
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 +++ ...
Mar 25, 8:08 am 2008
Alejandro Riveira
Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
Running Linux Varda 2.6.25-rc6-00268-gd2532dd #1 SMP PREEMPT Mon Mar 24 14:44:13 CET 2008 x86_64 GNU/Linux As the last time the thing is triggered with a p2p app making a lot of connections deluge My logs are spammed with the same msgs as other reports. If you need more info just ask. PS: i will not bother to make a report in the web forums becouse the last time i was ignored. (Someone may want to change the web forums pointer in the logs to the linux-wireless mailing ...
Mar 25, 5:12 am 2008
Ivo van Doorn
Re: Spammed logs again rt2500pci 2.6.25-rc6-00268-gd2532dd
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 ...
Mar 25, 6:41 am 2008
previous daytodaynext day
March 24, 2008March 25, 2008March 26, 2008