Greetings, Just want some input before I start dropping patches everywhere. A simple ack will do nicely if you just agree. Currently we use the name of the most typical HP Jornada (680 and 720) to mean all 6XX/7XX (= 620/660/680/690 and 720/720/728). In the past this has led to some confusion when people tried to compile their own kernels. For instance an hp 620 user thought that their system was unsupported because everything was for '680'. Or the other way round 728 users didn't want to use 720...

I'm no VM tuning expert, but I have and still do heavy compile jobs on similarly configured machines, with no OOM problems: I regularly build 2.6 kernels and occasionally also gcc on a 100MHz 486 with 28MB of RAM and perhaps 500MB of swap. It runs a standard but stripped down Fedora Core 4 user-space, with ext3 file systems and a kernel that doesn't include anything non-essential. The machine will swap madly, but the OOM killer never triggers. (All system settings are FC4 defaults. I haven't tou...

Wires up the new timerfd API to the x86 family. Signed-off-by: Davide Libenzi <davidel@xmailserver.org> - Davide --- arch/x86/ia32/ia32entry.S | 4 +++- arch/x86/kernel/syscall_table_32.S | 4 +++- include/asm-x86/unistd_32.h | 6 ++++-- include/asm-x86/unistd_64.h | 9 +++++++-- 4 files changed, 17 insertions(+), 6 deletions(-) Index: linux-2.6.mod/include/asm-x86/unistd_32.h ================================================================...

I think that advancing the timer against the timer's current "now" can be a pretty common usage, so, w/out exposing hrtimer's internals, we add a new hrtimer_forward_now() function. Signed-off-by: Davide Libenzi <davidel@xmailserver.org> - Davide --- include/linux/hrtimer.h | 7 +++++++ 1 file changed, 7 insertions(+) Index: linux-2.6.mod/include/linux/hrtimer.h =================================================================== --- linux-2.6.mod.orig/include/linux/hrtime...

This patch removes a few remainders of the VID_HARDWARE_* removal. Signed-off-by: Adrian Bunk <bunk@kernel.org> --- Documentation/DocBook/videobook.tmpl | 9 --------- drivers/media/video/usbvision/usbvision.h | 4 ---- 2 files changed, 13 deletions(-) 643d01fb38b6f376cced035549f4e193018776e7 diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl index b629da3..b3d93ee 100644 --- a/Documentation/DocBook/videobook.tmpl +++ b/Documentation...

This defines the new macro arch_has_single_step() in linux/ptrace.h, a default for when asm/ptrace.h does not define it. It declares the new user_enable_single_step and user_disable_single_step functions. This is not used yet, but paves the way to harmonize on this interface for the arch-specific calls on all machines. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/ptrace.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 46 insertions(+), 0 dele...

I'm not sure it's true that there is no machine where some chips support single-step and others don't, though I do think it's true that no arch code has a conditional like this now. In the case of block-step (in later patches), is is the case that a run-time check for availability of the hardware feature comes up (on some x86 configurations). So a main reason The code compiles away completely with if (0)'s. I did it this way to avoid more #ifdef's in the generic ptrace code. Previous patch rev...

This adjusts the x86 kprobes implementation to cope with per-thread MSR_IA32_DEBUGCTLMSR being set for user mode. I haven't delved deep enough into the kprobes code to be really sure this covers all the cases where the user-mode BTF setting needs to be cleared or restored. It looks about right to me. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/kprobes_32.c | 15 +++++++++++++++ arch/x86/kernel/kprobes_64.c | 15 +++++++++++++++ 2 files changed, 30 insertion...

This adds low-level support for a per-thread value of MSR_IA32_DEBUGCTLMSR. The per-thread value is switched in when TIF_DEBUGCTLMSR is set. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/process_32.c | 6 +++++- arch/x86/kernel/process_64.c | 3 +++ include/asm-x86/processor_32.h | 2 ++ include/asm-x86/processor_64.h | 2 ++ include/asm-x86/thread_info_32.h | 6 ++++-- include/asm-x86/thread_info_64.h | 4 +++- 6 files changed, 19 i...

This adds constant macros for a few of the bits in MSR_IA32_DEBUGCTLMSR. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/asm-x86/msr-index.h | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/msr-index.h b/include/asm-x86/msr-index.h index a494473..4045bbe 100644 --- a/include/asm-x86/msr-index.h +++ b/include/asm-x86/msr-index.h @@ -63,6 +63,13 @@ #define MSR_IA32_LASTINTFROMIP 0x000001dd #define MSR_IA32_LASTINTTOIP 0x000...

This makes ptrace_request handle PTRACE_SINGLEBLOCK along with PTRACE_CONT et al. The new generic code makes use of the arch_has_block_step macro and generic entry points on machines that define them. Signed-off-by: Roland McGrath <roland@redhat.com> --- kernel/ptrace.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-) diff --git a/kernel/ptrace.c b/kernel/ptrace.c index 309796a..2824726 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -373,6 +373,12 @@...

This cleans up the 64-bit ptrace code to separate the guts of the debug register access from the implementation of PTRACE_PEEKUSR and PTRACE_POKEUSR. The new functions ptrace_[gs]et_debugreg are made global so that the ia32 code can later be changed to call them too. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace_64.c | 140 ++++++++++++++++++++----------------------- include/asm-x86/ptrace.h | 3 + 2 files changed, 69 insertions(+), 74 deletions(-) ...

This cleans up the 64-bit ptrace code to use task_pt_regs instead of its own redundant code that does the same thing a different way. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace_64.c | 60 ++++++++---------------------------------- 1 files changed, 12 insertions(+), 48 deletions(-) diff --git a/arch/x86/kernel/ptrace_64.c b/arch/x86/kernel/ptrace_64.c index 85fba7b..8123ecb 100644 --- a/arch/x86/kernel/ptrace_64.c +++ b/arch/x86/kernel/ptrace_64.c @@...

This cleans up the 32-bit ptrace code to use task_pt_regs instead of its own redundant code that does the same thing a different way. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace_32.c | 68 ++++++++++-------------------------------- 1 files changed, 16 insertions(+), 52 deletions(-) diff --git a/arch/x86/kernel/ptrace_32.c b/arch/x86/kernel/ptrace_32.c index 50882b3..7c33244 100644 --- a/arch/x86/kernel/ptrace_32.c +++ b/arch/x86/kernel/ptrace_32.c @@...

This changes the single-step support to use a new thread_info flag TIF_FORCED_TF instead of the PT_DTRACE flag in task_struct.ptrace. This keeps arch implementation uses out of this non-arch field. This changes the ptrace access to eflags to mask TF and maintain the TIF_FORCED_TF flag directly if userland sets TF, instead of relying on ptrace_signal_deliver. The 64-bit and 32-bit kernels are harmonized on this same behavior. The ptrace_signal_deliver approach works now, but this change makes th...

This makes ptrace_request handle all the ptrace requests that wake up the traced task. These do low-level ptrace implementation magic that is not arch-specific and should be kept out of arch code. The implementations on each arch usually do the same thing. The new generic code makes use of the arch_has_single_step macro and generic entry points to handle PTRACE_SINGLESTEP. Signed-off-by: Roland McGrath <roland@redhat.com> --- kernel/ptrace.c | 61 +++++++++++++++++++++++++++++++++++++...

I'd like to look into that later after most arch's have moved to using the generic code for their existing support. I am thoroughly in favor, but it requires some more groundwork that can come after this initial stage. Thanks, Roland -

This moves the single-step support code from ptrace_64.c into a new file step.c, verbatim. This paves the way for consolidating this code between 64-bit and 32-bit versions. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/Makefile_64 | 2 + arch/x86/kernel/ptrace_64.c | 134 ----------------------------------------- arch/x86/kernel/step.c | 140 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 142 insertions(+), 134 deletions(-) diff --git a...

This cleans up the single-step code to use the asm/segment.h macros for segment selector magic bits, rather than its own constant. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/step.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c index cb3c8bc..3b70f20 100644 --- a/arch/x86/kernel/step.c +++ b/arch/x86/kernel/step.c @@ -5,8 +5,6 @@ #include <linux/mm.h> #include <linux/ptr...

This gets rid of the local constant macro TRAP_FLAG. It's redundant with the public constant macro X86_EFLAGS_TF. Signed-off-by: Roland McGrath <roland@redhat.com> --- arch/x86/kernel/ptrace_32.c | 9 +++------ arch/x86/kernel/ptrace_64.c | 9 +++------ 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/ptrace_32.c b/arch/x86/kernel/ptrace_32.c index 39a94a0..2b4fcb5 100644 --- a/arch/x86/kernel/ptrace_32.c +++ b/arch/x86/kernel/ptrace_32.c @@ -37,9 ...

This copies into asm-x86/segment_64.h some macros from asm-x86/segment_32.h for dissecting segment selectors. This lets other code use these macros uniformly on 32/64-bit rather than duplicating the constants elsewhere. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/asm-x86/segment_64.h | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/segment_64.h b/include/asm-x86/segment_64.h index 04b8ab2..dce7421 100644 --- a/include...

I wouldn't say creating an account (if you don't already have one) plus 5 additional mouse clicks per bug report are substancially more How should a newbie find the correct mailing list? Benchmark: If you don't already know MAINTAINERS well then finding the right What about recommending a cronjob that resends the bug report every three days? ;-) Really, we must define _one_ way for people to report a bug, and how If you expect people to read and follow this, wouldn't it be easier...

What are you talking about? $ grep PATA MAINTAINERS "we" = "we kernel developers" I'm not focussed on Bugzilla. But a submitter should send a bug report _once_ through one well-defined medium, this should result in the bug report not being lost, and every other communication of the submitter should be triggered by developers requesting additional information. I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting...

You are trying to solve something that is not a problem. It does not matter which medium we choose for getting bug reports. The only thing that matters is that we get bug reports resolved within a cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -

On Sun, 25 Nov 2007 20:36:04 +0100 you have both a heavily patched kernel and a tainted kernel due to binary kernel modules.... sounds like you're best of contacting the support side of whoever gave you the patches and/or the binary module; I don't think there's much lkml can do for you. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -