How about this? #include <stdio.h> #define CONFIG_FOO 1 /* #define CONFIG_BAR 1 */ #define STR2(x) #x #define STR(x) STR2(x) #define PASTE2(x, y) x##y #define PASTE(x, y) PASTE2(x, y) #define KCONFIG2(x, y) STR(PASTE(CONFIG_, x))[y] #define KCONFIG(x) (!((KCONFIG2(x, 0) == 'C') && \ (KCONFIG2(x, 1) == 'O') && \ (KCONFIG2(x, 2) == 'N') && \ (KCONFIG2(x, 3) == 'F') && \ (KCONFIG2(x, 4) == 'I') && \ (KCONFIG2(x, 5) == 'G') && \ (KCONFIG2(x, 6) == ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10711 Subject : BUG: unable to handle kernel paging request - scsi_bus_uevent Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2008-05-14 11:23 (11 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629 Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160 Submitter : Alexey Dobriyan <adobriyan@gmail.com> Date : 2008-05-05 09:59 (20 days old) References : http://lkml.org/lkml/2008/5/5/28 Handled-By : Paul E. ...

Hello; This message seems to be appearing on a random, (every x amount of boots). At first I thought this was resolved with adjusting the .config but didn't seem to be the answer. Also I have third party modules installed i.g.(isight driver, and dri driver) which also might be causing this. I guess the best answer is if somebody else can verify this happens to them, with all in kernel modules. I on the other hand will unload the third party modules and see if this appears. regards; -- ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10686 Subject : critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700 Submitter : Len Brown <len.brown@intel.com> Date : 2008-05-12 20:04 (13 days old) Handled-By : Robert Moore ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10751 Subject : pciehp probing slow, duplicate kobject_add Submitter : Jan C. Nordholz <jckn@gmx.net> Date : 2008-05-19 14:26 (6 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10708 Subject : V4L2-based build error Submitter : Jonathan Corbet <corbet@lwn.net> Date : 2008-05-12 22:14 (13 days old) References : http://marc.info/?l=linux-kernel&m=121063048408534&w=4 Handled-By : Mauro ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10765 Subject : iwl3945/mac80211: association times out since 2.6.26-rc1 Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com> Date : 2008-05-20 22:46 (5 days old) Handled-By : Zhu Yi <yi.zhu@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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10761 Subject : hackbench regression with 2.6.26-rc2 on tulsa machine Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-05-20 8:09 (5 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10557 Subject : [regression] latest git couse kernel oops. Submitter : Alexey Fisher <bug-track@fisher-privat.net> Date : 2008-04-26 00:19 (29 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10787 Subject : pcie hotplug bootup crash fix Submitter : Ingo Molnar <mingo@elte.hu> Date : 2008-05-24 16:58 (1 days old) References : http://marc.info/?l=linux-kernel&m=121164842212038&w=4 Handled-By : Ingo ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724 Subject : ACPI : EC: GPE Submitter : Justin Mattock <justinmattock@gmail.com> Date : 2008-05-16 6:17 (9 days old) References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4 ...

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10748 Subject : dhclient fails to run; capabilities error Submitter : Amit Shah <shahamit@gmail.com> Date : 2008-05-19 06:25 (6 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725 Subject : Write protect on on Submitter : Maciej Rutecki <maciej.rutecki@gmail.com> Date : 2008-05-16 14:55 (9 days old) References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4 --

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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10760 Subject : PCIEHP breakage in 2.6.26-rc1,2.6.26-rc2,2.6.26-rc3 Submitter : Ryan Hope <rmh3093@gmail.com> Date : 2008-05-19 17:47 (6 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10638 Subject : sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-05-07 4:55 (18 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10670 Subject : BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status Submitter : Karol Lewandowski <lmctlx@gmail.com> Date : 2008-05-08 23:12 (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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10749 Subject : the system doesn't shutdown Submitter : Riccardo <goric@trivenet.it> Date : 2008-05-19 09:00 (6 days old) --

This message contains a list of some regressions from 2.6.25, 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.25, 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10759 Subject : recent 2.6.26 kernel hangs at suspend Submitter : Jeff Chua <jeff.chua.linux@gmail.com> Date : 2008-05-19 15:07 (6 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10634 Subject : volanoMark regression with kernel 2.6.26-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-05-06 2:06 (19 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9791 Subject : Clock is running too fast^Wslow using acpi_pm clocksource Submitter : tosn00j02@sneakemail.com Date : 2008-05-03 05:09 (22 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10710 Subject : [BISECTED] Lots of "rescheduling IPIs" in powertop Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-05-13 20:42 (12 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10713 Subject : ehci splatter in 2.6.26-rc2 Submitter : Lennert Buytenhek <buytenh@wantstofly.org> Date : 2008-05-14 11:24 (11 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10630 Subject : USB devices plugged into dock are not discoverred until reload of ehci-hcd Submitter : Lukas Hejtmanek <xhejtman@ics.muni.cz> Date : 2008-05-05 10:02 (20 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10669 Subject : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6) Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-05-06 16:09 (19 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.25. Please verify if it still should be listed. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10493 Subject : mips BCM47XX compile error Submitter : Adrian Bunk <adrian.bunk@movial.fi> Date : 2008-04-20 17:07 (35 days old) References : http://lkml.org/lkml/2008/4/20/34 http://lkml.org/lkml/2008/5/12/30 ...

Above I'm not speaking about my code, I'm only speaking in terms of a solution to this case, even if it isn't mine.. Daniel --

This is a configuration problem. You need to pick one driver or the other, not both, as that commit's description indicates. Jeff --

Could we s/KCONFIG_/CFG_/g ? CONFIG_ is long enough already, and K there is very maningless..... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Not today where we have one configuration definition per architecture. I hope we one day can change that so we have one for the whole kernel. This would for example allow us to detect when someone do a misspelled "depends on FOOBAR" because it will no longer be These symbols would be know of - their value would just be 0. The correct patch (last one posted) does this. Sam --

$ cat test.c #define KCONFIG(x) (CONFIG_##x - 0) int main() { if (KCONFIG(PREEMPT)) ; return 0; } $ gcc -O2 -Wall test.c test.c: In function ‘main’: test.c:5: error: ‘CONFIG_PREEMPT’ undeclared (first use in this function) test.c:5: error: (Each undeclared identifier is reported only once test.c:5: error: for each function it appears in.) $ gcc --version cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There ...

Yep. But is a unified config something that someone is actively working on, or a distant pipe dream? J --

When we have one configuration for the kernel and not as today where we have one configuration for each architecture (with a lot of shared files) then it is already taken care of by my (updated) patch. Sam --

Can we get the /etc/kernel-config regression fixed before even posting things like this? Please? Linus --

1) I have no pland to replace the current CONFIG_ use. My master plan is to have a single configuration for the kernel and not as today where we have one configuration for each architecture. How far away we are from that I dunno. It is a while I visited this. And I will not have time to do so anytime soon I'm afraid. Sam --

It would have helped if I had applied the correct patch... All boolean and tristate symbols in the konfiguration have their symbols defined as KCONFIG_* no matter their values. So KCONFIG_DVB_VES1820 would get defined. Correct patch below. Sam diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index ee5fe94..247ea30 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -666,6 +666,43 @@ out: return res; } +static void ...

You and your scientific method. Yeah, this is one of those cases where you need cpp to rescan its input after pasting, and I don't think it will ever do that. J --

We have many places in the kernel that looks like the following: #ifdef CONFIG_FOO ... #endif Which has the disadvantage that the code denoted '...' are not even built if CONFIG_FOO is not selected in the current configuration. We know that gcc do simple code-elimination for conditionals which is always true/false and thus the above code could be turned into: if (CONFIG_FOO) ... One line smaller and we follow the normal flow in the program. The code is always build but we do ...

Hi Ingo/Steven, Ftrace currently maintains an update count which includes false updates, i.e, updates which failed. If anything, such failures should be tracked by some separate variable, but this patch provides a minimal fix. Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> --- fix updating of ftrace_update_cnt diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index bfba25c..14e086f 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -443,7 +443,7 @@ static ...

Apply the io-throttle controller to the opportune kernel functions. Both accounting and throttling functionalities are performed by cgroup_io_account(). Signed-off-by: Andrea Righi <righi.andrea@gmail.com> --- block/blk-core.c | 2 ++ fs/buffer.c | 6 ++++++ fs/direct-io.c | 2 ++ mm/page-writeback.c | 5 +++++ mm/readahead.c | 2 ++ 5 files changed, 17 insertions(+), 0 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index ...

Hi, Andrea, There are several parallel efforts for the IO controller? Could you describe/compare them with yours? Is any consensus building taking place? CC'ing containers mailing list. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

This is the core io-throttle kernel infrastructure. It creates the basic interfaces to cgroups and implements the I/O measurement and throttling functions. Signed-off-by: Andrea Righi <righi.andrea@gmail.com> --- block/Makefile | 2 + block/blk-io-throttle.c | 219 +++++++++++++++++++++++++++++++++++++++ include/linux/blk-io-throttle.h | 10 ++ include/linux/cgroup_subsys.h | 6 + init/Kconfig | 10 ++ 5 files changed, 247 ...

sem_queue.sma and sem_queue.id were never used, the attached patch removes them. Signed-Off-By: Manfred Spraul <manfred@colorfullife.com> --- include/linux/sem.h | 2 -- ipc/sem.c | 2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/include/linux/sem.h b/include/linux/sem.h index 6a1af1b..87756ef 100644 --- a/include/linux/sem.h +++ b/include/linux/sem.h @@ -107,8 +107,6 @@ struct sem_queue { struct sem_undo * undo; /* undo structure */ int ...

The attached patch: - reverses the locking order of ulp->lock and sem_lock: Previously, it was first ulp->lock, then inside sem_lock. Now it's the other way around. - converts the undo structure to rcu. Benefits: - With the old locking order, IPC_RMID could not kfree the undo structures. The stale entries remained in the linked lists and were released later. - The patch fixes a a race in semtimedop(): if both IPC_RMID and a semget() that recreates exactly the same id happen between ...

I did some cleanup in ipc/sem: - ipc/sem contained hand-written linked lists, they can be replaced with standard list_head lists. - the locking was written before CLONE_SYSVSEM was introduced, with ulp->lock, it's now possible to free undo structures during IPC_RMID immediately. - There is a (extremely unlikely) race in semtimedop(), it can access kfree'd memory. The patches pass my own simple test cases, what do you think? -- Manfred --

-tip tree testing found that the the PCI hotplug ISR routine crashes with a NULL pointer dereference under certain circumstances. The situation under which it occurs is hw and timing related: it appears to happen on a system that has PCI hotplug hardware but with no active hotplug cards, and another interrupt in the same (shared) IRQ line arrives too early, before the hotplug-slot entry has been set up - as triggered by CONFIG_DEBUG_SHIRQ=y: pciehp: HPC vendor_id 8086 device_id 27d0 ...

Maybe I wasn't precise enough. The script looks for macros which take argument(s) i.e. Well I'll just go through some of them. This is long term task as its number is quite big. Maybe I can improve the script some more or apply some other measures. I guess one can find there all sort of macros and some part of them are leftovers from something that was there some time ago. Interesting part would be to write a 'parser' that actually sees the context and understands cpp directives, that ...

Possibly. There's likely to be a lot of macros unused like these ones: #define PCI_X_CMD_MAX_READ 0x000c /* Max Memory Read Byte Count */ /* Max # of outstanding split transactions */ #define PCI_X_CMD_SPLIT_1 0x0000 /* Max 1 */ #define PCI_X_CMD_SPLIT_2 0x0010 /* Max 2 */ #define PCI_X_CMD_SPLIT_3 0x0020 /* Max 3 */ ... where the macros embody the PCI specification in code -- possibly we don't use them yet, but if we ever did, ...

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi.c ==================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6.git/arch/x86/kernel/nmi.c 2008-05-24 17:23:04.000000000 +0400 @@ -0,0 +1,532 @@ +/* + * NMI watchdog support on APIC systems + * + * Started by Ingo Molnar <mingo@redhat.com> + * + * Fixes: + * Mikael Pettersson : AMD K7 support for local APIC NMI ...

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi_32.c ==================================================================== --- linux-2.6.git.orig/arch/x86/kernel/nmi_32.c 2008-05-24 13:07:08.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/nmi_32.c 2008-05-24 13:10:10.000000000 +0400 @@ -425,7 +425,7 @@ static int unknown_nmi_panic_callback(st char buf[64]; sprintf(buf, "NMI received for unknown reason %02x\n", reason); - die_nmi(buf, ...

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi_64.c ==================================================================== --- linux-2.6.git.orig/arch/x86/kernel/nmi_64.c 2008-05-24 13:09:27.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/nmi_64.c 2008-05-24 13:17:59.000000000 +0400 @@ -98,7 +98,7 @@ int __init check_nmi_watchdog(void) smp_call_function(nmi_cpu_busy, (void *)&endflag, 0, 0); #endif - for (cpu = 0; cpu < NR_CPUS; ...

apic_write_around will be expanded to apic_write in 64bit mode anyway. Only a few CPUs (well, old CPUs to be precise) requires such an action. In general it should not hurt and could be cleaned up for apic_write (just in case) Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi_32.c ==================================================================== --- linux-2.6.git.orig/arch/x86/kernel/nmi_32.c 2008-05-24 13:04:20.000000000 +0400 +++ ...

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi_32.c ==================================================================== --- linux-2.6.git.orig/arch/x86/kernel/nmi_32.c 2008-05-24 13:01:21.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/nmi_32.c 2008-05-24 13:04:20.000000000 +0400 @@ -51,6 +51,17 @@ static DEFINE_PER_CPU(short, wd_enabled) static int endflag __initdata = 0; +/* Run after command line and cpu_init init, but before all ...

Make 64bit die_nmi() to produce the same message as 32bit mode has Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> --- Index: linux-2.6.git/arch/x86/kernel/nmi_64.c ==================================================================== --- linux-2.6.git.orig/arch/x86/kernel/nmi_64.c 2008-05-24 12:07:40.000000000 +0400 +++ linux-2.6.git/arch/x86/kernel/nmi_64.c 2008-05-24 12:25:57.000000000 +0400 @@ -358,8 +358,8 @@ nmi_watchdog_tick(struct pt_regs *regs, */ ...

This is a functionally equivalent replacement of the current reference counting of struct fw_card instances. It only converts it to common idioms as suggested by Kristian Høgsberg: - struct kref replaces atomic_t as the counter. - wait_for_completion is used to wait for all card users to complete. BTW, it may make sense to count card->flush_timer and card->work as card users too. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- Applies after patch "firewire: clean up ...

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-card.c | 1 - drivers/firewire/fw-device.h | 1 - drivers/firewire/fw-ohci.c | 1 - drivers/firewire/fw-transaction.h | 2 -- 4 files changed, 5 deletions(-) Index: linux/drivers/firewire/fw-card.c =================================================================== --- linux.orig/drivers/firewire/fw-card.c +++ linux/drivers/firewire/fw-card.c @@ -497,7 +497,6 @@ ...

您2008想5給24心愛的另ㄧ半ㄧ份24驚5喜2008嗎？ 近5來5看5看，試5試5這5個5喔 ^.^ 珍23珠23貝23殼23項23鍊23禮23盒　～　日23本23九23州23空23運23來23台 網址在這→203.70.179.39/ju←複製這行網址貼上即可 ×∵⊙?▽

For some perverse reason, if you call add_preferred_console() it prevents setup_early_printk() from successfully enabling the boot console - unless you make it a preferred console too... Also, make xenboot console output distinct from normal console output, since it gets repeated when the console handover happens, and the duplicated output is confusing without disambiguation. [ Applies to end of xen pvfb series ] Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: ...

[ Doing a full config compile I came up with this ] Remove user_trace_stop that was more of a hack to debug xrun latencies. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- sound/core/pcm_lib.c | 1 - 1 file changed, 1 deletion(-) Index: linux-2.6.24.7-rt10/sound/core/pcm_lib.c =================================================================== --- linux-2.6.24.7-rt10.orig/sound/core/pcm_lib.c 2008-05-24 00:53:24.000000000 -0400 +++ ...

29 2008 3ca084f9-08fd-46a6-b6ec-ecfb5377c3b0 ★8★5★2008年日本通譯案內士考試：考前１０４天：★2★0★ ★★★您懂日文或曾經學過日文嗎？★★★★ 　　 　　月薪百萬台幣的簡單日本証照 　　　　這項對台灣人相當容易 考的日本執照考試告訴您：日本通譯案內士考試：只要考 簡單科目即可．不會比台灣的大學時期的期中考難喔．． 不必去坊間高價而效果有限補習班．告訴您自修即可簡單 自力達成方法．． 　(我們免費提供考試必須的：日本轉信地址) ★★★９９個國家如何去留學？★★★★ 及４０個低學費國家去留學．您想留學高學費的英日語以 外國家卻求助無門嗎？您知道全世界有４０個國家大學． 研究所．博士班免費．．這裡告訴您求助管道．． ★★★９９國語言如何去學習法？★★★★ 歐洲人精通５．６國語言是家常便飯．．您想精通數國以上語言竟求助無門嗎？ 請電　0　9　1　2　2　8　4　5　9　9張小姐詢問 想了解更多請至 ...

Many show operations in edd_attribute have same error checks at the head. This patch consolidates these error checks to callee function. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Matt Domsch <Matt_Domsch@Dell.com> --- drivers/firmware/edd.c | 74 ++++++++++++++++++++----------------------------- 1 file changed, 31 insertions(+), 43 deletions(-) Index: 2.6-git/drivers/firmware/edd.c =================================================================== --- ...

OK. This is update patch. From: Akinobu Mita <akinobu.mita@gmail.com> Subject: edd: fix error paths in module_init If kzalloc() or edd_device_register() failed in module_init, it returns error without cleanup the devices already registered. Rather than fixing it to back completely out (unregister everything that had successfully registered until now) and return error, This patch makes it have succeeded. Because having even the first device be reported, even if the others couldn't ...

(Adding Cc: block layer maintainer for no solid reason...) There was only a single change to drivers/block/floppy.c after 2.6.25: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7afea3... [...] By "until it(2.6.26-rc1) went away" you mean a crash during writing to or reading from the FDD, or during general usage? -- Stefan Richter -=====-==--- -=-= ==--- http://arcgraph.de/sr/ --

Greetings all; Who is the maintainer of drivers/block/floppy.c and associated files? I ask because there are a few of us still using it, in particular with what some may call oddball disk formats & I'm up to here with doing such as this: [root@coyote coco3]# setfdprm /dev/fd0 COCO7203.5 [root@coyote coco3]# getfdprm /dev/fd0 get geometry parameters: No such device Or: Assuming the above took, [root@coyote coco3]# dd if=/dev/fd0 of=test.dsk dd: reading `/dev/fd0': Input/output ...

On Fri, 23 May 2008 21:19:13 -0300 What is the problem you found? Why do you need to change the limit from 16? Did it bring you any performance enhancements? If so, how much? -- All rights reversed. --

On Fri, 23 May 2008 17:59:27 -0400 People who wonder why these pointers never get initialized: they point to the zeropage, which of course lives at address zero. /* The so-called "zeropage" */ struct boot_params { struct screen_info screen_info; /* 0x000 */ struct apm_bios_info apm_bios_info; /* 0x040 */ __u8 _pad2[12]; /* 0x054 */ struct ist_info ist_info; /* 0x060 */ ... -- ...

=?utf-8?q?Kristian=20H=C3=B8gsberg?= writes: > Signed-off-by: Kristian Høgsberg <krh@redhat.com> > --- > arch/x86/boot/compressed/misc.c | 30 +++++++++++++++++++++++++++--- > 1 files changed, 27 insertions(+), 3 deletions(-) How is this an improvement? What bug does it fix? Is there any evidence that these messages are harmful for end-users? All this accomplishes is to make early boot failures harder to debug. --

> In other words I do not think it'll help you with the review. I really do prefer to encourage people to include the Doc changes in their submitted patches. It does make it easier to review, and the Doc changes are part of what needs to be reviewed. I will do my best to complete my review, and I will most likely ack this patch, once it is complete. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson ...

Generally you only want to use one of those... Jeff --

I use it in some of my code (but moderately). It's particularly useful for limit checking such as above. It's useful too when you want to use the config value as an offset or a bit shift. Eg: p = malloc(buf_size << (CONFIG_SHIFT-0)); Willy --

Sorry, we already have CONFIG_FOO (meaning =y) and CONFIG_FOO_MODULE (meaning =m). This seems to work well and will generally do the right thing. If we had CFG_FOO=2 for the case of FOO=n then the clean use of: if (CFG_FOO && blah)... -hpa --

I think that would be a massive disadvantage. Furthermore, they *can* (and arguably *should*) still be used for the preprocessor; something like: #if CFG_BLUTTAN ... at least can be configured to warn on a typo. -hpa --

I don't think we want to use "1 or 2"... I suspect we want to use the same booleans we currently have. I would suggest CFG_* instead of CONFIG_* for the new set. -hpa --

You still have the possibility to use the "-0" trick : if (CFG_THINGY_LIMIT && x > (CONFIG_THINGY_LIMIT-0)) {...} Willy --

Oh, that's cute in a vile way. I hadn't seen it before. J --

I think CONFIG_ and CFG_ should be exact parallels, so if CONFIG_FOO is I suppose, but it might be useful to know whether a constant is present: if (CFG_THINGY_LIMIT && x > CONFIG_THINGY_LIMIT) {...} (which fails if CONFIG_THINGY_LIMIT is undefined, so I guess it still doesn't work very well). J --

I, of course, meant: #define CFGVAL_CONFIG_FOO 0 #define CFGVAL_CONFIG_BAR 1 #define CFGVAL_CONFIG_BAZ_MODULE 1 -- Tom Spink --

That can *strongly* be argued with. In particular, the use of #ifdef is crap to begin with. Using #if even for the preprocessor makes it possible to trap misspellings. -hpa --

A quite common pattern in the kernel is: #if defined(CONFIG_FOO) || (defined(CONFIG_FOO_MODULE) && defined(MODULE)) Your suggestion would require them to be changed to: #if (defined(CONFIG_FOO) && !defined(CONFIG_FOO_MODULE)) || (defined(CONFIG_FOO_MODULE) && defined(MODULE)) (We could push these cases to kconfig, but there might also be other cases where changing the existing semantics of CONFIG_FOO could cause breakages.) We see daily in kconfig that mixing tristates with bools is ...

Hi, A thought occurred to me that we may be able to used some preprocessor magic and do this: #define config_defined(x) CFGVAL_## x Which means that, if we get Kconfig to produce: #define CFGVAL_CONFIG_FOO 0 #define CFGVAL_CONFIG_VALUE_BAR 1 #define CFGVAL_CONFIG_VALUE_BAZ_MODULE 1 We can use this: if (config_defined(CONFIG_FOO) && some_expr) { panic("Oh no."); } Thoughts? -- Tom Spink --

That's a very defeatist stance, and quite frankly bogus. Doing it as a flag day event is not really practical, which is why we need a new set of symbols. However, at that point we can discourage continuing use of the CONFIG_ symbols and deprecate them over time. It's not like we're talking about user-space-visible interfaces here! -hpa --

Summary: an OF-specific wrapper around the mmc_spi platform code. I think a wrapper to encapsulate all the OF-specific knowledge makes much sense here. The only thing that looks odd to me about this is that the wrapper is a spi_device rather than an of_device. To me it makes more sense to just have an of_device setting up the right spi_device. (Though maybe I missed some discussion about why that can't work.) Example: drivers/usb/host/sl811_cs.c does that for PCMCIA card that just ...

You mean, "does this node define a bus". If it doesn't, there shouldn't be #a and #s; if it does, the binding should describe what the addressing is. #a = #s = 0 describes a bus without any Yes please. There's a good chance that it doesn't turn out to be Linux-specific at all (after some modification, perhaps). Segher --

Hi Anton, On Fri, 23 May 2008 22:28:42 +0400 Anton Vorontsov <avorontsov@ru.mvista.co= If you delay this assignment, you may not have to clean it up in the Maybe you should do this last so that you don't leak more than necessary if mmc_spi_remove fails. (I don't know what state mmc_spi_remove leaves This is initialised by spi_register_driver(). --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Thanks. Is this a newly-occurring bug or did earlier kernels do this also? If it was newly added, do you know in which kernel version we might have added it? --

Is someone looking into this? It could be somehow connected with commit 1be62dc190ebaca331038962c873e7967de6cc4b where we add smp_mb() to mark_buffer_dirty() under some circumstances. But I don't really see how. The WARN_ON() being triggered is !buffer_uptodate(bh) but that seems ridiculous for call paths like ext2_sync_super() -> mark_buffer_dirty() or journal_destroy() -> journal_update_superblock() -> mark_buffer_dirty() which are in oopses. Also this warning started appearing only recently ...

Note, only the older 2.6.24 and possibly .25 versions of this are my "fault", as those come from the usb core. That's a bug that I thought we fixed, and I can not duplicate it myself at all. Other instances of this are real problems in other areas of the kernel (like the pci hotplug drivers), and are not my fault :) If anyone knows of a way to constantly reproduce this issue with a USB device, please contact me and I'll work to resolve this. Arjan, thanks a lot for these reports, I find ...

On Sun, 25 May 2008 00:23:04 +0200 Ted looked at these during the LF summit, and his conclusion was that they're all media errors (eg USB unplug) that ext3 then did not handle well at all. Maybe Ted has an update on this? the 2.6.24-rc is a red herring btw.. that's just the first kernel version that actually printed its version as part of WARN_ON(). --

It's not that it's not "very useful" - it's that it would be TOTALLY WRONG. If you change the page and the AD bits can change randomly while you do so, that means that the AD bits are now _undefined_. Which of the two pages did it happen to? The old one? The new one? Nobody can know. So you'd effectively have dirty bits that could be associated with the wrong physical page, which means that some page may be dirty, but the kernel would have it marked clean. That would be beyond ...

I explained this a couple of times. The request_firmware() is an abstract mechanism that can request a firmware file. The location of the firmware file is up to the userspace. The kernel requests a particular file and that is it. All namespacing has to be done by the firmware helper script (nowadays udev). That the current implementation of the firmware helper maps the filename 1:1 to a file under /lib/firmware/ just works, but doesn't have to work all the time. It is not the ...

It doesn't seem to have that effect. Whatever I do, on 'make clean' the .o files are removed and the auto-generated .c files remain. Which is probably OK. -- dwmw2 --

strange - like 'make clean' does not vist this directory?? The .o files are deleted using a simple find ... which explain why they are hit. I have not applied your patches but if you d not see issues with it I wil not try to chase it further atm. Sam --

Playing with it now. I fixed the mkdir thing by including $(objtree) in the target. -- dwmw2 --

The architecture parameter is the architecture of the running kernel that implements sys_kexec_load. Because it is a pain for testing and in general impossible we don't change cpu modes during a kexec. So a 32bit caller of sys_kexec_load will need to passing in different code if it is running on a 32bit or a 64bit kernel. The trampoline code in /sbin/kexec does change modes on x86 when appropriate. Caring if you know the architecture in the unload case is a bit silly. As there is no ...

I guess so .. Daniel --

Lock stealing? The usage of sched_setscheduler is fairly pervasive in userspace, if a task becomes SCHED_FIFO it did so via sched_setscheduler. So I don't think this is at all "once a year". Tasks shouldn't be forced to determine if a task is sleeping or not before it There are degree's of overhead with each step.. Someone may not need or You mean the lock ordering would cause the deadlock vs. unqueue_me_pi , or are you talking about something else? Daniel --

And it works this way even after the plist code. May I politely suggest, that you carefully read futex_wake() and the corresponding libc implementation and figure out why there is no guarantee and why there can't be one? Sorry, I'm not abusive. You make claims about correctness and you seem to believe that the plist code gives guarantees except for the setscheduler corner case, but your hypothesis is simply wrong: There is no kernel side controlled handover of a normal futex. The woken ...

After reading futex_wake, Doesn't it depend how many waiters are woken? Given that comes from userspace, glibc could wake a single waiter and If that's the requirement then code that cleans up the corner case that I've identified, which is also minimal should be acceptable .. Since it's meeting the same requirement you layed out above for the original plist changes. Daniel --

Why not just a new sysfs file for the uio device, irq_enabled, or something like that? That way our main read/write path is left alone. thanks, greg k-h --

It makes a certain amount of sense to use write. You hold the device file descriptor anyway for the read (wait for interrupt) operation, so using the same file descriptor is not a too bad idea: while (!stop) { /* wait for interrupt */ read(fd); do_stuff(); /*reenable interrupt */ write(fd); } I thought about using a sysfs entry for a while, but looking at the actual use case made the write() solution a more natural choice. Thanks, tglx --

Simpler implementation, simpler use and future-proofing (in the sense Fair enough :-) symmetry is good. This is pretty much the response I -- Tom Spink --

Oh no. We are not going to open the bottomless pit of ioctls in UIO. Once we have an ioctl channel in place we have the same mess which we want to avoid in the first place. Also when a driver needs more than the obvious interrupt wait / control functions (which are pretty symetric btw.) aside of the mmapped access to the device then it does not belong into the category of an UIO driver. Thanks, tglx --

Hello. I tried to insert a new LSM hook for truncate operation, but I had to insert security_path_truncate() hook into multiple locations since do_truncate() is directly called from some locations. http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/trunk/2.2.x/tomoyo-lsm/patche... Is it possible to replace do_truncate() and file_truncate() with path_truncate() so that security_path_truncate() is called from only ...

It's dropped privileges to help mitigate any security related bug it may contain. It's conceivable (albeit remote[1]) that fork/exec plus That's it. thanks, -chris [1] Get lucky combo in the garbage bits and have not shed uid 0. Much less likely. --

Doh, I missed the leading portion of the pathname (cscope -p3 didn't Hmm, it would be kind of nice to have a formalized way get the size, perhaps it would help with KaiGai's request for caps printed out. Something that tells us either the number of u32s, or the max bit Yes, thanks. But I still think we need to print a warning (unfortunately we can't distinguish libcap from non-libcap app), because apps that aren't using libcap should really be updated (either pull new update from vendor or ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Wright wrote: | * Andrew G. Morgan (morgan@kernel.org) wrote: |> diff --git a/include/linux/capability.h b/include/linux/capability.h |> index f4ea0dd..f88b4db 100644 |> --- a/include/linux/capability.h |> +++ b/include/linux/capability.h |> @@ -34,9 +34,6 @@ struct task_struct; |> #define _LINUX_CAPABILITY_VERSION_2 0x20071026 |> #define _LINUX_CAPABILITY_U32S_2 2 |> |> -#define _LINUX_CAPABILITY_VERSION ...

Heh, you just want me to do all the hard work :) OK, I'll go along: /mnt/a/x is a regular file ln /mnt/a/x /mnt/b/x rename /mnt/a/x /mnt/b/x/p & ln /mnt/b/x /mnt/a/q Neither ->rename nor ->link is required to be defined on x. The rename will first lock x, then a. The link will first lock a then x, AFAICS. This is probably just one of several ways to make it deadlock. Hmm? Miklos --

Well, at least it has been working for years in kernel 2.4 for me with pppd 2.4.2b3 to 2.4.4 (I've not upgraded my firewall to 2.6 yet). So it has definitely been working at some point. Willy --

On Sat, May 24, 2008 at 9:29 PM, Michael S. Tsirkin It looks like also this issue should be fixed by ' mac80211: reorder channel and freq reporting in wext scan report' patch. http://article.gmane.org/gmane.linux.kernel.wireless.general/15177 Please try. Thanks Tomas --

>>> On Fri, May 23, 2008 at 11:02 PM, in message <Pine.LNX.4.58.0805232301080.12686@gandalf.stny.rr.com>, Steven Rostedt Its not that we are saying it doesn't happen. Rather, we are saying the overhead of exiting from the second call (and only remaining call after this patch) is not as significant as it would seem on paper (based on empirical data). In essence, it adds an xchg to the steal-case which is not "great", but.... ..conversely, if the first test fails, the second test will *always* ...

I should have made this more descriptive to eliminate the confusion. Lock stealing, upon entry to *slowlock(), almost never happens. By almost I mean out of ~2+M locks, only 10s of locks were granted from the original redundant attempt. (From manual instrumentation) I do not have exact numbers. Best, --

On Fri, May 23, 2008 at 6:09 PM, Ciaran McCreesh it's weird, you should have 00000 - 9f400: System RAM ===> is not showing up 100000 - d7ff0000: System RAM ===> is not showing up 100000000-11fffffff : System RAM YH --

--MP_/2AlIvHwc55xUh=g1dkRxHpi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 23 May 2008 17:05:34 -0700 I've attached /proc/iomem from current head minus the original patch, with and without pnpacpi=3Doff. Thanks, --=20 Ciaran McCreesh --MP_/2AlIvHwc55xUh=g1dkRxHpi Content-Type: text/plain; name=iomem-normal.txt Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; ...

I would argue 'yes!' g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Okay, I wasn't sure. Will do. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Very good point. Okay, so we cannot assume any correlation between the number of CS lines and the number of child nodes to the SPI bus. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

On Sat, May 24, 2008 at 12:26 AM, Grant Likely I'm having second thoughts about this. I think this code is more SPI centric than it is OF centric. ie. it is usable by all spi masters in an OF enabled system, but it is not usable by all OF devices in an SPI enabled system. Or, in other words; it adds OF support to SPI, not the other way around. I think drivers/spi is the right place for this to live. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Oh, of course the driver needs it! I'm not claiming otherwise. More what I mean is that the driver doesn't need to be loaded or even I do not dispute any of that. My point, however, is that pdata is typically used simply as a representation that is convenient for platform code to pass that data into the driver and that often drivers don't use that representation directly. Instead, the data is explicitly copied explicitly field by field into the driver at probe time and is not touched ...

Hi David, It would have helped to CC stable (fixed) and to give the mainline commit ID since the stable branch only holds already merged patches. Greg, the commit is 6ab455ee... Willy --

Hi Greg Perusing: http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git doesn't show the patch referenced below as in the queue for 2.6.25.5 David --

That is good for ppc. But for x86, things seem to have changed. Previously, one could just do `make ARCH=x86_64` on an i586 installation, now the required magic is a little bit tougher, unless I am missing something (new). --

run it as FV guest. YH --

.. need to do the same thing in arch/x86/lguest.c::lguest_init YH --

I moved reserve_ebda_region() to i386_start_kernel from setup_arch. and reserve_ebda_region will check if (paravirt_enabled()), wonder if that cause problem. but 64bit already did that. YH --

Hm, what kind of graphics adapter is there in your box? Rafael --