oh, nice to see that this is still alive. i tried this around half a year ago because i needed more than 256 loop devices and iirc, this was working quite fine. at least i got no crashes and was able to mount and acess more than 300 iso-images with that. shortly after, loop device was extended to handle a larger number of loop-devices and i went that way because dm-loop was not in mainline. i have taken a look at the wiki at http://sources.redhat.com/lvm2/wiki/DMLoop from time to time, but there ...

[Empty message]

[ version 2 of mcount patches: changes include: Removal of most notrace. Even though it may clutter a bit, we can always add more later. Removal of REGPARM. No changes is made with respect to that. Cleaned up Makefile and used Kconfig for config dependencies. Some other minor cleanups. Cleaned up tracer itself. Made it more generic and can be used to trace multiple methods. Added irqs off latency tracing. This records the highest latency areas that interrupts a...

Several different types of tracing needs to use the same core functions. This patch separates the core functions from more specific onecs to allow for future tracing methods. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- lib/tracing/Kconfig | 6 lib/tracing/Makefile | 3 lib/tracing/trace_function.c | 211 ++++++++++++++++++ lib/tracing/tracer.c | 457 ++++++++++++++--------------------------- lib/tracing/tracer.h | 55 ++++ ...

This patch adds an interface into debugfs. /debugfs/tracing/ctrl echoing 1 into the ctrl file turns on the tracer, and echoing 0 turns it off. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- lib/tracing/tracer.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++- lib/tracing/tracer.h | 1 2 files changed, 87 insertions(+), 1 deletion(-) Index: linux-compile-i386.git/lib/tracing/tracer.c =================================================================== --- li...

Add the notrace annotations to some of the vsyscall functions. Note: checkpatch errors on the define of vsyscall_fn because it thinks that it is a complex macro that needs paranthesis. Unfortunately we can't put paranthesis on this macro. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- arch/x86/kernel/vsyscall_64.c | 3 ++- arch/x86/vdso/vclock_gettime.c | 15 ++++++++------- arch/x86/vdso/vgetcpu.c | 3 ++- include/asm-x86/vsyscall.h | 3 ++- 4 file...

This patch resets the trace when it is started by the user. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- lib/tracing/tracer.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) Index: linux-compile-i386.git/lib/tracing/tracer.c =================================================================== --- linux-compile-i386.git.orig/lib/tracing/tracer.c 2008-01-09 14:14:02.000000000 -0500 +++ linux-compile-i386.git/lib/tracing/tracer.c 2008-01-09 15:17:36.000000000 -0500 @@ -78,...

The latency tracer needs a way to get an accurate time without grabbing any locks. Locks themselves might call the latency tracer and cause at best a slow down. This patch adds get_monotonic_cycles that returns cycles from a reliable clock source in a monotonic fashion. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- include/linux/clocksource.h | 3 ++ kernel/time/timekeeping.c | 48 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) Index: l...

The latency tracer can call clocksource_read very early in bootup and before the clock source variable has been initialized. This results in a crash at boot up (even before earlyprintk is initialized). Since the clock->read variable points to NULL. This patch simply initializes the clock to use clocksource_jiffies, so that any early user of clocksource_read will not crash. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: John Stultz <johnstul@us.ibm.com> --- include...

Now that each entry has a reliable timestamp, we can use the timestamp as the source of sorting the trace and remove the atomic increment. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- lib/tracing/tracer.c | 3 +-- lib/tracing/tracer.h | 2 -- 2 files changed, 1 insertion(+), 4 deletions(-) Index: linux-compile-i386.git/lib/tracing/tracer.c =================================================================== --- linux-compile-i386.git.orig/lib/tracing/tracer.c 2008-01-09 ...

The trace output is very verbose with outputing both the IP address (Instruction Pointer not Internet Protocol!) and the kallsyms symbol. So if kallsyms is configured into the kernel, another file is created in the debugfs system. This is the trace_symonly file that leaves out the IP address. Here's an example: CPU 1: swapper:0 smp_apic_timer_interrupt+0xc/0x58 <-- apic_timer_interrupt+0x66/0x70 CPU 1: swapper:0 exit_idle+0x9/0x22 <-- smp_apic_timer_interrupt+0x35/0x58 CPU 0: sshd:2611 _sp...

If CONFIG_MCOUNT is selected and /proc/sys/kernel/mcount_enabled is set to a non-zero value the mcount routine will be called everytime we enter a kernel function that is not marked with the "notrace" attribute. The mcount routine will then call a registered function if a function happens to be registered. [This code has been highly hacked by Steven Rostedt, so don't blame Arnaldo for all of this ;-) ] Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by: Stev...

For better cacheline performance, this patch creates a separate struct for each CPU with the percpu data grouped together. Signed-off-by: Steven Rostedt <srostedt@redhat.com> --- lib/tracing/tracer.c | 42 +++++++++++++++++++++++------------------- lib/tracing/tracer.h | 12 ++++++++---- 2 files changed, 31 insertions(+), 23 deletions(-) Index: linux-compile-i386.git/lib/tracing/tracer.c =================================================================== --- linux-compile-i386.git.or...

This adds the task comm and pid to the trace output. This gives the output like: CPU 0: sshd:2605 [<ffffffff80251858>] remove_wait_queue+0xc/0x4a <-- [<ffffffff802ad7be>] free_poll_entry+0x1e/0x2a CPU 2: bash:2610 [<ffffffff8038c3aa>] tty_check_change+0x9/0xb6 <-- [<ffffffff8038d295>] tty_ioctl+0x59f/0xcdd CPU 0: sshd:2605 [<ffffffff80491ec6>] _spin_lock_irqsave+0xe/0x81 <-- [<ffffffff80251863>] remove_wait_queue+0x17/0x4a CPU 2: bash:2610 [<ffffffff802...

Hello, as hibernation (swsusp) started to work with my CPU, I found that my Turtle Beach Malibu stops working after resume from hibernation. It's caused by fact that the card is not enabled on the pnp layer during resume - and thus card registers are inaccessible (reads return FFs, writes go nowhere). During resume, pnp_bus_resume() in drivers/pnp/driver.c is called for each pnp device. This function calls pnp_start_dev() only when the PNP_DRIVER_RES_DO_NOT_CHANGE bit is NOT seting pnp_drv-&gt...

In gitx86: commit 692effca950d7c6032e8e2ae785a32383e7af4a3 Author: John Reiser <jreiser@BitWagon.com> Date: Wed Jan 9 13:31:12 2008 +0100 STT_FUNC for assembler checksum and semaphore ops ... Comments? Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> diff --git a/arch/x86/lib/checksum_32.S b/arch/x86/lib/checksum_32.S index adbccd0..1f9aacb 100644 --- a/arch/x86/lib/checksum_32.S +++ b/arch/x86/lib/ch...

-- "Premature optimization is the root of all evil." - Donald Knuth --

Hi, I have some computers where port 0x80 is claimed by 8237A DMA controller [1] But in this case it seems a lasy acpi programmer that doesn't want to convert the hole in 0x80-0x8f range... PS : I post from gmane web interface, so I can't keep CC. [1] This happen with a old 7 years old siemens PIII and a new hp core2duo. state = active io 0x0-0xf io 0x80-0x8f io 0xc0-0xdf dma 4 --

UML gets linked with the 'C' runtime library. It doesn't pass parameters in registers unless you get the source and recompile the whole thing --and then you would have to recompile all your applications, too. Yikes! 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 p...

Ah, right. I didn't think of that. Does that mean that FASTCALL removals will have to be undone? Or is there an alternative? Miklos --

FASTCALL is useless and should not make a difference. It enables regparm on specific functions, but that should not make a difference if it works or not. For working -mregparm you will need asmlinkage on all functions that interface with assembler code to disable regparms for them. The only exception is system calls which have the arguments on the stack too. -Andi --

Hello, I found this kconfig info on kernel page size: '8KB and 64KB work quite well, since Sparc ELF sections provide for up to 64KB alignment.' so I thought I'll give it a try. I tested 2.6.24-rc7 and it stopped right after 'Remapping the kernel ... done' At first I wanted to bisect this but soon I found there is no kernel that boots with 64k pages on that machine. I tested 2.6.24-rc7, 2.6.23, 2.6.22, 2.6.20 and 2.6.16. 2.6.24-rc7 dies right after 'Remapping the kernel ... done' text. So ...

We (the -stable team) are announcing the release of the 2.6.23.13 kernel. It contains one serious fix for the w83627ehf.c hardware monitoring driver. If you use this driver, PLEASE, upgrade to this kernel version. To quote the developer, Jean Delvare: I have had a private report that this bug might have caused permanent hardware damage. There is no definitive proof at this point, but unfortunately due to the lack of documentation I really can't rule it out. This problem only affects the 2.6.23 ...

Add device_init_wakeup to init wakeup. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c index d98622f..28360e8 100644 --- a/drivers/power/pda_power.c +++ b/drivers/power/pda_power.c @@ -207,6 +207,8 @@ static int pda_power_probe(struct platform_device *pdev) } } + device_init_wakeup(&pdev->dev, 1); + return 0; usb_irq_failed: -- With best wishes Dmitry --

On Wed, 09 Jan 2008 16:42:34 +0100 Thanks. I think I'll drop the original patch. The mix of ints, size_t's, etc in that code is pretty random and would be best addressed by somene sitting down and working out from scratch what types we _should_ be using in there and then making all the code use the right types in an organised fashion. Doing this in a piecemeal through-a-pinhole fashion won't work very well and is a bit risky. --