It's ready for testing. Please grab http://ltt.polymtl.ca/lttng/patch-2.6.24-rc1-git13-lttng-0.10-pre18.tar.bz2 patch name : markers-support-multiple-probes.patch It still need to go through patchcheck.pl and some polishing, but it seems to work fine for me with multiple probes (the sample marker, sample probe and multiple instances of my lttng probes can connect/disconnect without problem). Currently, the "connect/disconnect" and "arm/disarm" operations are separate. However, they could be...

It's not an instruction-decoding issue at all (that's a 16- vs 32-bit issue, which can only be changed by a ljmp). Apparently the 486DX4 mis-executes the load to segment register, which is an EU function in that context. (And yes, it's sort-of-documented behaviour in the sense that the documentation says "do things this way", but the Intel docs are unfortunately full of "do things this way" which don't make sense and That's exactly the issue here. The code without this patch deferred the ...

Yes, it says it needs to be a far jmp or call (and if you enabled paging in the cr0 load, you need to identity-map the branch target). Having successfully broken the rules for a long time so far, maybe we can get away with still cutting corners... but it doesn't seem particularly worthwhile since we've been caught once. J -

Just looked it up; it was a bit hard to find (it is Intel vol 3 page 9-27, at least in the version I have), but you're right -- the documentation only demands a short jump here, not a long jmp (which actually makes sense given what I remembered that a long jump should be deferrable here.) So yes, that is definitely the right fix and avoids the ugly mixing of code. I'll update the patch. -hpa -

[Empty message]

Not known to me and I haven't tried the PID namespaces yet. Greetings, Rafael -

From: Vegard Nossum <vegard.nossum@gmail.com> This makes sure printk format strings contain no more than a single line. Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> [the message was tweaked.] Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> --- fs/fat/inode.c | 6 ++---- fs/fat/misc.c | 5 ++--- 2 files changed, 4 insertions(+), 7 deletions(-) diff -puN fs/fat/inode.c~fat_fix-printk-format-str fs/fat/inode.c --- linux-2.6/fs/fat/inode.c~fat_f...

Seems like it is not inteded for using in atomic at all (you probably passed an unknown algo here to the prepare function). You seem to have to use a workqueue if it is possible or prepare the serach before the interrupt occurs. Post your regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University -

I change the algo, from "bm" to "kmp" and probably resolve. I will make more tests and if error occour i post latter... Thanks so much. Felipe Dias -

Yes, that's what the spec says. I queried this a few months ago, but hpa used his convincing voice and said that in practice it isn't necessary; there are no known cpus which need this, and any that do would cause other things to break. But I guess now we have the counter-example... J -

Joy. Apparently the Intel documentation is actually self-inconsistent. Section 9.9.1, page 9-17 does indeed have the "far jump or call" injunction, whereas the sample code in section 9.10.1, page 9-27, line 180 does a near jump! -hpa -

iirc various Intel VT hypervisor implementations also have trouble with not following this restriction. At least in the early Xen days it was a frequent reason for boot failure. -Andi -

At a guess (I haven't looked closely) I'd say it is the bug that was meant to be fixed by commit 4ae3f847e49e3787eca91bced31f8fd328d50496 except that patch applied badly and needed to be fixed with the following patch (not in git yet). These have been sent to stable@ and should be in the queue for 2.6.23.2 NeilBrown Fix misapplied patch in raid5.c commit 4ae3f847e49e3787eca91bced31f8fd328d50496 did not get applied correctly, presumably due to substantial similarities between handle_s...

During booting of last vanilla kernel I got: Trying to free nonexistent resource... This because of if "ENABLE_APRICOT" is on we do: request_region(ioaddr,...) if (checksum test failed) goto out1; dev->base_addr = ioaddr;//<-here mistake out1: release_region(dev->base_addr,...) Here patch which fixes this bug for me. Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> --- diff --git a/drivers/net/82596.c b/drivers/net/82596.c index bb30d5b..2797da7 100644 --- a/dr...

[Empty message]

Thanks Randy - applied. Sam -

BTW what's that 'BitKeeper' fossil here? -

actually, one wonders if there's any value in keeping any references to other version control systems such as subversion, SCCS, CVS, mercurial, etc. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -

What do you mean by "other"? git doesn't have a monopoly, and the kernel should support people using a reasonable set of version control systems. Supporting VSS would be strange, but nothing wrong with the set you listed, if people find those systems useful. It's not like it amounts to a huge amount of effort to do so. J -

Apparently. -hpa -

Here the number of false positives is overhelming, but perhaps there are also _real_ duplicated include somewhere in the bunch: include/acpi/acpi_bus.h: #include <linux/device.h> include/asm-alpha/core_cia.h: #include <asm/io_trivial.h> include/asm-arm/atomic.h: #include <asm/system.h> include/asm-arm/arch-clps711x/hardware.h: #include <asm/hardware/ep7212.h> include/asm-arm/arch-clps711x/hardware.h: #include <asm/hardware/clps7111.h> include/asm-arm/arc...

Here the real job is to fliter out false positives more then print out the list I would say ;-) Marco -

(untested, needs an ack from maintainer) Spotted by Nick <gentuu@gmail.com>, hopefully can explain the second trace in http://bugzilla.kernel.org/show_bug.cgi?id=9180. If ->async_idle_cfqq != NULL cfq_put_async_queues() puts it IOPRIO_BE_NR times in a loop. Fix this. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> --- cfq/block/cfq-iosched.c~ 2007-08-09 19:59:26.000000000 +0400 +++ cfq/block/cfq-iosched.c 2007-11-04 22:23:42.000000000 +0300 @@ -2065,9 +2065,10 @@ static void cf...

given the recent patches to remove duplicated #include preprocessor directives in source files, let it be known that there are a number of them: http://www.crashcourse.ca/wiki/index.php/Duplicate_include_files help yourself. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ==========================================================...

trust me, it's not a script i'm particularly proud of: =========================== #!/bin/sh DIR=${1-*} # by default, all directories for cf in $(find ${DIR} -name *.c) ; do echo ${cf} grep "#include" $cf | sort | uniq -c | grep -v 1 done | grep -B1 "#include" | grep -v -- "--" =========================== on the bright side, it took about 90 seconds to write, but i won't be winning any awards for style. i'll add it to the web page. rday -- ======...