* Step 5 "cpu_mask_to_apicid" of cleaning up io_apic.c modifies the cpu_mask_to_apicid genapic interface to pass a pointer to incoming cpumask_t argument removing yet another "cpumask_t variable on the stack". apicid = cpu_mask_to_apicid(cpumask); becomes: apicid = cpu_mask_to_apicid(&cpumask); * All the appropriate genapic "cpu_mask_to_apicid" functions are modified to use this new interface. * Total stack savings are: ====== Stack (-l 100) 1 - ...

* Step 3 "target_cpus" of cleaning up io_apic.c modifies the TARGET_CPUS interface to pass a pointer to the returned mask for arch X86_64, removing yet another "cpumask_t variable on the stack". target_cpus = TARGET_CPUS; becomes: TARGET_CPUS(target_cpus); For x86_32 this is expanded to: target_cpus = (genapic->target_cpus()); For x86_64 this is expanded to: target_cpus = (genapic->target_cpus)(&(target_cpus)); * All the appropriate genapic ...

* Step 1 of cleaning up io_apic.c removes local cpumask_t variables from the stack. - Method 1: remove unnecessary "extra" cpumask variables. - Method 2: use for_each_online_cpu_mask_nr() to logically AND the passed in mask with cpu_online_map, eliminating the need for a temp cpumask variable. - Method 3: use get_cpumask_var variables where possible. The current assignment of temp variables is: /* * Temporary cpumask variables * ...

* Make the following changes to acpi-cpufreq.c functions: - use node_to_cpumask_ptr in place of node_to_cpumask - use get_cpumask_var for temporary cpumask_t variables - use alloc_cpumask_ptr where available - use a per_cpu temp variable for drv_cmd which contains an embedded cpumask_t variable. * The resultant stack savings are: ====== Stack (-l 100) 1 - initial 2 - stack-hogs-acpi-cpufreq_c '.' is less than the limit(100) .1. .2. ...

* Adds debugging to the get_cpumask_var operations. It uses a primitive per_cpu lock variable and will only discover nested get_cpumask_var operations on the same variable. Applies to linux-2.6.tip/master. Signed-off-by: Mike Travis <travis@sgi.com> --- arch/x86/Kconfig.debug | 12 ++++++++++++ include/linux/cpumask_ptr.h | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+) --- linux-2.6.tip.orig/arch/x86/Kconfig.debug +++ ...

* Add for_each_online_cpu_mask_nr() function to eliminate need for a common use of a temporary cpumask_t variable. When the following procedure is being used: funcproto(cpumask_t *mask, ...) cpumask_t temp; cpus_and(temp, *mask, cpu_online_map); for_each_cpu_mask_nr(cpu, temp) ... If then becomes: for_each_online_cpu_mask_nr(cpu, *mask) ... * Note the generic __next_cpu_and (and __next_cpu_and_nr) functions allowing AND'ing with any cpumask_t ...

* Define a generic cpumask_ptr type and some helper functions that * do not add any overhead to low count NR_CPUS systems. Essentially * for NR_CPUS <= BITS_PER_LONG, an array of one cpumask is created on * the stack. For larger count systems, a pointer is defined. In both * cases the pointer variable can be used as C will optimize out the * pointer derefence in the small system case. * * Add a simple kmalloc to allocate a temporary cpumask variable. * (Note, kmalloc should be ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11209 Subject : 2.6.27-rc1 process time accounting Submitter : Lukas Hejtmanek <xhejtman@ics.muni.cz> Date : 2008-07-31 10:43 (38 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11465 Subject : Linux-2.6.27-rc5, drm errors in log Submitter : Gene Heskett <gene.heskett@verizon.net> Date : 2008-08-30 18:52 (8 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11264 Subject : Invalid op opcode in kernel/workqueue Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com> Date : 2008-08-07 04:18 (31 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11442 Subject : btusb hibernation/suspend breakage in current -git Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2008-08-25 11:37 (13 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11220 Subject : Screen stays black after resume Submitter : Nico Schottelius <nico@schottelius.org> Date : 2008-07-31 21:05 (38 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11224 Subject : Only three cores found on quad-core machine. Submitter : Dave Jones <davej@redhat.com> Date : 2008-08-01 18:15 (37 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (17 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11471 Subject : GPE storm detected, kernel freezes Submitter : George Gibbs <Vash63@gmail.com> Date : 2008-08-31 22:00 (7 days old) Handled-By : Zhang Rui <rui.zhang@intel.com> --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11501 Subject : Failed to open destination file: Permission deniedihex2fw Submitter : Andrew Morton <akpm@linux-foundation.org> Date : 2008-09-04 18:34 (3 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11358 Subject : net: forcedeth call restore mac addr in nv_shutdown path Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-17 3:30 (21 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11336 Subject : 2.6.27-rc2:stall while mounting root fs Submitter : Torsten Kaiser <just.for.lkml@googlemail.com> Date : 2008-08-12 12:37 (26 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (17 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11237 Subject : corrupt PMD after resume Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2008-08-02 9:51 (36 days old) References : ...

This message contains a list of some regressions from 2.6.26, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.26, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11271 Subject : BUG: fealnx in 2.6.27-rc1 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 14:58 (33 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11512 Subject : sort-of regression due to "kconfig: speed up all*config + randconfig" Submitter : Alexey Dobriyan <adobriyan@gmail.com> Date : 2008-09-05 22:50 (2 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11276 Subject : build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-06 17:18 (32 days ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11230 Subject : Kconfig no longer outputs a .config with freshly updated defconfigs Submitter : Josh Boyer <jwboyer@linux.vnet.ibm.com> Date : 2008-08-02 16:03 (36 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11272 Subject : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 15:12 (33 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11335 Subject : 2.6.27-rc2-git5 BUG: unable to handle kernel paging request Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-12 4:18 (26 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11506 Subject : oops during unmount - ext3? (2.6.27-rc5) Submitter : Marcin Slusarz <marcin.slusarz@gmail.com> Date : 2008-09-04 19:14 (3 days old) References : ...

I think this is closer to what we really want; after all, memory being written is the "first principles" test that applies here. -- Sent from my mobile phone (pardon any lack of formatting) -----Original Message----- From: Andrey Borzenkov <arvidjaar@newmail.ru> Sent: Saturday, September 06, 2008 10:46 To: H. Peter Anvin <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org>; Rafael J. Wysocki <rjw@sisk.pl>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Ingo Molnar ...

From: Alain Knaff <alain@knaff.lu> This patch, based on an idea by Christian Ludwig, includes support for compressing the kernel with bzip2 or lzma rather than gzip. Both compressors give smaller sizes than gzip. Moreover, lzma's decompresses faster than gzip. It also supports ramdisks and initramfs compressed using these two compressors. The functionality has been successfully used for a couple of years by the udpcast project This version applies to kernel 2.6.26.3 Signed-off-by: ...

From: Alain Knaff <alain@knaff.lu> While making the bzip/lzma compression patch, I noticed that vmlinux.scr was mistakenly listed in Documentation/dontdiff although it is a source file, and not a generated file (it's present in the .tar archive) However, a couple of files that were really generated were missing. Signed-off-by: Alain Knaff <alain@knaff.lu> --- diff -purN -X linux-2.6.26.3udpcast/Documentation/dontdiff linux-2.6.26.3/Documentation/dontdiff ...

The current frequency can be read from either /proc/cpuinfo or /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq . The voltage /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq - though on x86, setting this to anything other than the maximum will result in more No, you can do that in userspace. Charge time has only been exposed for apm, and that's because the BIOS gave it to us. Accurate figures are going to require learning the behaviour of the specific battery, and ...

applied the commit below to tip/genirq - thanks Pawel. Ingo -------------> From 7e6e178ab1548c8d894a77593e757acf4510b8ba Mon Sep 17 00:00:00 2001 From: Pawel MOLL <pawel.moll@st.com> Date: Mon, 1 Sep 2008 10:12:11 +0100 Subject: [PATCH] genirq: irq_chip->startup() usage in setup_irq and set_irq_chained handler This patch clarifies usage of irq_chip->startup() callback: 1. The "if (startup) startup(); else enabled();" code in setup_irq() is unnecessary, as startup() falls back to ...

added cc: kvm@vger.kernel.org --

applied to tip/irq/sparseirq, thanks. Maybe some design documentation would be nice too, to point out that most of the pain we do here is because we dont have bootmem available as early as we need an already instantiated dyn-array based IRQ array. So we try this mix of an abstraction of preallocated and post-allocated array, with pre-bootmem and post-bootmem behavior. Ingo --

git commit 74811f355f4f69a187fa74892dcf2a684b84ce99 causes crash at module load (or boot) time on my machine with a hpt374 controller. The reason for this is that for initializing second controller which sets (hwif->dev == host->dev[1]) to true (1), adds 1 to a void ptr, which advances it by one byte instead of advancing it by sizeof(hpt_info) bytes. Because of this, all initialization functions get corrupted data in info variable which causes a crash at boot time. This patch fixes that and ...

On Sat, Sep 6, 2008 at 12:44 PM, Andrew Morton current tip/master two days ago works. YH --

which kernel version is this? --

One thread being idle is even on Atom the right thing to do in some situations. If you have processes which, when HT is used, experience high pressure on the common cache(s) then you should not schedule them together. We can theoretically find out whether this is the case using the PMCs. With perfmon2 hopefully on the horizon soon it might actually be possible to automatically make these measurements. There is another aspect I talked to Peter about already. We really want concurrent ...

On Sat, 06 Sep 2008 16:43:31 +0100 but you cannot imfluence the cpu's scheduling of the instructions. As an OS one COULD decide to just not schedule the nice task at all, but then, especially on atom where HT has a high efficiency, your cpu is mostly idle ... -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

Here's how I imagine it: say I have one regular task and one "nice -9" task. On a conventional uniprocessor system they would get about 90% and 10% of the CPU respectively. On the hyperthreadng system they currently get equal shares; except that the CPU is more efficient with two threads running, so you could perhaps say that they get 60% each or something like that. But 60% is still less than 90%, and I don't want my foreground interactive task being slowed down that much by this ...

Linus, Please pull the latest timers-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git timers-fixes-for-linus This is a rather large update that late in the rc cycle, but it's all really important bugfixes around the timers/timekeeping code. The C1E idle support (added in .27) made some long standing bugs in the timers code more prominent and I spent almost two weeks now going through the code with a fine comb, creating debug patches and ...

Linus, please pull another ALSA fix for 2.6.27-rc5 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus which is a simple regression fix in Kconfig. Thanks! Takashi === Takashi Iwai (1): Fix CONFIG_AC97_BUS dependency sound/Kconfig | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/sound/Kconfig b/sound/Kconfig index a37bee0..8ebf512 100644 --- a/sound/Kconfig +++ b/sound/Kconfig @@ -91,6 +91,9 @@ endif # ...

When switching from kwin composite wm (KDE 4.1) to compiz I often hit the following error: Sep 6 10:24:31 poppero1 kernel: [ 186.138203] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f726bc80 f68f6840 Sep 6 10:24:31 poppero1 kernel: [ 186.138568] [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f726bc80 f68f6840 probably due to broken X drivers/apps; after hitting this the error my laptop (hp nx7010) is totally ...

On Sat, Sep 6, 2008 at 11:09 AM, James Courtier-Dutton Doesn't dmidecode already allow this? e.g. sudo dmidecode --type baseboard possibly combined with: sudo dmidecode --type chassis See for reference: With respect to sound in/out, it might benefit userland as well, to help set up your speakers. Particularly as some cards allow for several plugs to be both in- and output at one's choosing. --

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/amd.c | 3 --- arch/x86/kernel/cpu/amd_64.c | 3 +-- arch/x86/kernel/cpu/centaur.c | 1 - arch/x86/kernel/cpu/common.c | 9 +++------ arch/x86/kernel/cpu/cpu.h | 1 - arch/x86/kernel/cpu/cyrix.c | 1 - arch/x86/kernel/cpu/transmeta.c | 1 - 7 files changed, 4 insertions(+), 15 deletions(-) Index: ...

applied to tip/x86/unify-cpu-detect, thanks Yinghai. Ingo --

ble, Actually it is not. brightness_switch_enabled only disables event handling; it still resets actual brightness on loading and creates sysfs files to

yup thanks. The acpi guys and Rusty are still scratching each others That's coming out of the module loader and is a new one. It's the same I'm suspecting an overactive assertion in the new vmap code? --

We are pleased to announce the 2.6.26.3-rt7 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.26-rt6 - PPC ftrace fixes (Steven Rostedt) - PPC revert a reverted patch reverted again (Chirag Jog) to build a 2.6.26.3-rt7 tree, the following patches should be applied: ...

applied to tip/tracing/ftrace, thanks Steve. Ingo --

ftrace_release is necessary for all uses of dynamic ftrace and not just the archs that have CONFIG_FTRACE_MCOUNT_RECORD defined. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- include/linux/ftrace.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) Index: linux-tip.git/include/linux/ftrace.h =================================================================== --- linux-tip.git.orig/include/linux/ftrace.h 2008-09-05 16:04:34.000000000 -0700 +++ ...

Not so. 5.5.3 actually says this: The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following: - Has transferred exactly the amount of data specified during the Setup stage - Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet This clearly indicates that if the amount of data specified in the Setup stage is a multiple of the wMaxPacketSize then there should not be a ...

The virtual CPUs are more of a problem. They can't be distinguished from the real CPU models they are emulating other than by actually testing. --

Right, hence the first-principles test. In theory we could just execute the test on ALL CPUs, but I have excluded family < 6 simply because there is a (very) remote possibility one of them might have used that opcode for something completely different. -hpa --

if so, should only test on VIA chips. YH --

A file size of 4096KB is probably just running entirely out of the cache.. --

it crashes two testsystems, the fault on a NULL pointer in hpet init, with: initcall print_all_ICs+0x0/0x520 returned 0 after 26 msecs calling hpet_late_init+0x0/0x1c0 BUG: unable to handle kernel NULL pointer dereference at 000000000000008c IP: [<ffffffff80d228be>] hpet_late_init+0xfe/0x1c0 PGD 0 Oops: 0000 [1] SMP CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.27-rc5 #29725 RIP: 0010:[<ffffffff80d228be>] [<ffffffff80d228be>] hpet_late_init+0xfe/0x1c0 RSP: ...

Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states. If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 ...

Basic HPET MSI setup code. Routines to perform basic MSI read write in HPET memory map and setting up irq_chip for HPET MSI. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> --- arch/x86/kernel/hpet.c | 54 ++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/io_apic.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++ include/asm-x86/hpet.h | 21 +++++++++++++++ 3 files changed, 139 insertions(+) Index: ...

yeah, I was just trolling ;) I queued this fix for 2.6.27. --

From: "ext Andrew Morton" <akpm@linux-foundation.org> Subject: Re: [PATCH] Add missing macro argument for devm_release_* family Not sure for others, but at least, I am using this in my developing driver;) --

looks good to me - it's fairly safely structured and also in small, single-purpose steps. If there's a problem with them bisection should give a very good clue about exactly where. So i've created a new tip/x86/signal topic for them and applied them - lets see how it goes. Thanks, Ingo --

I've got a whole slew of "get-ready-to-remove-cpumask_t's" coming soon. There are two phases, one completely within the x86 arch and the 2nd hits the generic smp_call_function_mask ABI (won't be doable as a back-ported Hmm, no. I'm using a default config right now as I can boot that pretty The main thing is to allow the distros to set it manually for their QA testing of 2.6.27. I'm sure I'll get back bugs because of just that. (Is there a way to have them know to assign bugzilla's to ...

applied to tip/sched/rt, thanks Krzysztof! Ingo --

hm, that doesnt seem to match the ranges that got printed: | Kernel is loaded at the standard 2MB physical, and goes up to 13.6MB | physical. That's a tad large at 11.6 MB but still valid. so how come a ~2MB vmlinux takes 11.6 MB? Is the bss that large for some reason perhaps? Ingo --

good question. Does your successful 2.6.26 bootup actually _depend_ on the initrd? Or does it perhaps have enough built-in drivers that make it boot just fine? in that case v2.6.26 might just have stomped on the initrd silently, corrupted it (during kernel decompress), and the initrd unpacker saw the corruption and ignored it. Userspace wouldnt care as the kernel had all the drivers it needed. or perhaps something made your v2.6.27 bzImage larger so that the very much so. I was ...

wonder if lilo is fixing bzImage from 1M, and when it is calculating pos of ramdisk...base that later on-same-position uncompressing, put vmlinux from 2M... it seems kexec is puting initrd as high as possible, or could specify the ramdisk postion .. wonder if new lilo could help. YH --

Sorry, the sentence above is not very clear: I meant that with 2.6.27 the uncompressed vmlinux is only slightly bigger than older kernels; as you stated the size is 11.6MB. Luca --

ok - Peter says he'd rather like to investigate this some more and have the fix in v2.6.28 instead - so i moved it from tip/x86/urgent to tip/x86/setup. Ingo --

Was it really that simple? Subject: [PATCH] Fix ghost devices under /sys/firmware/edd =46rom: Andrey Borzenkov <arvidjaar@mail.ru> Some BIOSes do not always set CF on error before return from int13. The patch adds additional check for status being zero (AH =3D=3D 0). This was fixed for edd.S in http://marc.info/?l=3Dlinux-kernel&m=3D114087765422490&w=3D2, but lost again when edd.S was rewritten in C. Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru> =2D-- arch/x86/boot/edd.c | ...

Do you have any evidence that there aren't any BIOSes which leave AH != 0 on legitimate success? If so, you have turned a nuisance bug into something that could cause install failures. -hpa --

I'm quite sceptical that it can be ever made to work in a useful way for real hardware (as opposed to an hypervisor para virtual setup for which this interface is not the right way -- it should be done in some specific driver instead) And if it cannot be made to work then it will be a false promise to the user. They will see it and think it will work, but it will not. This means I don't see a real use case for this feature. -Andi --

yeah, most likely. (It's possible technically even on a native kernel - yeah - it's actually the way how hugetlb should be done. Plus expand gbpages to hugetlbfs and hotplug memory on Barcelona CPUs and you can do user-space apps that can run for a long time without any TLB misses. _That_ might make sense to explore in practice. (i'm not holding my breath though, TLB misses are _fast_ on the best x86 CPUs.) But we wont be able to make such experiments without having the capability ...

I don't think its driver is almighty. IIRC, balloon driver can be cause of fragmentation for 24-7 system. In addition, I have heard that memory hotplug would be useful for reducing of power consumption of DIMM. I have to admit that memory hotplug has many issues, but I would like to solve them step by step. Thanks. -- Yasunori Goto --

Here are some results obtained during runs where we varied the number of readers & the multi-block read counts. 5 runs per rq_affinity setting were done, and the averages are plotted at: http://free.linux.hp.com/~adb/jens/08-09-05/by_mbr.jpeg In all cases we are seeing a noticeable improvement in reduction of elapsed time to perform the tasks, and again we are seeing much tighter deviations with rq_affinity set to 1: Min Avg Max Std Dev ...

http://kisskb.ellerman.id.au/kisskb/buildresult/45949/: | drivers/net/wireless/b43/phy_g.c:388: error: implicit declaration of function 'mmiowb' | distcc[4257] ERROR: compile drivers/net/wireless/b43/phy_g.c on localhost failed | make[5]: *** [drivers/net/wireless/b43/phy_g.o] Error 1 Missing #include <asm/io.h>? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call ...

On Fri, 5 Sep 2008 12:43:05 +0200 The current comment is reasonable for me: /* Don't invoke OOM killer or retry in lower 16MB DMA zone */ if (gfp & __GFP_DMA) noretry = 1; --

At Fri, 05 Sep 2008 14:09:24 -0700, Thanks for checking! Takashi --

hm, is it worth the trouble? This is during very early init. Ingo --

[Yinghai Lu - Sat, Sep 06, 2008 at 12:16:28PM -0700] | On Sat, Sep 6, 2008 at 12:04 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | > [Maciej W. Rozycki - Sat, Sep 06, 2008 at 07:45:08PM +0100] | > | On Sat, 6 Sep 2008, Cyrill Gorcunov wrote: | > | | > | > Ingo, how about the following approach? We don't introduce new | > | > functions but rather srink the code by new printout form. | > | | > | Honestly, this one should probably use sprintf() or suchlike to avoid the | > | mess of printk() ...

Honestly, this one should probably use sprintf() or suchlike to avoid the mess of printk() calls building a line of output from pieces. It's quite easy to calculate here what the maximum size of the buffer required could be and automatic arrays can have variable size, so no need for the hassle of heap management. Calls to printk() without a trailing newline should be avoided where possible as it messes up logging priority if a message pops up from an interrupt inbetween. Maciej --

[Cyrill Gorcunov - Sat, Sep 06, 2008 at 11:38:20PM +0400] | [Yinghai Lu - Sat, Sep 06, 2008 at 12:16:28PM -0700] | | On Sat, Sep 6, 2008 at 12:04 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > [Maciej W. Rozycki - Sat, Sep 06, 2008 at 07:45:08PM +0100] | | > | On Sat, 6 Sep 2008, Cyrill Gorcunov wrote: | | > | | | > | > Ingo, how about the following approach? We don't introduce new | | > | > functions but rather srink the code by new printout form. | | > | | | > | Honestly, this one ...

But is it really a trouble? With an auto array the additional code is minuscule -- mostly printk() calls replaced with sprintf() plus a variable or two to maintain a pointer to the buffer which will go into registers anyway. Plus a pr_info("%s", buffer) or suchlike at the end. I know laziness is a virtue, but you have to draw a line somewhere. ;) The benefit, apart from what I wrote above, is less chance of propagating bad style to newcomers with each piece of such old code removed. ...

applied to tip/irq/sparseirq - thanks Cyrill. Ingo --

My original patch actually had that, and Ingo added it to the -tip tree too (I think), so that should be the one we're discussing anyway. I just didn't think it would ever trigger in practice, which is why I removed it. Mea culpa. Linus --

Show me. Because I simply don't believe you. The first code is simply _wrong_ - except if "expect" isn't even _used_ afterwards (in which case gcc can optimize away the last unused write). And I strongly suspect that that is what you've seen. Because quite frankly, if what you describe is real, then your gcc is incredibly buggy. So buggy that it sounds unlikely to be able to compile the kernel in many other places. This is very simple and very fundamental C, not something subtle ...

Just checked, yes you are right. I messed that up in my tiredness to see the obvious bug in Ingo's fixup patch. /me resorts to bed tglx --

My bad. Did not test that against -tip, just applied it from mail :) Just checked. The -tip version still has the expect-- in the for() which might lead to stupid results depending on the gcc madness level. Thanks, tglx --

hm, yes, that's my brown paper bag fault, sorry. I did that addition in tip/x86/tsc and posted it to you and i did test it immediately - and i noticed that i never saw the fast-calibration message i expected to see. I even pasted the boot log over irc yesterday and i still have it: *> [ 0.000] TSC: PIT calibration deviates from PMTIMER: 738839 846296. *> [ 0.000] TSC: Using PIT calibration value *> [ 0.000] Detected 738.839 MHz processor. *> does not seem to trigger ...

I just ran your patch in a loop on the SMI mephitic laptop with random delays between the loops. 20 out of 10000 results are between 2200 and 8400Mhz while the CPU still runs @2GHz. And it also happened in an automated boot/reboot cycle (no extra loop) once out of 50. So the SMI hit exactly: + t1 = get_cycles(); + for (expect = 0xfe, i = 0; i < QUICK_PIT_ITERATIONS; i++, expect--) { + if (!pit_expect_msb(expect)) + goto failed; + } -----> HERE + t2 = ...

Quite the reverse. We have a guarantee that it _is_ decremented. Adn that guarantee is very much about the C language. for (a ; b ; c) { .. } translates as a; while (b) { .. continue: c; } And this has absolutely _nothing_ to do with any gcc oddity or anything else. The fact is, the code that Ingo added was totally bogus. The real bug was that he did a totally bogus "--expect" in the argument to that last call. Because 'c' *will* have been done ...

Over which _whole_ thing ? You want to have the very very fast thing, which is not reliable under all circumstances as Alok pointed out and Why not ? We want to figure out if it solves the problem and sending What we apply finally is a totally different thing. Thanks, tglx --

I didn't know that sending a test patch which is admittetly not pretty is a capital crime nowadays. In future I'll restrict myself to look at such stuff only on Monday to Friday between 9AM and 5PM and send test/RFC patches only when they got approved by the nonshitapproval committee, which holds a meeting once a month. Yours grumpy, tglx --

Um, I don't see how that follows. get_request_wait() is the first thing the block layer does to try to get a request structure for the queue. If it's stuck there it means that block was out of requests and is waiting for some memory to free up. If we're stuck there, nothing went down to the CD. However, being stuck here really isn't good news. These things are mempool backed to prevent writeout deadlock ... we shouldn't be running out of them. What does ...

Right. It looks like there was a media change in the CD drive and hald was waiting for the device in sr_test_unit_ready() forever. Apparently, the device could not get ready. It looks like a SATA/ATA (whatever the CD-ROM is attached to) issue or sr_mod breakage. Thanks, Rafael --

it's minimal and easy. It really works to operate on the source code - this 'open source' thing ;-) We just still tend to think in terms of binary software practices that have been established in the past few not a problem really, it is rather small compared to all the stuff that is in a typical disto install. I like the fundamental message as well: "If you want to be more secure, you've got to have the source code, and it's not an unsolvable problem. The debug info can be on a ...

Hello. The thing with colors is that they are very personal... The colors I have work great on my terminals. I don't think I can come up with one scheme which looks nice to everybody, hence the support for color schemes. If you can come up with a color scheme which works gr8 for you, I'll be happy to add it. If you are interested, check the I cannot reproduce this. What terminal emulator are you using, and which ncurses version? Also, can you please send me the terminal Yes. You need to ...

binfmt_script and binfmt_misc disallow recursion to avoid stack overflow using sh_bang and misc_bang. It causes problem in some cases: $ echo '#!/bin/ls' > /tmp/t0 $ echo '#!/tmp/t0' > /tmp/t1 $ echo '#!/tmp/t1' > /tmp/t2 $ chmod +x /tmp/t* $ /tmp/t2 zsh: exec format error: /tmp/t2 Similar problem with binfmt_misc. This patch introduces field 'recursion_depth' into struct linux_binprm to track recursion level in binfmt_misc and binfmt_script. If recursion level more then ...

ok, i've cherry-picked those two commits over into tip/x86/urgent. Ingo --

On Sat, 6 Sep 2008 16:56:10 +0200 ok I fixed this in the master branch of git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-hrtimer.git --

ah, you are right ... and i thought i could trust grep -i acpi drivers/pci/intel-iommu.c coming up empty ;-) Jesse's call obviously, but the DMI thing local to intel-iommu.c still looks better to me in all regards. I'm no fan of DMI in general - it just doesnt scale - but here a crappy BIOS gets punished with a DMI quirk and that's OK. Ingo --

Acked-by: Ingo Molnar <mingo@elte.hu> Ingo --

applied to tip/x86/cleanups - thanks Christoph. I'm curious, how did you find it, some automation - or old-fashioned code reading? Ingo --

hm, doesnt this break things like CPU cross-calls done in CPU_DYING callbacks? Ingo --

On Fri, 05 Sep 2008 16:03:54 -0500 What the... It seems someone broke git-diff (or less). This one is properly undamaged: diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 62a4c91..dad8edb 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -29,6 +29,7 @@ #include <linux/blkdev.h> #include <linux/mutex.h> #include <linux/scatterlist.h> +#include <linux/string_helpers.h> =20 #include <linux/mmc/card.h> #include <linux/mmc/host.h> @@ -496,6 ...

Yep, same bug in mainline. --

Irrelevant - what if UML, or anything else for that matter, starts using CLONE_IO? All of a sudden, valgrind will start letting those Yeah, if you cloned in a signal handler, that would be a problem. How about sticking the annotation in the thread itself? This may be Jeff -- Work email - jdike at linux dot intel dot com --

ok, please check that in another mail. YH --

that needs fixing too i think. We dont really want to sprinkle the code with various specific panics. Ingo --

pulled, thanks Vegard. Great progress on a rather difficult aspect of kmemcheck! Ingo --

Moving Squashfs over to the crypto API is a good idea. When the zlib crypto module code is in the mainline kernel moving Squashfs, AxFS and CRAMFS over will be easy. Are you planning to do the necessary work to get this (or a subsequent version following the comments from Herbert Xu) into mainline? Cheers Phillip --

applied to tip/x86/cleanups, thanks. Ingo --

applied to tip/x86/core, thanks Jan. Ingo --

applied to tip/x86/xen, thanks Jan. Ingo --

so these are added: MK8 || MCORE2 || MCRUSOE || MEFFICEON especially the Core2 one should be rather relevant, on 32-bit systems. Applied to tip/x86/cpu, thanks Jan. Ingo --

Seems to work correctly. The first spindown no longer happens. In the BTS you noted the support is "partial". What's partial about it? Thanks Rafael. --

the latter, i misunderstood how it works. Ingo --

please put this all behind a .config debug option that distros can turn on/off. Also, when it's enabled in the .config, there should be another .config option that marks it disabled by default but it can be enabled via a boot parameter. Distro debug kernels will most likely enable the .config - even release kernels might enable it it, with default off - users can enable the boot switch if they suspect something, without having to build a new kernel. Ingo --

On Sat, 6 Sep 2008 13:39:55 +0200 I never thought TRACE_PRINT would need anything more. At least I'm happy with the concept of TRACE_PRINT, it just needs some adjustments in the API to be nice to use. True, I might some day want to add yet another entry type for mmiotrace, but I'm not planning that for now, and I could just add it like they are in the current framework. But the benefit of the CUSTOM type would be to allow modularized and out-of-tree tracers. And then, why keep the current ...

agreed - stable Cc:-ed. It's about this upstream commit: | commit 38c052f8cff1bd323ccfa968136a9556652ee420 | Author: Ingo Molnar <mingo@elte.hu> | Date: Sat Aug 23 17:59:07 2008 +0200 | | rtc: fix deadlock please backport it into -stable .26 and .25. Thanks, Ingo --

Ubuntu Feisty ships with NR_CPUS=8, but yes, I imagine that this number will increase. Perhaps a table for 64-bit CPUs: Cachelines per Total NR_CPUs Implementation Cachelines 1-64 1 2 [laptop distros] 65-128 3 6 [x86 distros, Power] 129-192 4 8 193-256 5 10 257-320 6 12 321-384 7 14 385-448 8 16 449-512 9 18 [SGI ca. 2004] 513-576 10 20 577-640 11 22 ...

I'd like to keep this comment, as the #define is still there. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds --