The real bug is that we shouldn't have "double negatives", and certainly not negative config options. Making that "promiscuous /dev/mem" option a negated thing as a config option was bad. Ingo, over to you.. --

Add gpio_to_irq() implementation allowing the gpio_chip registration to also specify an function to map GPIO offsets into IRQs. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt3/drivers/gpio/gpiolib.c =================================================================== --- linux-2.6.26-quilt3.orig/drivers/gpio/gpiolib.c 2008-07-18 00:40:52.000000000 +0100 +++ linux-2.6.26-quilt3/drivers/gpio/gpiolib.c 2008-07-18 00:47:03.000000000 +0100 @@ -339,6 +339,36 @@ const char ...

From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] modules: extend initcall_debug functionality to the module loader The kernel has this really nice facility where if you put "initcall_debug" on the kernel commandline, it'll print which function it's going to execute just before calling an initcall, and then after the call completes it will 1) print if it had an error code 2) checks for a few simple bugs (like leaving irqs off) and 3) print how long the init call took in ...

thanks, zapped it. Ingo --

drivers/pci/proc.c:91:3: warning: cast from restricted __le16 drivers/pci/proc.c:100:3: warning: cast from restricted __le32 drivers/pci/proc.c:109:3: warning: cast from restricted __le16 drivers/pci/proc.c:161:40: warning: cast to restricted __le16 drivers/pci/proc.c:170:41: warning: cast to restricted __le32 drivers/pci/proc.c:179:40: warning: cast to restricted __le16 Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- Patch against next-20080717 drivers/pci/proc.c | 18 ...

Hi, for some time I've noticed giving the cmdline (to kernel at boot) "hdd=ide-scsi ..." I get ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device then changing to the suggested "hdd=ide-cd ..." I get ide_setup: hdc=ide-cd -- OBSOLETE OPTION, WILL BE REMOVED SOON! Rather illogical to me :-) I guess neither should be used, I can make my cdrom and dvd devices work without ok. kernel 2.6.26 Tom --

Joe Jin already had another one to move dma32_reserve_bootmem later YH --

The current implementation reports the structure name as VMCOREINFO_OSRELEASE in VMCOREINFO, e.g. VMCOREINFO_OSRELEASE=init_uts_ns.name.release That doesn't make sense because it's always the same. Instead, use the value, e.g. VMCOREINFO_OSRELEASE=2.6.26-rc3 That's also what the 'makedumpfile -g' does. Signed-off-by: Bernhard Walle <bwalle@suse.de> diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 3265968..3c7784d 100644 --- ...

So what makes the 6 meaningless and the 2 meaningful and worth keeping? It does nothing for Linus's dislike of large numbers either. -- Len Sorensen --

hm, but it was not reproducible on the third and fourth attempt :-( I tried hard to provoke it by generating artificial parallel network and netconsole output - but it didnt want to trigger. Heisenbug ... Maybe the debug output gives someone an idea about the nature of the bug? Ingo --

From: Ingo Molnar <mingo@elte.hu> This is very unlikely to be added by us networking folks, no networking merges have happened for the 2.6.27 merge window yet :-) --

and Cc:-ed SLUB folks. Could be a sleeper cell of bugs gone active ;-) Or could be SLUB (-debugging) breakage. Netconsole is pretty reliable on this box. (and the bootup continued just fine after this report) Just re-tried it, the bug is reliably repeatable. Will try a bisection run. Ingo --

It doesn't actually work. The config says # head: 088fcf34 and I checked out this from the tip tree. But kernel-config still complains about unknown config options... What went wrong? Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

From: Ingo Molnar <mingo@elte.hu> This bug would be a quite positive result then :) --

We'll be in The Rideau Suite in Les-Suites Tuesday July 22nd 8:30-18:30. Thanks to HP for sponsoring lunch at 12:30 as well as snacks at 10:00 and 15:30. We'll wing it for dinner. On linux-pm (sorry, on sabbatical I've been bad about keeping up on email) I've seen intent to attend from: Len Brown <len.brown@intel.com> Alan Stern <stern@rowland.harvard.edu> Dipankar Sarma <dipankar@in.ibm.com> Rafael J. Wysocki <rjw@sisk.pl> "Woodruff, Richard" <r-woodruff2@ti.com> Vaidyanathan ...

following warning, In file included from /localuser/dwalker/linus/kernel/sched.c:1675: /localuser/dwalker/linus/kernel/sched_rt.c: In function ‘inc_rt_tasks’: /localuser/dwalker/linus/kernel/sched_rt.c:508: warning: unused variable ‘rq’ looks to be caused by, commit 1100ac91b6af02d8639d518fad5b434b1bf44ed6 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Jun 5 12:25:37 2008 +0200 sched: fix cpuprio build bug this patch was not built on !SMP: kernel/sched_rt.c: In ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- David, akpm? drivers/power/olpc_battery.c | 20 ++++++++------------ 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c index 32570af..5fbca26 100644 --- a/drivers/power/olpc_battery.c +++ b/drivers/power/olpc_battery.c @@ -205,9 +205,9 @@ static int olpc_bat_get_property(struct power_supply *psy, union power_supply_propval *val) { int ret = ...

Quite right. Somehow I managed to test and then send out an earlier version of this patch. Unfortunately, testing the right patch results in my machine locking up. The Intel System Programming Guide, volume 3A points out that x86 interrupts really do have priorities associated with them. And since EOI simply clears the highest priority bit, delaying calling ->ack() just isn't possible. I've also found some other distressing facts about LAPICs in the guide: If more than one ...

Recently released kernel 2.6.26 came with UDF 2.50 support. * http://en.wikipedia.org/wiki/Universal_Disk_Format We should get support for UDF 2.60. Please, add support for it! The Universal Disk Format (UDF) is a format specification of a file system for storing files on optical media. It is an implementation of the ISO/IEC 13346 standard. Revision 2.60 (March 1, 2005). Considering that 2.60 been out since 3 years ago, it is rather bad that we still don't support it. Also the 2.50 ...

Author: Eric W. Biederman <ebiederm@xmission.com> Implement the basic helper function that walks all of the processes in a pid namespace and sends them all a signal. Both locations that could use this functions are also updated to use this function. I use find_ge_pid instead of for_each_process because it has a chance of not touching every process in the system. [daniel@hozac.com: Optimize away nr <= 1 check, against latest Linus tree] Signed-off-by: Eric W. Biederman ...

Was copying files to a vfat filesystem on a usb flash drive from two shells (following http://www.pendrivelinux.com/2008/05/21/usb-xubuntu-804-persistent-install-from-linux/, but doing steps 16 & 18 concurrently) and got a kernel crash; alpha lock and scroll lock (?) flashing. Predictably, nothing in syslogs. Had a USB-attached hard drive plugged in as well as the flash drive, and after reboot they enumerate in opposite order (/dev/sdb <-> /dev/sdc), if that matters, which I expect it doesn't. ...

Register the Amiga-specific video modes with sysfs, so you can see them in /sys/class/graphics/fb0/modes and change the video mode by writing to /sys/class/graphics/fb0/mode. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/amifb.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/video/amifb.c +++ b/drivers/video/amifb.c @@ -2383,6 +2383,9 @@ default_chipset: goto amifb_error; } + fb_videomode_to_modelist(ami_modedb, NUM_TOTAL_MODES, + ...

From: Adrian Bunk <bunk@kernel.org> This patch adds the missing MODULE_LICENSE("GPL"). Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/c2p.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/video/c2p.c +++ b/drivers/video/c2p.c @@ -12,6 +12,7 @@ * for more details. */ +#include <linux/module.h> #include <linux/string.h> #include "c2p.h" @@ -227,3 ...

From: Robert P. J. Day <rpjday@crashcourse.ca> ZORRO: Replace deprecated __initcall with equivalent device_initcall. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/zorro/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/zorro/proc.c +++ b/drivers/zorro/proc.c @@ -158,4 +158,4 @@ static int __init zorro_proc_init(void) return 0; } ...

From: Adrian Bunk <bunk@kernel.org> This patch fixes the following build error: <-- snip --> .. Building modules, stage 2. MODPOST 1203 modules ERROR: "c2p" [drivers/video/amifb.ko] undefined! .. make[2]: *** [__modpost] Error 1 <-- snip --> Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/video/c2p.c | 1 + 1 file changed, 1 insertion(+) --- ...

From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - make the following needlessly global functions (always) static: - atari_mfp_console_write() - atari_scc_console_write() - atari_midi_console_write() - atari_init_mfp_port() - atari_init_scc_port() - atari_init_midi_port() - #if 0 the following unused functions: - atari_mfp_console_wait_key() - atari_scc_console_wait_key() - atari_midi_console_wait_key() - remove the following ...

From: Adrian Bunk <bunk@kernel.org> This patch makes the following needlessly global functions static: - q40_reset() - q40_halt() - q40_disable_irqs() - q40_gettimeoffset() - q40_hwclk() - q40_get_ss() - q40_set_clock_mmss() Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/q40/config.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) --- a/arch/m68k/q40/config.c +++ ...

From: Adrian Bunk <bunk@stusta.de> m68k: remove stale ARCH_SUN4 #define Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- include/asm-m68k/sbus.h | 2 -- 1 file changed, 2 deletions(-) --- a/include/asm-m68k/sbus.h +++ b/include/asm-m68k/sbus.h @@ -12,8 +12,6 @@ struct sbus_dev { } reg_addrs[1]; }; -#define ARCH_SUN4 0 - /* sbus IO functions stolen from include/asm-sparc/io.h for the serial driver */ /* No SBUS on ...

From: Adrian Bunk <bunk@kernel.org> It seems the driver was removed back in kernel 2.3 but the options were forgotten. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/Kconfig | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-) --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -490,28 +490,6 @@ config ATARI_MFPSER Note for Falcon ...

From: Julia Lawall <julia@diku.dk> As noted by Akinobu Mita in patch b1fceac2b9e04d278316b2faddf276015fc06e3b, alloc_bootmem and related functions never return NULL and always return a zeroed region of memory. Thus a NULL test or memset after calls to these functions is unnecessary. This was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; statement S; @@ E = ...

From: Geert Uytterhoeven <geert@linux-m68k.org> On recent kernels, I get the following error when using an initrd: | initrd overwritten (0x00b78000 < 0x07668000) - disabling it. My Amiga 4000 has 12 MiB of RAM at physical address 0x07400000 (virtual 0x00000000). The initrd is located at the end of RAM: 0x00b78000 - 0x00c00000 (virtual). The overwrite test compares the (virtual) initrd location to the (physical) first available memory location, which fails. This patch converts ...

From: Adrian Bunk <bunk@kernel.org> This patch contains the following possible cleanups: - make the following needlessly global code (always) static: - baboon.c: struct baboon - baboon.c: baboon_irq() - config.c: mac_orig_videoaddr - config.c: mac_identify() - config.c: mac_report_hardware() - config.c: mac_debug_console_write() - config.c: mac_sccb_console_write() - config.c: mac_scca_console_write() - config.c: mac_init_scc_port() - oss.c: oss_irq() - oss.c: ...

From: Adrian Bunk <bunk@kernel.org> Unless I miss something that's code for a sparc machine even the sparc code no longer supports that got copied to m68k when these files were copied. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/sun3/prom/console.c | 4 ---- arch/m68k/sun3/prom/init.c | 9 --------- arch/m68k/sun3/prom/printf.c | 5 ----- include/asm-m68k/oplib.h | 1 - 4 files changed, 19 ...

From: Geert Uytterhoeven <geert@linux-m68k.org> Allow no CPU/platform type for allnoconfig - Provide a dummy value for FPSTATESIZE if no CPU type was selected - Provide a dummy value for NR_IRQS if no platform type was selected - Warn the user if no CPU or platform type was selected Note: you still cannot build an allnoconfig kernel, as CONFIG_SWAP=n doesn't build and we cannot easily fix ...

Acked-by: Jeff Garzik <jgarzik@redhat.com> --

From: Adrian Bunk <bunk@kernel.org> This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- arch/m68k/sun3/idprom.c | 2 +- arch/m68k/sun3/prom/Makefile | 1 - arch/m68k/sun3/prom/console.c | 2 +- arch/m68k/sun3/prom/init.c | 2 +- arch/m68k/sun3/prom/misc.c | 2 +- arch/m68k/sun3/prom/printf.c | 2 +- ...

Linux needs btrfs upstream more than it needs ZFS... Jeff --

From what I can see, it is an absolutely-minimal readonly implementation. -hpa --

Why? -- Evgeniy Polyakov --

There are a number of fs drivers in the kernel which provide read-only support. The GPL-ed code might not be much (I haven't looked at it), but if someone would spend some time to write a nice, clean patch which can be easily improved, I think there would be at least one user out there who would find it useful. Of course, this could open a door for all kinds of incomplete drivers, but these days people seem nuts about ZFS. In second thoughts, maybe a fuse based driver would be better. ...

Hi, I got this on latest -git with an intentionally corrupted filesystem image: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink) ------------[ cut here ]------------ kernel BUG at fs/jfs/namei.c:512! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 4408, comm: rm Not tainted (2.6.26-03414-g33af79d #43) EIP: 0060:[<c02df988>] EFLAGS: 00210286 CPU: 1 EIP is at jfs_unlink+0x418/0x430 EAX: 00000031 EBX: 00000000 ECX: f2d16000 EDX: 00000000 ESI: 0000004c EDI: f43b12dc EBP: f2d17f20 ESP: ...

Basically because _stext is an incredibly dangerous symbol; being linker generated it doesn't actually get put in the right place if you look: jejb@sparkweed> nm vmlinux |egrep -w '_stext|_text' ffffffff80209000 T _stext ffffffff80200000 A _text Since we can't do negative offsets, you've lost access to the symbols in the sections that start before _stext. Assuming you meant _text (which is dangerous because it's a define in the kernel linker script and could change). Then you can't ...

Hi Frank, I know we'd better archive that requirement. However, if we lose support from developers because we are too much focusing on that, we'll also lose the future of systemtap itself. We have to see the cost/benefit from the long-term of view. Could we separate systemtap parser/elaborator and code generator to support both of old and new kernels? Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: ...

Can you explain in detail how you believe this is materially different from offsetting from _stext? - FChE --

a crude way to tell it maybe.... http://groups.google.com/group/comp.lang.c/msg/073812010e0516a4 --

Clean up a few more minor nits in the prng Now that we use a plain cipher instead of a blkcipher, we don't need an iv anymore, so remove that parameter from the reset_prng_context function. Make it instead with a legngth parameter, so that we can treat the key as a blob, rather than a string. Also change the get_prng_bytes function to make nbytes a size_t, so we don't have to worry about signed math there Signed-off-by: Neil Horman <nhorman@tuxdriver.com> prng.c | 11 ...

Improve the accuracy of TIOCOUTQ value as implemented in chars_in_buffer() method by walking and counting tx DMA buffers, reading controller tx FIFO level and accounting for controller tx shift register. The greatly improves application control of transmit latency at lower data rates. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 08:39:06.000000000 -0500 +++ b/drivers/char/synclink_gt.c 2008-07-17 12:14:22.000000000 -0500 @@ -214,6 +214,7 @@ ...

There is no good reason to immediately open the lower file, and that can cause problems with files that the user does not intend to immediately open, such as device nodes. This patch removes the persistent file open from the interpose step and pushes that to the locations where eCryptfs really does need the lower persistent file, such as just before reading or writing the metadata stored in the lower file header. Two functions are jumping to out_dput when they should just be jumping to out ...

Add control of hardware serial bit order between LSB first (default/standard) and MSB first. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/include/linux/synclink.h 2008-07-17 11:45:48.000000000 -0500 +++ b/include/linux/synclink.h 2008-07-17 11:46:52.000000000 -0500 @@ -136,6 +136,7 @@ #define MGSL_INTERFACE_RTS_EN 0x10 #define MGSL_INTERFACE_LL 0x20 #define MGSL_INTERFACE_RL 0x40 +#define MGSL_INTERFACE_MSB_FIRST 0x80 typedef struct _MGSL_PARAMS { --- ...

Linus, Pull this to get the revert and the PTR_ERR() version: git://oss.oracle.com/git/jlbec/linux-2.6.git configfs-fixup-ptr-error It's tested with the same testing I did before - ocfs2 and netconsole. Joel -- "But all my words come back to me In shades of mediocrity. Like emptiness in harmony I need someone to comfort me." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --

See, I coded it up with PTR_ERR() first, and everyone I showed I wish you hadn't, because it won't be to difficult to go back to PTR_ERR(). However, don't revert it - that affects some of the follow-on patches that were affected by the change. I'll spin up a new PTR_ERR() change. I have some more cleanups coming too, they need to finish their time in linux-next. Joel -- "The cynics are right nine times out of ten." - H. L. Mencken Joel Becker Principal Software ...

Hi, I got this with an intentionally corrupted filesystem: Filesystem "loop1": Disabling barriers, not supported by the underlying device XFS mounting filesystem loop1 Ending clean XFS mount for filesystem: loop1 Device loop1 - bad inode magic/vsn daddr 9680 #30 (magic=4946) ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:54! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 12849, comm: grep Not tainted (2.6.26-03414-g33af79d #43) EIP: 0060:[<c0386d89>] ...

FWIW, this is fs/xfs/xfs_alloc.c:1817: if (!pag->pagf_init) { Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Which kind of implies that we've got a bogus fsbno that we're using as the basis of allocation..... What is the corruption you are inducing? Can you produce a xfs_metadump image of the filesystem and put it up somewhere that we can access it? I suspect that we are not validating the block numbers coming out of the various btrees as landing inside the filesystem.... Cheers, Dave. -- Dave Chinner david@fromorbit.com --

Add run time control for receive DMA buffer fill level to allow application to control receive latency when using stream oriented serial protocols that pass receive data to application only after a DMA buffer fills. This was previously a compile time option, but run time control is needed when application changes data rate (and latency requirements) or uses different data rates on different ports. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 ...

Linus, Please pull the latest tracing fixes git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tracing-fixes-for-linus Thanks, Ingo ------------------> Ingo Molnar (4): ftrace: fix merge buglet ftrace: fix lockup with MAXSMP ftrace: do not trace scheduler functions ftrace: do not trace library functions arch/x86/kernel/Makefile | 3 +-- kernel/Makefile | 3 +-- lib/Makefile | 14 ...

Indeed. I do not even understand why it was done that way in the I agree... Maybe someone with stronger guts than mine will have read about it and will correct it for some next release. Thanks once again, Loïc --

Server with Intel SHG2 board, servervorks CSB5 rev. 93: After upgrade from kernel 2.6.22 (IDE serverworks driver) to 2.6.25 (Fedora 9: libata+pata_serverworks driver), SW RAID1 performance is very bad. Problem is probably with secondary IDE channel, which has disabled DMA: # hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 828 MB in 2.00 seconds = 414.26 MB/sec Timing buffered disk reads: 210 MB in 3.01 seconds = 69.83 MB/sec # hdparm -Tt /dev/sdb /dev/sdb: Timing cached ...

Attn: We are please to inform You won the sum of £750,000.00 GBP and BMW 5 Series Car in our Seasonal E-mail Programme Award.Fill the details:Full Name,Country,Tel,Sex,Occupation Contact(bmw_claimsunit@btinternet.com)for claims Regards --

Believe it or not, we really do understand this sentiment. The whole runtime/time.c in particular is a fairly ugly way for us to get a call-anywhere gettimeofday. I would love to see an in-kernel replacement for this, but I don't have the expertise to know how to approach it myself. Josh --

In kernel 2.6.26, this patch commit 15c8b6c1aaaf1c4edd67e2f02e4d8e1bd1a51c0d Author: Jens Axboe <jens.axboe@oracle.com> Date: Fri May 9 09:39:44 2008 +0200 on_each_cpu(): kill unused 'retry' parameter means that runtime/time.c is now using the wrong calling conventions. Fix this up and surround it by kernel versioning #ifdefs. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- runtime/time.c | 5 +++++ 1 files changed, 5 insertions(+), 0 ...

Fix calls of smp_call_function*() in arch/ia64/kvm for recent API changes. CC [M] arch/ia64/kvm/kvm-ia64.o arch/ia64/kvm/kvm-ia64.c: In function 'handle_global_purge': arch/ia64/kvm/kvm-ia64.c:398: error: too many arguments to function 'smp_call_function_single' arch/ia64/kvm/kvm-ia64.c: In function 'kvm_vcpu_kick': arch/ia64/kvm/kvm-ia64.c:1696: error: too many arguments to function 'smp_call_function_single' Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by Xiantao Zhang ...

Hi, Here is a port of KVM-trace, currently using macros on top of the Linux Markers, to tracepoints. Note that I cleaned up the instrumentation too, so stuff like KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr, (u32)kvm_register_read(vcpu, reg), (u32)((u64)kvm_register_read(vcpu, reg) >> 32), handler); Sprinkled all across the KVM C code becomes : trace_kvm_cr_write(vcpu, cr, reg); Which looks much nicer, IMHO. It applies on top of linux-next ...

Hi Mathieu, It's difficult to review your patches because they aren't inlined. At any rate, this patches are unusable with SVM. They try to execute VT Which lived in VT-specific code (vmx.c) Which lives in common code (kvm_trace.c). But vmcs_read32() is VT-specific and should not be used in common code so this motion is wrong. Why not just pass more arguments to probe_kvm_intr()? Then your first two patches can be dropped completely. Regards, Anthony Liguori Mathieu ...

Is it a specific property of KVM-trace that causes this LOC blow-up? Or is this a generic side-effect of tracepoints? [ Hmm, hope I didn't missed too much of the tracepoint discussion... ] Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux --

Port/cleanup of KVM-trace to tracepoints. Tracepoints allow dormat instrumentation, like the kernel markers, but also allows to describe the trace points in global headers so they can be easily managed. They also do not use format strings. Anything that would involve an action (dereference a pointer, vmcs read, ...) only required when tracing is placed in the probes created in kvm_trace.c This patch depends on the "Tracepoints" patch. Signed-off-by: Mathieu Desnoyers ...

Hi Linus, please pull from 'for-linus' branch of git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus Besides a couple of small bugfixes this contains our rewritten qdio driver. This should be the last large s390 patch for this merge window. Thanks. Adrian Bunk (1): [S390] chsc headers userspace cleanup Cornelia Huck (2): [S390] dasd: Fix cleanup in dasd_{fba,diag}_check_characteristics(). [S390] cio: Export chsc_error_from_response(). Frank Munzert ...

IIRC, this happens for other syscalls as well. IIRC, timerfd ones. --

On Fri, 18 Jul 2008 01:29:39 +0400 Well it _did_ do this. But I fixed about four such build errors. Please check? --

This one crashes all of my x86-64 test boxes early during boot. The Linus' tree is not affected. Failing configs: http://www.sisk.pl/kernel/debug/next/20080717/HPC_nx6325-config http://www.sisk.pl/kernel/debug/next/20080717/M3A32-MVP-config It's not very likely that I'll be able to bisect this issue before OLS, so most probably I won't be testing linux-next in the next several days. Thanks, Rafael --

Who is making patches to kernel/sysctl.c ? With CONFIG_SYSCTL=y # CONFIG_SYSCTL_SYSCALL is not set linux-next-20080717 produces: linux-next-20080717/kernel/sysctl.c:2970: error: redefinition of 'setup_sysctl_set' linux-next-20080717/kernel/sysctl.c:1963: error: previous definition of 'setup_sysctl_set' was here because one definition of it is bounded by CONFIG_SYSCTL and another definition of it is bounded by CONFIG_SYSCTL_SYSCALL... :( --- ~Randy Linux Plumbers Conference, ...

Hi Ohta, Thanks for the patches. If I'm not mistaken there are several variants of this card: without upd* devices, only with upd64083 and with both upd devices. Which one do you have? Can you also show the dmesg output when ivtv loads? Looking at the four patches, I would say that the only relevant patch is the fix-probing patch. If you try it with only that one applied, does it still work correct for you? Note that this patch will not work with a KUROTOSIKOU card that has no upd* ...

Sorry that was a half truth. Outside of the context of pid namespaces it is true. In the context of pid namespaces it is false because we haven't merged the patches to drop signals from inside the pid namespace on the way to init. So it is a check that _should_ be redundant. Eric --

We should just drop the check for init as it is redundant. Eric --

ns is from current, and this is currently only called from See my response to Eric. I think that patch looks good... (Well, nr could -- Daniel Hokka Zakrisson --

I knew I had done something like that. Sure let's revive the patch and send it. I don't know why it got lost the first time. Eric --

This is to be done, indeed, but I do not like the proposed implementation, since you have to walk all the tasks in the system (under tasklist_lock, by the way) to search for a couple of interesting ones. Better look at how zap_pid_ns_processes works (by the way - I saw some patch doing so some --

While moving Linux-VServer to using pid namespaces, I noticed that kill(-1) from inside a pid namespace is currently signalling every process in the entire system, including processes that are otherwise unreachable from the current process. This patch fixes it by making sure that only processes which are in the same pid namespace as current get signalled. Signed-off-by: Daniel Hokka Zakrisson <daniel@hozac.com> diff --git a/include/linux/pid_namespace.h ...

Looks like you've already done that. :-) (Referring to Sukadev's email.) -- Daniel Hokka Zakrisson --

Eric --

Leave the transmitter in reset state after configuration so that transmit signal is held at mark until transmitter is explicitly enabled by application, otherwise transmitter sends idle pattern. Signed-off-by: Paul Fulghum <paulkf@microgate.com> --- a/drivers/char/synclink_gt.c 2008-07-17 08:39:06.000000000 -0500 +++ b/drivers/char/synclink_gt.c 2008-07-17 09:05:24.000000000 -0500 @@ -4157,7 +4157,7 @@ static void sync_mode(struct slgt_info * * 01 enable * 00 auto-CTS ...

Here's a ruby script that when run on 2.6.25 demonstrates that although the contents of /proc/self/maps changes, its mtime doesn't. --- start ruby script --- #!/usr/bin/ruby -w mapfile = "/proc/self/maps" oldmtime = File.stat(mapfile).mtime oldmaps = File.read(mapfile) arr = Array.new() for k in 1...10*1024*1024 arr.push(k) end newmaps = File.read(mapfile) newmtime = File.stat(mapfile).mtime if (oldmaps != newmaps) if (oldmtime == newmtime) puts("oldmaps ...

It does depend on the previous patch to fix the section mismatch reports. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

Ensure that the s3cmci host controller is turned off when the machine is shutdown, otherwise we end up leaving the card powered and processing insertion and removal events after the system prints "System halted." Signed-off-by: Ben Dooks <ben-linux@fluff.org> Index: linux-2.6.26-quilt3/drivers/mmc/host/s3cmci.c =================================================================== --- linux-2.6.26-quilt3.orig/drivers/mmc/host/s3cmci.c 2008-07-17 15:15:35.000000000 +0100 +++ ...

Hi all, at the moment blinking is not supported in fbcon but it is supported in vgacon. Since userspace applications don't distinguish between the two, they just assume that the linux terminal is always capable of blinking text. However implementing blinking in fbcon is not so difficult: this patch provides a very simple (too simple?) implementation of that. I am using the flashcursor function to scan the buffer for blinking text. For the sake of efficiency I added a simple flag mechanism to ...

On Thu, 17 Jul 2008 16:45:11 +0300 Applied, thanks a lot. Shame on me for not testing all defconfigs before submitting. Haavard --

Hi Octavian. Existing behaviour was selected to be able to have a progress if socket does not have enough data to fill the pipe. With your change if socket is not opened with non-blocking mode reading will block not matter if SPLICE_F_NONBLOCK is set or not. This is a quite serious break of the overall idea behind SPLICE_F_NONBLOCK. Socket will not be marked as non-blocking if SPLICE_F_NONBLOCK is specified, only splicing will used non-blocking reading, any read via recv() will use ...

You lost me here :) The way I interpret the man page text is that it is ok for splice to block, even if SPLICE_F_NONBLOCK is set. The comments near SPLICE_F_NONBLOCK says the same thing: #define SPLICE_F_NONBLOCK (0x02) /* don't block on the pipe splicing (but */ /* we may still block on the fd we splice */ /* from/to, of course */ For this "program": x=splice(socket, pipe, size, flags=0); if (x > 0) splice(pipe, ...

Hi, Any objections to the following patch? If not I'll send it on to Linus. This patch adds a "const" to the parser token table. I've done an allmodconfig build to see if this produces any warnings/failures and the patch includes a fix for the only warning that was produced. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Cc: Alexander Viro <aviro@redhat.com> Cc: Evgeniy Dushistov <dushistov@mail.ru> diff --git a/fs/ufs/super.c b/fs/ufs/super.c index 85b22b5..506f724 ...

Yeah thats a hard to answer question, one that I will leave up to others who have been doing this much longer than I. My thought is remount-ro is there to keep you from crashing, so if you have errors=continue then you expect to live with the consequences. Course if that bit gets flipped via corruption thats not good either. Thanks, Josef --

Oh, just 2M. It doesn't contain anything but copies of /bin/bash. I basically just made a crash-tester script that corrupts a dummy filesystem on purpose. But it seems that it might be partly my own fault for not protecting the bits in the filesystem image that say "oh, proceed on error". But I do have a feeling that the filesystem should not be able to say this in the first place. Because those bits can be corrupted legitimately in other ways ...

Yep: tune2fs -e remount-ro /dev/XXXX I should probably make the default configurable, and not "continue".... - Ted --

Well this is really odd, after that we call ext3_std_error which calls journal_abort, so when we come into journal_dirty_metadata is_handle_aborted() should have returned 1 and we should have just exited. I'm going to have to think on this for a bit. Josef --

Nope, seems to be the same problem: kjournald starting. Commit interval 5 seconds EXT3-fs warning: mounting fs with errors, running e2fsck is recommended EXT3 FS on loop0, internal journal EXT3-fs: mounted filesystem with ordered data mode. EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks in system zones - Block = 16, count = 1 EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks in system zones - Block = 32, count = 1 EXT3-fs error (device loop0): ext3_free_blocks: ...

Yes, it has been that way on Debian for many years... I was going to say the same thing, but you beat me to it. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --

-ENOLUCK EXT3-fs error (device loop0): ext3_free_blocks: Freeing blocks not in datazone - block = 524288, count = 1 EXT3-fs error (device loop0) in ext3_free_blocks_sb: IO failure BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c01fd200>] journal_dirty_metadata+0xa0/0x160 It did seem to get further, though. http://folk.uio.no/vegardno/linux/log-1216306142.txt Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer ...

Hi, I get this with both clean v2.6.26 and latest -git (33af79d12e0fa25545d49e86afc67ea8ad5f2f40): BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c01fd1e0>] journal_dirty_metadata+0xa0/0x160 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 4935, comm: rm Not tainted (2.6.26-03414-g33af79d #39) EIP: 0060:[<c01fd1e0>] EFLAGS: 00210246 CPU: 1 EIP is at journal_dirty_metadata+0xa0/0x160 EAX: 00000000 EBX: cca59160 ECX: 00000001 EDX: f5114000 ESI: ...

Vegard, How big is the filesystem? Is there any chance you can make a compressed e2image of the file? (This will not include file contents, but does reveal the names of the file.) Given the nature of the bug which you are reporting, it should be safe to scramble the names of the filenames using the -s option if that would make you feel more comfortable. The quick version is: e2image -r /dev/loop0 | bzip2 > badfs.e2i.bz2 Then folks like Josef would be able to test your filesystem ...

No, this is the command I used: mount -o loop disk mnt I think this looks interesting: EXT3-fs error (device loop0) in ext3_reserve_inode_write: IO failure The code in ext3_reserve_inode_write() is here: err = ext3_journal_get_write_access(handle, iloc->bh); if (err) { brelse(iloc->bh); iloc->bh = NULL; } Maybe it should do something different here? But I don't know :-) Thanks for helping out! Vegard -- ...

On Thu, 17 Jul 2008 13:21:55 +0200 Good catch. Looks reasonable to me... ACK -- Jeff Layton <jlayton@redhat.com> --

What about how porsch does it i.g. 911, 912, 913, 914 -- Justin P. Mattock --

How about making it an inline function to avoid the horrible -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

From: Ville Syrjala <syrjala@sci.fi> Reset the controller after each transfer since we're violating the spec sometimes. This is very cheap, so we don't try to be clever. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- Comment stolen from atmel_mci log. We noticed that AT91SAM9260 board + Marvell 8686 SDIO WLAN adater are not happy without applying the MCI reset trick. drivers/mmc/host/at91_mci.c | 5 ++--- 1 files changed, 2 ...

On Thu, 17 Jul 2008 11:34:07 +0200 Not all SDIO cards use 4-bit mode, so it looks to me like you have to disable it completely (unless there's a third revision where it works without any fine print?). Rgds --=20 -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

From: Mariusz Kozlowski <m.kozlowski@tuxland.pl> And these are all entirely superfluous, since they are already defined in linux/ethtool.h --

Mariusz --

The use of module parameters to set options is discouraged, especially when there are better choices. All these parameter should be controllable by ethtool. The reason is that users (and tools) shouldn't have to know the special parameters that are specific to that hardware. This version is okay as is for initial inclusion, but the parameters should be removed later. --

Does it have the same 4G limitation as ATL1 card? If yes, pci_using_64 logic isn't needed, and copying comment from atl1 driver wouldn't hurt, If no, you're setting small DMA mask. --

-stable usually overlaps with master. But I don't like version numbers long as binutils and "2.8.30.9.01" have. (BTW, IMHO it needs more than just a BKL removal to warrant a jump to 3.x) --

------- Blind-Carbon-Copy to: null@berklix.org Subject: Re: GPL version 4 From: "Julian Stacey" <jhs@berklix.com> Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Thu, 17 Jul 2008 04:12:50 +0200." <1216260770.10312.21.camel@localhost> Date: Thu, 17 Jul 2008 10:31:07 +0200 Sender: jhs@fire.js.berklix.net Please all, do Not massively cross post this flame ...

If we all agree on this, I'll send a new patch to fix this. --

I think 1) is correct way. There was a special short path for the top_cpuset's case, but now it is disappeared. I think there are no need to treat the top_cpuset as VIP, so 2) is excessive nurturing. Thanks, H.Seto --

This code has gotten too complicated for my modest brain ;). Question: In the case that the top_cpuset's sched_load_balance is -not- set, is there code already present that sets the sched_relax_domain_level in overlapping cpusets to the largest value in any of the overlapping cpusets? If so, where is that code? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> ...

The x86 arch code has all the prerequisites, so set HAVE_ARCH_TRACEHOOK. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 96e0c2e..dab1735 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -27,6 +27,7 @@ config X86 select HAVE_FTRACE select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64) select HAVE_ARCH_KGDB if ...

This changes x86 syscall tracing to use the new tracehook.h entry points. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace.c | 34 ++++++---------------------------- 1 files changed, 6 insertions(+), 28 deletions(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index e37dccc..19a7d2c 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -14,6 +14,7 @@ #include <linux/errno.h> #include ...

This adds TIF_NOTIFY_RESUME support for x86, both 64-bit and 32-bit. When set, we call tracehook_notify_resume() on the way to user mode. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/signal_32.c | 5 +++++ arch/x86/kernel/signal_64.c | 5 +++++ include/asm-x86/thread_info.h | 4 +++- 3 files changed, 13 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index 3ffb88f..c17c0cb 100644 --- ...

This moves the PTRACE_EVENT_EXIT tracing into a tracehook.h inline, tracehook_report_exec(). The change has no effect, just clean-up. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 15 +++++++++++++++ kernel/exit.c | 6 ++---- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 6276353..967ab47 100644 --- a/include/linux/tracehook.h +++ ...

This moves the PTRACE_EVENT_VFORK_DONE tracing into a tracehook.h inline, tracehook_report_vfork_done(). The change has no effect, just clean-up. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 18 ++++++++++++++++++ kernel/fork.c | 5 +---- 2 files changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 3ebc58b..830e6e1 100644 --- a/include/linux/tracehook.h +++ ...

This moves all the ptrace initialization and tracing logic for task creation into tracehook.h and ptrace.h inlines. It reorganizes the code slightly, but should not change any behavior. There are four tracehook entry points, at each important stage of task creation. This keeps the interface from the core fork.c code fairly clean, while supporting the complex setup required for ptrace or something like it. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/ptrace.h | ...

This adds the new function task_current_syscall() on machines where the asm/syscall.h interface is supported (CONFIG_HAVE_ARCH_TRACEHOOK). It's exported for modules to use in the future. This function safely samples the state of a blocked thread to collect what system call it is blocked in, and the six system call argument registers. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/ptrace.h | 4 ++ lib/Makefile | 2 + lib/syscall.c | 75 ...

ptrace(2) will start calling utrace_* hooks and functions. These tracehooks are generic and utrace is generic as well. --

This defines tracehook_signal_handler() as a hook for the arch signal handling code to call. It gives ptrace the opportunity to stop for a pseudo-single-step trap immediately after signal handler setup is done. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index e113e09..2d1426f 100644 --- ...

Even then I don't think it's a good idea. This one should only be touched in very very few places --

This extends wait_task_inactive() with a new argument so it can be used in a "soft" mode where it will check for the task changing state unexpectedly and back off. There is no change to existing callers. This lays the groundwork to allow robust, noninvasive tracing that can try to sample a blocked thread but back off safely if it wakes up. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/ia64/kernel/perfmon.c | 4 ++-- include/linux/sched.h | 8 ++++++-- ...

This adds tracehook_expect_breakpoints() as a formal hook for the nommu code to use for its, "Is text-poking likely?" check at mmap time. This names the actual semantics the code means to test, and documents it. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 15 +++++++++++++++ mm/nommu.c | 4 ++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index ...

My gut feeling this code needs ptrace_may_access() checks. --

This moves the ptrace logic in task death (exit_notify) into tracehook.h inlines. Some code is rearranged slightly to make things nicer. There is no change, only cleanup. There is one hook called with the tasklist_lock write-locked, as ptrace needs. There is also a new hook called after exit_state changes and without locks. This is a better place for tracing work to be in the future, since it doesn't delay the whole system with locking. Signed-off-by: Roland McGrath ...

This adds asm-generic/syscall.h, which documents what a real asm-ARCH/syscall.h file should define. This is not used yet, but will provide all the machine-dependent details of examining a user system call about to begin, in progress, or just ended. Each arch should add an asm-ARCH/syscall.h that defines all the entry points documented in asm-generic/syscall.h, as short inlines if possible. This lets us write new tracing code that understands user system call registers, without any new ...

This adds standard tracehook.h inlines for arch code to call when TIF_SYSCALL_TRACE has been set. This replaces having each arch implement the ptrace guts for its syscall tracing support. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 70 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 70 insertions(+), 0 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 8b4c15e..3548694 100644 --- ...

All the arch considerations are opt-in, and mostly quite simple. I have arch patches for review by a few arch maintainers who I don't think will mind too much. All others can look into it at their leisure and expect not to get broken. Thanks, Roland --

Looks sane to me from a quick scan. A ~200 byte increase in i386 allnoconfig .text is liveable with. But nothing defines CONFIG_HAVE_ARCH_TRACEHOOK yet. What effect will that have? I don't like the name! We have ftrace and we have static tracepoints and we have dynamic tracepoints and we have linux trace toolkit and whatever is in kernel/trace/trace.c etc, etc. Now this work comes along with _userspace_ tracing capabilities and it goes and calls it, of all things, "trace"! Things ...

This defines the tracehook_notify_jctl() hook to formalize the ptrace effects on the job control notifications. There is no change, only cleanup. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/tracehook.h | 20 ++++++++++++++++++++ kernel/signal.c | 10 +++++----- 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 42a0d7b..6dc428d 100644 --- a/include/linux/tracehook.h +++ ...

This moves all the ptrace hooks related to exec into tracehook.h inlines. This also lifts the calls for tracing out of the binfmt load_binary hooks into search_binary_handler() after it calls into the binfmt module. This change has no effect, since all the binfmt modules' load_binary functions did the call at the end on success, and now search_binary_handler() does it immediately after return if successful. We consolidate the repeated code, and binfmt modules no longer need to import ...

Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> --

This reverts the effect of commit f2cc3eb133baa2e9dc8efd40f417106b2ee520f3 "do_wait: fix security checks". That change reverted the effect of commit 73243284463a761e04d69d22c7516b2be7de096c. The rationale for the original commit still stands. The inconsistent treatment of children hidden by ptrace was an unintended omission in the original change and in no way invalidates its purpose. This makes do_wait return the error returned by security_task_wait() (usually -EACCES) in place of -ECHILD ...

I posted an earlier version of this patch series before, and I believe this has fixed the quibbles there were with it before. These changes pave the way for cleaning up ptrace a lot more in the future. This series is a prerequisite for the following "tracehook" series, but only because of patch conflicts. They can be reviewed separately. This series of patches is also available in GIT at the URL below, and in a mail folder of patch messages (use git-am or formail -s patch -p1) ...

Yes. After this settles, it will become tractable to change the whole locking plan for ptrace so we don't have this problem and get rid of this kludge altogether. Thanks, Roland --

On Thu, Jul 17, 2008 at 10:50 AM, Benjamin Herrenschmidt Oh come on, don't scare the guy more than he is - now he'll be staring frantically at each +-diff line before submitting :). And it's not like it's the end of the world, it's just that Fred has turned 42 or similar :) P.S. If I only knew how such an innocent thing would destroy a man's life i never would've reported it in the first place :). Sorry Grant. -- Regards/Gruß, Boris --

From: Grant Likely <grant.likely@secretlab.ca> The patch named "powerpc/mpc5121: Add clock driver", also contained an unrelated and bogus change to the top-level makefile. This patch backs out the bad bit. SHA1 of offending patch: 137e95906e294913fab02162e8a1948ade49acb5) Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- If the maintainer who picked up this patch (Grant Likely) had done his job, this cack-up never would have happened. Why do we still have to deal with such ...

Heh, oh please, I've got a thicker skin that that. I appreciate the error being pointed out. But Ben's right. That mistake will not happen again! :-) Cheers, g. --

Agreed, although I would have used [PATCH] modpost: fix duplicate markers entries --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

whoa, what's all that about? Patches can only have one Author: in git, and we indicate that in emails by putting a From: line right at the top of the changelog. (Additional credits can and should be mentioned in the changelog text of course). When that From: line is missing we take the authorship info from the email headers. So according to the above, this patch has three authors. Geeze, even I can type faster than that! --

Yes, it's needed in 2.6.26.x and 2.6.25, but I doubt it is critical : only needed for systemtap users which use markers and rebuild their I took the diffs Roland and Wenji sent in separate emails and created this patch. They are the ones who actually identified the solution. So I guess I should be the author, with credits to them, if they are ok with that. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

On Thu, Jul 17, 2008 at 12:35 AM, Borislav Petkov Oh crap Yeah, I'll fix that right now. Sorry. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Thank you for the report. Please could you confirm that this fixes it for you? ---- Subject: Update scripts/Makefile.fwinst to cope with older make Also fix unwanted rebuilds of the firmware/ihex2fw tool by including the .ihex2fw.cmd file when present. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 3d2f460..92305a3 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -28,18 +28,39 @@ ...

compile, build, reboot. all ok. It fixed my problem. Thank you. --

Port blktrace to the tracepoint infrastructure. It's just like markers, but without the format strings. Type checking of probes and call sites is done at probe registration. A reference count of blktrace users is kept. As soon as it is higher than 0, the probes are connected, which means that the branch is activated to enable the function calls and that the function addresses are added to the list of function to call for these tracepoints. By the way, I think something is silly with the current ...

I have not seen this, but looks good to me Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

LTTng 0.11 is released, which contains this bugfix. http://ltt.polymtl.ca/lttng/patch-2.6.26-0.11.tar.bz2 Mathieu -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 --

I'm not sure how else to express what I already said above: They simply need to get (in ACPI spec terms) the FADT's X_PM1a_EVT_BLK in sync with PM1_EVT_LEN (and they should at once make sure other X_PM*_BLK and X_GPE?_BLK fields are in sync with their respective legacy fields, too - while looking at the dump, it seemed there were more inconsistencies). Jan --

So does the BIOS owner need to fix the table? If you could give me the exact text to pass along to the mobo mfr, I will forward it and I can get them to release a new BIOS rev. Thanks, -Andrew --

So it's a firmware bug in the system you saw this on. The specification is clear about the width being at least 16 bits, and the warning was added to indicate the problem you now got: Dividing 8 by 16 yields zero for pm1_register_length, which results in acpi_gbl_xpm1a_enable aliasing the address of the respective status register. That won't work, hence the warning. I'd be hesitant to fix this (as I think we should be allowed to expect ACPI tables to not be that fundamentally flawed these ...

Yes that makes sense. Jan could you revise the patch to do that please? Thanks, -Andi --

I just saw this for the first time using a kernel built from the git head. This is all the ACPI related printk info around the warning. If more information is needed to figure out what this is, please let me know. [ 0.000000] ACPI: RSDP 000F7CE0, 0024 (r2 RS690 ) [ 0.000000] ACPI: XSDT 3DFE30C0, 004C (r1 RS690 AWRDACPI 42302E31 AWRD 0) [ 0.000000] ACPI: FACP 3DFE7400, 00F4 (r3 RS690 AWRDACPI 42302E31 AWRD 0) [ 0.000000] ------------[ cut here ]------------ [ 0.000000] ...

"Andrew Paprocki" <andrew@ishiboo.com> writes: I'll queue a revert for now until this can be resolved properly. -Andi --

What would lspci have to do with this? /proc/acpi/fadt (from an older kernel if the new one fails to come up) would seem to help somewhat, as that would allow comparing the v1 (byte-width) and v2 (bit-width) values - if they're out of sync (and they likely are if the system worked flawlessly with previous kernels), I'd be certain the tables are wrong. Jan --

In the rcu update side, don't use list_for_each_entry_rcu(). Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 8a59aaa..987f3c3 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -986,7 +986,7 @@ int ipmi_destroy_user(ipmi_user_t user) * synchronize_rcu()) ...

Hi During examination of stack-overflows on sparc64, it was found that there is no limit for a number of nested IRQ handlers. Sparc64 is especially stack-hungry architecture, minimum frame size is 192 bytes and after 75 frames it overflows. If someone provides a legitimate reason for more than 2 nested handlers, you could increase the constant in the patch --- but there really should be some limit, so that many simultaneous interrupts can't blow the stack. Mikulas --- IRQs ...

I assume that there is at most one active bad-behaving device with long interrupt processing time. For example IDE disk in PIO mode. If someone starts whining that he is simultaneously using two disks in PIO mode and is losing characters on serial line, we can make an architecture override for this (after we check that the architecture has enough stack space to hold more interrupts). But PIO mode is dead anyway, so there's no need to preemptively care about it. Mikulas --

Yes, your SELinux config is hosed. But I'll agree that we should just pass over the LSM options in that case (since clearly there aren't any) and not fail the read altogether. Patch will be forthcoming. -Eric --

O.K. I tried MMCONFIG and it seems to be giving me a: kernel panic VFS: cannot open device sda1 or unkown block (0,0) from what I remember I noticed this as far back as 2.6.22 -- Justin P. Mattock --

ok, please out lspci -vvxxx under 2.6.25.10 YH --

YH, Okay, I can confirm that 2.6.25.10 boots okay with pci=nommconf which does disable MMCONFIG. It also works fine by default with MMCONFIG enabled. So there may be two possibly unrelated problems in 2.6.26. The first being that MMCONFIG doesn't start up properly without your patch and the second being that with or without MMCONFIG, the boot process hangs just before when the line... PCI: Transparent bridge - 0000:00:1e.0 should appear. Jack --

YH, I am wondering if it might be worthwhile for me to try the various rc releases of 2.6.26 (starting with rc1-git1) to see if I can identify at what point 2.6.26 was broken with regards to booting on my MacBook Pro? In case that would point us towards the checkin of a specific set of patches as the problem. Jack --

No I have not tried the .iso yet. I am more concerned with the PCI option i.g. I'm using Direct, if I change to MMCONFIG will it cause this same bug? right now I'm occupied with drinking at the moment, but tomorrow I am curious as to see if this occurs. keep in mind if I'm going to have to deal with having a stuck system this means I need to use a live cd to recover the system, the problem is SELinux why: chrooting into the hardive and then compiling is going to kind of mess my policy a ...

try 2.6.26-rc1,..rc2 YH --

please boot with debug initcall_debug apic=verbose pci=routeirq? and try pci=nommconf I suspect that could be pci bridge is using 0xf0000000-0xf400000 too after Linus merge pci tree, please try to boot with pci=early_config_dump to see if it is true. please don't drop the cc list. YH --

Yinghai, As I expected pci=mmconf doesn't allow the MacBook Pro to boot. My understanding is that mmconfig is need for Linux on Macintel (at least for a shared MacOS X/Linux system). I am stuck with regards to the pci_early_config_dump results. The output we need scrolls off the top of the screen and since the boot hangs I can't access with dmesg. Can you suggest a hack right at the end of the code that does pci_early_config_dump that would halt the boot immediately after the ...

YH, I meant that pci=nommconf doesn't allow the boot to complete under 2.6.26. I haven't tried that under 2.6.25.10, however the 2.6.5.10 kernel should be using mmconfig since I see... PCI: Using MMCONFIG at f0000000 - ffffffff PCI: Using configuration type 1 ACPI: EC: EC description table is found, configuring boot EC ACPI: EC: non-query interrupt received, switching to interrupt mode ACPI: BIOS _OSI(Linux) query ignored via DMI ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 ...

This adds hooks for the SLUB allocator, to allow tracing with kmemtrace. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- include/linux/slub_def.h | 9 +++++++- mm/slub.c | 47 ++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 49 insertions(+), 7 deletions(-) diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h index d117ea2..0cef121 100644 --- a/include/linux/slub_def.h +++ b/include/linux/slub_def.h @@ -10,6 +10,7 ...

Hello everybody, I hopefully fixed previous complaints. Also wrote some documentation and fixed some missing stuff in SLAB. Please take a look and comment. BTW, see Documentation/vm/kmemtrace.txt for details on how to use this and for info on design details. Eduard Eduard - Gabriel Munteanu (4): kmemtrace: Core implementation. kmemtrace: SLAB hooks. kmemtrace: SLUB hooks. kmemtrace: SLOB hooks. Documentation/kernel-parameters.txt | 6 + ...

Acked-by: Matt Mackall <mpm@selenic.com> -- Mathematics is the supreme nostalgia of our time. --

Hi Eduard-Gabriel, On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu We have malloc_sizes[i].cs_size here as the _allocated_ size (which ...here as well. Why? AFAICT, you should always use ->buffer_size as the_allocated_ size. Hmm? --

This adds hooks for the SLAB allocator, to allow tracing with kmemtrace. Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> --- include/linux/slab_def.h | 56 +++++++++++++++++++++++++++++++++++++----- mm/slab.c | 61 +++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 104 insertions(+), 13 deletions(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 39c3a5e..77b8045 100644 --- a/include/linux/slab_def.h +++ ...

Hi, [Adding Randy to cc for the Documentation/ parts and Matt for the core.] On Thu, Jul 17, 2008 at 3:46 AM, Eduard - Gabriel Munteanu As I mentioned in private, I would prefer we drop autoconf from the I think you're supposed to document the actual filesystem in I still think kernel vs. cache is confusing because both allocations So why don't we have the ABI version embedded here like blktrace has so that user-space can check if the format matches its expectations? That should ...

Yes, I should cut all these casts off. Will resubmit soon. Eduard --

Before accessing the device data structure in hardware handlers, make sure it is a indeed a sdev device. Yinghai Lu <yhlu.kernel@gmail.com> found the bug on Jul 16, 2008, and later tested/verified the following fix. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> -- Index: linux2.6.26-git3/drivers/scsi/device_handler/scsi_dh_rdac.c =================================================================== --- linux2.6.26-git3.orig/drivers/scsi/device_handler/scsi_dh_rdac.c +++ ...

I don't actually like that one very much either. It's perfectly readable when looking at things closely, but it's not very nice when quickly "scanning" code visually. It looks like two separate indents. Btw, that "code scanning" is not necessarily a bad idea. It's actually pretty interesting to print code out in a 2-point font (or just open a terminal and do "ctrl -" several times to make the code basically unreadable). See if the code flow makes sense from 10,000 feet - you can ...

Wow, that's a magic! It works now! I think we should document it in the Documentation of kgdb. Thanks! -- ZC Miao (hellwolf.misty@gmail.com) Blog http://hellwolf.cublog.cn gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. --

Do you have CONFIG_DEBUG_RODATA=y in your kernel config? There is a presently a known problem where breakpoints will silently fail to plant when this is turned on. Jason. --

Andi, Jesse, Linus, Thanks for working through this while I'm away. Patches with cross-tree dependencies happen, and they continue to be a challenge to our process. We don't really have an organized way to handle them. It seems that every time they are a communication challenge and I'm sorry I wasn't there to hold up my end of the communication on this merge. Jesse, I use Tony Luck's topic-branch scheme, now part of the git ...

Good catch. Thanks. I'll queue a revert. -Andi --

Umm. The particular PART of ACPI you depend on needs to go in first, yes. That's the whole point of topic branches. They allow you to separate out work to different areas, so that people who are interested in (say) the PCI-impacting ones can merge with one part, without having to wait for the The PCI tree merged the suspend branch from the ACPI tree. You can see it by lookin gat the PCI merge in gitk: gitk dc7c65db^..dc7c65db and roughly in the middle there you'll find Jesse's ...

I originally started with topic branches and imported a few patches this way, but then eventually realized they don't really match my working style. In particular I tend to edit and sometimes delete old patches and that seems to be quite painful with the topic branch setup (or perhaps I just haven't figured out how to do it nicely). Also tried it with guilt, but that also ran into some issues (in particular after merges one cannot manage the patches as a guilt stack anymore) What I did then ...

Don't worry about it. Start small. I think the x86 tree took up some pretty extreme limits, as can be seen by their 29-way merge or whatever it was. They also obviously have a lot more stuff going on than the PCI tree would be expected to have. For most people, I'd expect that a small handful of branches is good. It might be just one, but it might be a couple of independent issues. The point where a topic branch is _really_ useful is when you ask yourself whether that particular ...

It matters to us end-testers when we do a git bisect. If you leave the history intact and let the merging happen at Linus' end (or, at least at merge time), then there is a point in history of your tree that someone (or git bisect) can check out and try, validating the patch, and therefore fingering a failed merge. It's the difference between having tested patches and an untested merge, or untested new patches and an untested merge. Your point is the end result is untested either way. The ...

Let me do a made-up example of this just to kind of illustrate the point. Let's say that _I_ rebased history to always make it linear. That would obviously make things much "easier" to bisect, since now it's just a linear list of commits, and bisection is just taking the midpoint of that list and trying it. Right? Also, I'd fix up the linear list so that any found bugs are squashed into th code that caused them, so all _known_ bugs are non-issues from the standpoint of bisection: ...

Ok I can do that one separately. I think my main problem was that it seemed so painful to change old commits and I ended up accumulating ugly reverts and incremental changes, but perhaps I just need to do better frontend scripts to make Hmm, perhaps I'm thick, but for me the only difference seems to be that the submitter does the merge that you would do (and safes himself a yelling at if it doesn't build or crashes at boot or similar...). In both cases there's a "untested in that ...

git rebase --interactive sounds like exactly what you are asking for. Harvey --

No. "git bisect" is perfetly able to handle merges. They are _fine_. The problem with rebasing is that it *changes* something that was already tested (and possibly merged into somebody elses tree) into SOMETHING ELSE. And that means that a large portion of the previous testing is basically thrown away. In particular, if something worked for somebody before, it also removes the "known good state" from a bisection standpoint, so rebasing actually makes things _harder_ to bisect - ...

Because sometimes merges are non-trivial. If you roll that merge conflict resolution back into the original patch, then the patch is now different. And in all these rebasings, who's to say there won't be a typo that accidentally changes the original patch that has had more Surely you agree that more testing is better? A rebased patch has had Andi, no offense was intended here. I'm just asking you to walk If you rebase, you're creating new patches that have less testing than the originals. ...

One final note on this: the above is obviously not a problem for simple code that only really does one thing, and in particular for code that you wrote yourself. Moving your own commits around to make them make more sense - or splitting them up etc - is often a _good_ thing, even if it obviously does change history. So using rebase to clean up and simplify and/or fix up stupid ordering issues is good, and "git rebase -i" is actually really good for this thing. No, the problems ...

Well, I haven't actually seen Len's original tree, so maybe the stuff Andi pushed was just the stuff he had queued up independently. I guess I Len wrote it up at one point, but I can't for the life of me remember where. He's not the onyl one to ask, though - Ingo and Thomas seem to have picked up topic branches pretty well (I had some issues with a couple of the topics, but they weren't fundamental and the major one was probably because Ingo tried a bit too hard to make sure that ...

Sounds like a nice feature. Thanks for the pointer. -Andi --

And Andi, before this goes any further, I'd like to say that (a) no, I don't hate you and (b) sorry in advance and in retrospect for my obviously abrasive personality and just being harsh. In particular, this is something that I have gone through with a _lot_ of maintainers. So you don't need to feel bad about it. Ingo and Thomas obviously did the very same thing not that long ago. And Davem had the same issue in the networking tree - most of the times when I pulled, I could tell ...

This line overflows while the result is good if changed to: if(((unsigned long long)m * (unsigned long long)m) > (unsigned long long)x) -- Len Sorensen --

As Lennart has said, gcc is smart enough to transform a division by a fs/nfs/write.c is init code mm/page_alloc.c is also init code mm/oom_kill.c isn't a hot path which leaves the fbmon case, which after a quick peek is setup code, so not a hot path either. So while that doesn't preclude us from changing it if you can indeed show its a better implementation, its not on anybodies hit-list. --

They will fault in the kernel, but only to fill the page tables, so it would cut down on latency. I do *NOT* believe we should make this an x86-only change. If it should be architecture-dependent I'd rather find the architectures that do need it. However, before changing this I really want to see some of the history about why it's that way in the first place. -hpa --

You can do that. There are lots of commercial products containing You are mistaken in several levels. 1. Disrespecting others' freedoms is not a matter of freedom, it's a matter of power. 2. Nothing in the GPL prevents you from doing any of this. If there is something that prevents you from doing this, it's copyright law. You won't find prohibitions in the GPL. 3. If you're unable to combine third-party GPL-incompatible software with GPL software, it's because the third party ...

Nah. Should be GPL V-infinity That way there won't be any more. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is ...

good point. i'll change that. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== --

Yeah, I was trying to decide if I should remove that or not, in the event we wanted to support alternate [blk]ciphers in the future for the cprng. As I think about it, I don't think its a big deal to nix. I'll get rid of it shortly. Thanks -- /*************************************************** *Neil Horman *nhorman@tuxdriver.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --

Doh! Ment to remove that! My bad :) Thanks -- /*************************************************** *Neil Horman *nhorman@tuxdriver.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ --

OK, just to be sure we're talking about the same thing, is kernbench displaying the context switch *rate*, or the total number of context switches during the build? Peter is looking at vmstat, which is showing cs/sec. J --

I'm talking about total number of context switches - kernbench gets it from time -f "%c" make -j 4 Dividing through it gives me a rate of around 250/sec (vs Peters 3000), but I've set CONFIG_HZ=100 (vs Peters 1000), so they don't wildly conflict. Well spotted :-) - Alex -----Original Message----- From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] Sent: 17 July 2008 16:45 To: Alex Nixon (Intern) Cc: Peter Zijlstra; Ingo Molnar; Linux Kernel Mailing List; Ian Campbell Subject: ...

Yeah I've checked - the number of context switches seems to be around 60k regardless of whether CONFIG_PARAVIRT is switched on, and regardless of whether it's running in domu or native (-j4 on dual core) -----Original Message----- From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] Sent: 17 July 2008 16:03 To: Peter Zijlstra Cc: Ingo Molnar; Linux Kernel Mailing List; Alex Nixon (Intern); Ian Campbell Subject: Re: Large increase in context switch rate No, it doesn't seem to be. A ...

Is this specific to Xen?, as a native kernel doesn't do more than ~3k cs/s with make -j3 on my dual core. --

How about if you boot with printk_time=0, whilst CONFIG_PRINTK_TIME=y? r, Kyle --

I did a git-checkout of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git which got me commit id 33af79d12e0fa25545d49e86afc67ea8ad5f2f40 and looked at include/linux/smp.h line 123. It has: #define on_each_cpu(func,info,wait) \ ({ \ local_irq_disable(); \ func(info); \ local_irq_enable(); \ 0; ...

That's the function call right there :-) Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

Hi! this patch fixed my problem completly. thanks a lot! kind regards, Alois --

From: Will Newton <will.newton@imgtec.com> Applied, thanks. --

Hi Oleg, The app can reload the timer itself before the signal has been dequeued Yes, this case definitely occurs. Now that I know what's going on, I've finally managed to extract a standalone test case. Try this: http://markmc.fedorapeople.org/test-posix-timer-race.c Yeah, I had considered that, but it's a tad more invasive. See below. I mainly don't like this patch because we may lock the sighand from one thread's task_struct and then unlock it via the group leader's ...

Mel, Thanks for the info & the script. I'll give it a try & see what we get. Richard --

On Thursday, July 17, 2008 12:36 AM Hi, Roland I used outlook to send these patches, can you give me some aderise on how to send non-mangled patches. Best wishes jie --

--- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

We would prefer to have kernel-doc on exported functions... --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

Gaah. Generally we don't, but you're right to ask. The ELF loading keeps on accumulating these things, and I'm not sure we have the right process for things like this. They're all individually small and insignificant, and they are all individually never going away and making the ELF loader messier and messier. I dunno. Linus --

Some IBM POWER-based platforms have the ability to run in a mode which mostly appears to the OS as a different processor from the actual hardware. For example, a Power6 system may appear to be a Power5+, which makes the AT_PLATFORM value "power5+". This means that programs are restricted to the ISA supported by Power5+; Power6-specific instructions are treated as illegal. However, some applications (virtual machines, optimized libraries) can benefit from knowledge of the underlying CPU model. ...

On Thu, 17 Jul 2008 17:19:32 -0500 OK. But it conflicts directly with the already-queued execve-filename-document-and-export-via-auxiliary-vector.patch (which various potential reviewers blithely deleted - don't come complaining to me!): From: John Reiser <jreiser@BitWagon.com> The Linux kernel puts the filename argument of execve() into the new address space. Many developers are surprised to learn this. Those who know and could use it, object "But it's not documented." Those who ...

That was the intent, yes. However: $ scripts/bloat-o-meter vmlinux-x86-{before,after} add/remove: 0/0 grow/shrink: 2/0 up/down: 18/0 (18) function old new delta init_mm 784 800 +16 load_elf_binary 11946 11948 +2 (x86_64_defconfig, gcc 4.2.3) The init_mm/mm_struct bloat is expected (although I'd like to avoid that), but evidently it has some small effect on ...

On Thu, 17 Jul 2008 16:14:29 +1000 Do you have any tests in mind that we could use to decide whether the patch I posted Tuesday would do a decent job at protecting frequently used data from streaming data? http://lkml.org/lkml/2008/7/15/465 -- All Rights Reversed --

It's far far easier to tell the kernel "I am no longer using these pages" than to say "I will not use these pages sometime in the future after I have used them". The former can be done synchronously and with a much higher efficiency than it takes to scan through LRU lists to figure this out. We should be using the SEQUENTIAL to open up readahead windows, and ask The slow desktop in the morning should not happen even without such a call, because the kernel should not throw out frequently ...

This approach, instead of invalidating the pages right away would provide a middle ground: a way to tell the kernel "these pages are not too important". Whereas if MADV_SEQUENTIAL just invalidates the pages once per megabyte (say), then it's only doing what is already possible using MADV_DONTNEED ("drop this pages now"). It would automate the process, but it would not provide a more subtle hint, which could be quite useful. As I see it, there are two basic concepts here: - no_reuse (like ...

I never pretended anything like that. Actually, that's what the "immediate values" are for : they allow to patch load immediate value instead of a memory read to decrease d-cache impact. They now allow to patch a jump instead of the memory read/immediate value read + test + conditional branch to skip the function call with fairly minimal impact. I agree with you that eating precious d-cache and jump prediction buffer entries can eventually slow down the system. But this will be _hard_ to show ...

OK but saying "there is no detectable impact when running hackbench" is I'm not saying you have to reproduce it (although Intel's Oracle OLTP benchmark is very sensitive to that kind of thing and schedule() is near the top). But just acknowledge that it adds some cost. OK you're one of the few people really trying hard to count every cycle so I don't mean to pick on this code in particular. --

Well, in that case, it would be best to tack a Cc: stable@kernel.org git footer to it right away, I think. IMHO, it would also be nice if the commit message made it more clear that the issue it solves can affect much more serious ACPI events than just hot key presses. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

Vacuously so. My patch still applies, but #10919 makes it obsolete. My patch fixed a bug that shows up in polling mode. #10919 kills polling mode. I've tested v2.6.26 + #10919 and it works fine (except for spamming the kernel log - please read my Bugzilla comment). It appears that interrupt mode suffered from a race which is very similar to my original problem. If two GPE interrupts arrive before the workqueue runs, then the second interrupt will be ignored ...

Not so, there are two polls in ec.c, first is poll for change in status register, which gave the name to the mode, and still exists; the other is for event in embedded controller, which was introduced to properly solve #9998, and part of The notion of queue in embedded controller is new, it was never mentioned in ACPI spec, so the driver was written with assumption that new query interrupt should not arrive before we service previous one. There is even a chart in how interrupts I think, this is ...

We need to get ALL pending events from the EC, whether in polling mode or in interrupt mode (and we must make sure that we ARE going to queue any new interrupt before we stop checking for an empty pending event queue, otherwise there is a small window where a new event might get queued, and we are still masking the GPE and don't notice it). As long as the fix does that, it is all I care :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the ...

OK, I forgot about that. I need to do some reading on kernel programming, workqueues in particular, and redo my patch again. Sorry, Alexey! AFAICS there's still this (very) small window where events could be dropped. Alan --

Hi Alan, Could you please test if your patch works with the last patch in #10919? Thanks, Alex. --

By virtue of this being in debugfs, we can change the user interface I like this as that is what a number of current modules do (usb-serial drivers), but you have to be careful about the module parameter namespace to not get collisions here with existing "debug" files. So for now, I recommend staying in debugfs, it makes more sense. thanks, greg k-h --

In looking at your follow-on patches, where you add this to subsystems, it seems that you have to add a lot of #include <linux/dynamic_printk.h> lines. And in looking at this modification to device.h, I think lots of the kernel should break, but you are getting it "for free" by including the .h file within kernel.h. Why not also include it here in device.h? Also, with this change, code that is already using dev_dbg() today is instantly converted over to this logic now, right? Anyway, ...

Seconded. Makes the cpufreq-related patch even smaller, for we won't have to touch all drivers. Makes sense, and we can discuss depending one thing on another later on. Looking forward to seeing this infrastructure merged. I guess it will help a lot. Best, Dominik --

<within all cpufreq drivers> #define DYNAMIC_DEBUG_CPU_FREQ 1 <dynamic_printk.h> #ifdef DYNAMIC_DEBUG_CPU_FREQ #define DYNAMIC_DEBUG_NUM_FLAGS "3" ... #else ... ... #endif or -- even better -- could we determine the definition of DYNAMIC_DEBUG_CPU_FREQ on the fly? It needs to be set to true for exactly all Not that much of a nuiseance, IMO. Or SELECT CONFIG_DYNAMIC_PRINTK_DEBUG when CONFIG_CPU_FREQ_DEBUG is enabled (if davej agrees ;) ) Best, Dominik --

yes 1) cpufreq.h is included by other subsystems, and thus those other subsystems potentially have the wrong debugging information. 2) For the case where CONFIG_CPU_FREQ_DEBUG is set and CONFIG_DYNAMIC_PRINTK_DEBUG is not set i need to be able get the proper definition of 'dynamic_dbg_enabled()' out of dynamic_print.h (included by kernel.h). This proper definition is obtained by setting 'DEBUG', and thus i need to define this before the kernel.h include. We can solve #2 by defining ...

look at what went into 2.6.25.11 for example. it's a security fix. you do treat them differently: you include them in -stable to the exclusion of many other 'less important' fixes. read Documentation/stable_kernel_rules.txt for how you not treat all fixes as equal (it's not only security ones that anything that breaks the kernel's security model. privilege elevation always does. --

Hey, I have a crazy idea! What if they just mark all the bugs as a security bug (after all they all kinda are for some definition of security anyway)? That way people just apply all the patches and do not have to analyze anything, therefore not wasting their limited human resources at all! Linus' point is exactly that they shouldn't be treated differently, so you shouldn't allocate human resources to other bugs and just apply the security ones. If you want to convince someone you must tell us ...

Well it's hardly last minute given that the merge window only opened a couple of days ago... But beyond that, now that I've thought about it a bit more I'm not even sure the patch is really correct (though it works on my test machines). Shouldn't we be looking at _PRS not _CRS? And ideally we should try to find even more space, not less. This patch made one of my machines lose quite a bit of space: ... Allocating PCI resources starting at c0000000 (gap: ...

Sure, inlined functions are embedded in a caller function, so the closest function is the correct owner. However, I meant local-scope functions can have same name if they are defined in different scope. And even though, both of them are shown in kallsyms. This mean, you can see the functions which have real different existence but have same symbol. Would you mean systemtap should not probe those name-conflicted Hmm, here is what I got with your patch; $ stap --kelf -e 'probe ...

Just by way of illustration, this is systemtap fixed up according to suggestion number 1. You can see now using your test case that we get: # probes kernel.function("do_open@fs/block_dev.c:929") /* pc=<lookup_bdev+0x90> */ /* <- kernel.function("do_open") */ kernel.function("do_open@fs/nfsctl.c:24") /* pc=<sys_nfsservctl+0x6a> */ /* <- kernel.function("do_open") */ kernel.function("do_open@ipc/mqueue.c:642") /* pc=<sys_mq_unlink+0x130> */ /* <- kernel.function("do_open") */ James From: ...

Hi James, Thank you for updating the patch. Unfortunately, I found another scenario; if someone make a module which has EXPORT_SYMBOL(do_open), it's a non-static function. but there are other static version do_open in kallsyms. Here, I tested it and got below; $ stap --kelf -e 'probe module("test").function("do_open"){}' -p2 # probes module("test").function("do_open@?") /* pc=<do_open+0x0> */ /* <- module("test").function("do_open") */ And I think similar issue will occur even if it is ...

It's actually one of these: http://www.frontier-silicon.com/products/chips/chorus2.htm Support for which is not yet in the mainline kernel. Kconfig updates should follow when the SoC support is merged but I hope these patches --

I take the blame on me. I've copied that file between OSes so it changed executable. It slipped from my attention Will also change my scripts as well. Tomas --

On Tue, 15 Jul 2008 22:31:32 +0900 Why do we remove it, rather than unbreaking it? Did some other driver replace it? Does nobody need the driver any more? --

On Wed, 16 Jul 2008 17:18:18 -0700 The old driver was not maintained for a long time and did not work(also it was not used). It was there for someone might fix it. But all function(LED, MTD, Framebuffer) replced by new drivers. It's time to go. Yoichi --

Here is the link to the original thread http://lkml.org/lkml/2008/7/11/328 And here is where Linus explained the idea http://lkml.org/lkml/2008/7/12/137 I'll reply to the rest of your email tomorrow (can't keep my yes open any longer :)). Max --

>>> On Wed, Jul 16, 2008 at 5:44 PM, in message <487E6BD7.3020006@qualcomm.com>, Well, admittedly I am not entirely clear on what problem is being solved as I was not part of the original thread with Linus. My impression of what you were trying to solve was to eliminate the need to rebuild the domains for a hotplug event (which I think is a good problem to solve), thus eliminating some complexity and (iiuc) races there. However, based on what you just said, I am not sure I've got that ...

Yes and no. The parameter PCI_DMA_BUS_IS_PHYS is set if the platform doesn't have one. Nowadays, that's not enough; with VT and bypass what the system really needs to know is if the device will be using the iommu. The idea of calling into the platform iommu code was considered when all this was done, but it was rejected. Function pointer calls are incredibly expensive on most platforms that at that time had iommus. The best way was to construct a theoretical parametrisation of an ...

On Wed, 16 Jul 2008 14:02:27 -0400 (EDT) If the device has 64KB boundary restriction, the device also has max_seg_size restriction of 64KB or under. So the vmerge acounting What is your new restriction? All restrictions that IOMMUs need to know are dma_get_seg_boundary and dma_get_max_seg_size. --

On Thu, 17 Jul 2008 07:50:24 -0400 (EDT) I don't think that your argument, 'the problem that we don't know', is true. With the vmerge accounting, we calculate at two places. So if we add a new restriction, we need to handle it at two places. It's a logical result. Of course, it's easier to calculate at one place rather than two places. But 'we don't know what restriction we will need' isn't a problem. BTW, as I've already said, I'm not against removing the vmerge accounting from ...

or see if Documentation/email-clients.txt has any useful info for you... --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

applied to tip/x86/urgent, thanks Rusty. Ingo --

The short answer is that HP-UX decided to keep major number 11 as a branding decision, and has released updates such as 11i, 11i v1, 11i v2, etc. Most recent release was 11i v3, and if you do a uname -a, you'll see that you get a "real" version, like 11.31. http://en.wikipedia.org/wiki/Hpux#Versions /ac --

Use 2.8 in 2008, 2.9 in 2009, 2.10 in 2010, etc? Craig Milo Rogers --

Another point that came into my mind: How many scripts and programs out there parse the kernel version number, know about the 2.6 prefix, and might need an update if it changes? Not a big deal if a change would indicate a big change like with the old development model - but IMHO not worth it if there's no compelling reason why we have to change the numbering at all. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had ...

I'm very confused. I can do this... make INSTALL_FW_PATH=/tmp/foo firmware_install su otheruser touch firmware/.ihex2fw.cmd (gives EPERM as expected) make INSTALL_FW_PATH=/tmp/foo2 firmware_install And it _works_ for me, after I've made that change in scripts/Makefile.fwinst. But I don't have .ihex2fw.d -- I have .ihex2fw.cmd. What is in your .ihex2fw.d? And does it work if you include _that_ from firmware/Makefile? /me wonders where Sam is hiding... -- dwmw2 --

HOSTCC firmware/ihex2fw - due to: FORCE /home/rafael/src/linux-next/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system compilation terminated. Thanks, Rafael --

Jean, -tip testing found another (similar) i2c crash with latest -git, on a Core2Duo laptop: calling nforce2_init+0x0/0x1b initcall nforce2_init+0x0/0x1b returned 0 after 0 msecs calling nforce2_s4985_init+0x0/0x275 BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c04af2cf>] i2c_smbus_xfer+0x27/0x3f0 *pdpt = 00000000009cb001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Pid: 1, comm: swapper Not tainted (2.6.26-tip #3033) EIP: 0060:[<c04af2cf>] EFLAGS: ...

Well, it's pretty easy oops unless I misread something. It happened on not nforce2 motherboard, right? nforce2_init will just register PCI driver, no matching PCI ids => nforce2_set_reference() isn't called => nforce2_smbus stays NULL. Second module loads and tries to i2c_smbus_xfer(NULL, ) in module_init() hook which oopses. --

turning off CONFIG_I2C_AMD756_S4882 works around this bug (as expected), via the patch below. Ingo ---------------------------> commit 3f6403ab0bfdfca0cefbbc414afedc62734392f3 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Jul 17 11:52:41 2008 +0200 i2c: work around boot crash in amd756_s4882_init() work around: [ 19.610000] bus: 'pci': add driver amd756_smbus [ 19.615204] initcall amd756_init+0x0/0x20 returned 0 after 9 msecs [ 19.620000] ...

It is in 2.6.26 as I haven't merged any patches with Linus yet, portions of it might be in older kernels, but not in the same type of format. thanks, greg k-h --

The label that is written on the board for this particular LED, or Hm.. how could I enumerate them then? Or should I just give them the This is tricky question. Personally I place them inside the gpio controller node that is responsible for the LED. But I think placing the led nodes at top level would be also fine (maybe with "leds { }" node as a parent for all board's LEDs. What would you suggest for a "best practice"? Thanks, -- Anton Vorontsov email: ...

I like the idea, thanks. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

On Thu, Jul 17, 2008 at 06:05:19PM +0400, Anton Vorontsov wrote: Ugh, no. The idea sounds good, but in practice it isn't, since we'll have to handle suspend/resume ops ourselves. When we stick with the device/driver model we're getting all this for free. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

This "compatible" name is a bit too generic. No, I don't know a What is a label? It should be described here. Also, its encoding You show a unit address but have no "reg" value. This is incorrect. What would be the parent node of this, btw? Segher --

Ah. I just wrongly read your message. You're purposing to use gpio leds platform driver... I think this is doable, yes. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

Ok, how about adding code the existing leds-gpio driver so that it can creates LEDs from of_platform devices too? I've made a patch to do this and it works ok. The code added to leds-gpio is about half what was involved in Anton's new driver. What I did was re-factor the existing platform device probe function to use a new function that creates a single led. Then a new of_platform probe function can use it too. That way most of the probe code is shared. remove, suspend and resume aren't ...

Basically what I did then in my patch then, refactor leds-gpio so most of it is shared and there is a block of code that does platform binding and another block that does of_platform binding. I didn't change the OF platform binding syntax so as not to complicate the example, but that's easy to do. Something like: leds { compatible = "gpio-led"; gpios = <&mpc8572 6 0 &mpc8572 7 0>; labels = "red", "green"; }; Or like this, which needs a little more code to ...

On Thu, Jul 17, 2008 at 9:20 AM, Anton Vorontsov Alternately, I would also be okay with a scheme where all LED nodes have a common parent and an of_platform driver would bind against the parent node; not the individual children. Then the leds-gpio driver could be refactored to have both platform and of_platform bus bindings. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. --

Won't the leds-gpio driver give you suspend/resume support? g. --

hi Jaroslav, et al, -tip testing found the following bootup crash on latest -git: [ 44.827459] calling alsa_card_opti9xx_init+0x0/0x20 [ 44.830435] bus: 'isa': add driver opti93x [ 44.833503] device: 'opti93x.0': device_add [ 44.837804] bus: 'isa': add device opti93x.0 [ 44.841820] bus: 'isa': driver_probe_device: matched device opti93x.0 with driver opti93x [ 44.845327] bus: 'isa': really_probe: probing driver opti93x with device opti93x.0 [ ...

At Thu, 17 Jul 2008 19:06:57 +0200, Could you try the patch below? thanks, Takashi --- diff --git a/sound/isa/opti9xx/opti92x-ad1848.c b/sound/isa/opti9xx/opti92x-ad1848.c index 41c047e..d20abb2 100644 --- a/sound/isa/opti9xx/opti92x-ad1848.c +++ b/sound/isa/opti9xx/opti92x-ad1848.c @@ -688,7 +688,7 @@ static void snd_card_opti9xx_free(struct snd_card *card) if (chip) { #ifdef OPTi93X struct snd_cs4231 *codec = chip->codec; - if (codec->irq > 0) { + if (codec && ...

No. J --

Looks good to me. Ack. Max --

If needed: Acked-by: Andrew Vasquez <andrew.vasquez@qlogic.com> BTW: is the memory_read_from_buffer() work for qla2xxx going in through the mm tree submission path??? --

On Thu, 17 Jul 2008 16:12:35 -0700 FSVO "through", yeah. It's appeared on linux-scsi four times so far. Last time James complained about the fs.h inclusion so Akinobu raised a patch "move memory_read_from_buffer() from fs.h to string.h" which I just merged. I'll just keep pressing send - it'll get there sometime. Or you can merge it if you like. --

Fine, I'll give you a little time. But I want to hear specifics how it helps drivers. I have shown how it hurts many drivers. My arguement is that once we set the flag on the drivers, we will end up with it set on all drivers or the remaining drivers will not care. There were 413+ drivers in linux-next that were compiled by allyesconfig, about 150 used driver data. If the purpose is to enforce range checking, then I'll start working on patches for those 100 drivers to do that. But ...

Thanks. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

The GFDL is never appropriate, and certainly not for the kernel tree. We had some files under it in the past and we decided to relicense them after talking to the authors. --

Heh. This fits the general pattern where American and English spellings diverge - usually it's the English spelling which changed rather than the American one. It's not normally so recent, though. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." --

On Wed, Jul 16, 2008 at 11:48 AM, John W. Linville I'll cover this. If we can't cover this well in the time frame provided we can discuss this over the course of the week in impromptu sessions. Luis --

i chose min(p_bdi * p_cgroup, p_bdi * p_task) because i couldn't imagine a simple example for which my patch can make some sense is: while :;do dd if=/dev/zero of=file conv=notrunc bs=4096 count=1;done YAMAMOTO Takashi --

If you could get netconsole working and collect the complete console log from both the working config and the broken one, that would help a lot. Bjorn --

True, there are other serious types of bugs (silent data corruption is one particularly nasty one). However, for *any* serious bug, it's important to be clear on what the likely impact is and what's affected. This goes particularly for the ones that might otherwise not be obvious to the person affected until it's too late, such as security and silent data corruption bugs, but really it applies to all serious bugs. I'm not convinced these descriptions are clear enough. Aidan --

I think a wrapper (move to right group and calls exec) will run by user, not by admin. In explicit placement, user knows what a type of application he/she launch. /mnt/cgroup | | gid1 gid2 | | | | uid1 uid2 uid3 uid4 | | proj1 proj2 [uid1/gid1]% newtask.sh proj1app ... proj1app run under /mnt/cgroup/gid1/uid1 [uid1/gid1]% newtask.sh --type proj1type proj1app ... proj1app run under /mnt/cgroup/gid1/uid1/proj1 In this case, admin sets up limitation of ...

Thanks for the report, I've been away for a while, thus the late response. Please update to get this relevant fix and some other TCP fixes (if you haven't yet): releases/2.6.25.7/tcp-fix-skb-vs-fack_count-out-of-sync-condition.patch ...If you still get them afterwards, please do rereport (and include me as recipient :-)). ...I know there are couple of cases still after that fix where TCP invariant checks trigger but they've been rare enough to evade any of my debugging attempts ...

I think that exposes us to a race. CPU takes the first interrupt, calls handle_fasteoi_irq(). That calls handle_IRQ_event() which calls the device's interrupt handler. Interrupt handler reads status register to determine what to do next. Device generates second interrupt and changes status register. Second interrupt is never delivered because the ->eoi hasn't been called yet. I plan to keep using the edge handler which solves this race by calling mask_ack(). For MSIs without mask bits, ...

Remember that MSI predates INTX disable bit. -- Krzysztof Halasa --

That's true. MSI was introduced in PCI 2.2 and INTX disable was introduced in PCI 2.3; a 3-year window. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

__do_IRQ() is the old all-in-one handler which is not called on platforms which have GENERIC_HARDIRQS set. You can safely ignore what Right and it is not supposed to know anything about the hardware details at all. The per irq setting can provide NOOP functions for all the mask/mask_ack/unmask things when thats the right way for the That's irrelevant. All the interrupts are handled via Yep. You can also use fasteoi_handler, which just calls ->eoi() after You want to use the ...

Yep, I believe Lachlan is planning to regenerate the xfs git tree before the pull request. --Tim --

Hmm, I don't see how the apic timer is related to that, but it might be a problem with the hpet. Why does it work with 2.6.24 on kubuntu 8.04 ? Oh, that's a different beast, but it might be also a problem with the timer interrupt routing. Thanks, tglx --

The Short story... it was a dark and rainy night :-P oops, wrong mailing list.... so here goes The kernel boots and when init.d starts, the screen switches off, the CPU fan goes to Max speed, and a few minutes later all goes quiet and it appears to have powered off. I usually boot with noapictimer and if I disable ACPI totally, the clock references don't work and the timebase goes wrong. (Playing a MP3 is quite an entertaining event as it sounds like an old vinyl record player with a ...

Hi All, Here is a dump from lspci.... looks completely different :-P and here i was blaming ATI :-) Richard 00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge 00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) 00:04.0 PCI bridge: ATI Technologies Inc Unknown device 7914 00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) 00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port ...

Those are the interesting ones :) Questions: Are CONFIG_HIGHRES_TIMERS and CONFIG_NO_HZ enabled ? Is it still necessary to add any command line option ? Is the system stable ? Also please provide the output of # cat /sys/devices/system/clocksource/clocksource0/current_clocksource and # cat /proc/timer_list Thanks, tglx --

Hi All, I am still available to hack away :-) I would also like to get this bug resolved but I feel I am out of my depth with this problem. (Embedded PowerPC's are my toys) As a quick test, I grabbed the 2.6.26 kernel and built it... but alas, it broke... well, from my ill-educated guess, it looked like acpid done something and the machine shut down. Richard --

We have a fix for that in Linus tree. Any chance to give current mainline a test ride ? Thanks, tglx --

Mike> Have you made the ext2/3/4 developers aware of this? Yep. Mike> Shouldn't _any_ filesystem "just work" given that the block Mike> layer is what is generating the checksums and then verifying Mike> them on read? Yep. There are a couple of issues. One problem is that pages are no longer locked down during I/O. Instead the writeback bit is being set to indicate that I/O is in progress. Not all corners of ext* have been adapted to that properly. Especially ext2 suffers and ...

On Thu, Jul 17, 2008 at 4:35 PM, Geert Uytterhoeven Last time I looked you were not the maintainer of squashfs. Phillip spent a long time examining the possibility of maintaining compatibility but decided asthat there were sufficient advantages in a new layout to warrant the change. --

On Thu, 17 Jul 2008 15:48:02 +0200 There is no actual description of what this fixes, is there? Do machines go oops, or what? How do we proceed from here with this patch? Who should review it, who should test it, who should ack it and who should merge it? e4233dec749a3519069d9390561b5636a75c7579 was in January so this patch is applicable to 2.6.25.x and to 2.6.26.x. But is it needed there? Insufficient info. Ho hum. I queued it, tagged as needed-in-2.6.25.x and 2.6.26.x. But I am ...

"Replaying all of the user space actions that took us to get there" - this task is not even always possible without deterministic log/replay mechanism :( --

yes, we probably prefer an intermediate representation to some extent, mainly because we (a) don't want garbage data that we don't use and (b) to make the task of converting from old to new kernel version easier. But only for these two reasons. I see zero value in avoiding representation used internally by the kernel for the sake of avoiding it. In fact, if it's that much easier to stick to that representation in a specific case -- so be it. There shall be userland utilities that will be ...

$ gcc -v Did you mean dynamic allocation? :) -- Dave --

Well that assert is plain wrong: static int apic_match_dest(struct kvm_vcpu *vcpu, struct kvm_lapic *source, int short_hand, int dest, int dest_mode) { int result = 0; struct kvm_lapic *target = vcpu->arch.apic; apic_debug("target %p, source %p, dest 0x%x, " "dest_mode 0x%x, short_hand 0x%x", target, source, dest, dest_mode, short_hand); ASSERT(!target); It should be ASSERT(target), if anything. -- I have a truly marvellous ...

Yeah. Too early in the morning for me. Roland's trick might be easier than either, though. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

Yes, it's designed to be restartable. Returning 0 should be fine. We can reduce the buffer size to 256 though. I wouldn't want an allocation in this hot path. -- error compiling committee.c: too many arguments to function --

On Tue, 15 Jul 2008 14:15:27 +0530 Is this needed in 2.6.26? If so, the patch whcih I applied will need a little work because I had to touch up some rejects against already-queued changes. I can fix that issue by applying this _ahead_ of those changes, but I'm just not able to judge whether this is needed from the information which was You don't _have_ to put new includes right at the end of the list! Everyone does this, and it just maximises the probability of merge A couple of ...