On Fri, 16 Nov 2007 11:33:20 +0900 "Ken'ichi Ohmichi" <[EMAIL PROTECTED]> wrote:
>
> This patch fixes the configuration dependencies in the vmcoreinfo data.
>
> i386's "node_data" is defined in arch/x86/mm/discontig_32.c,
> and x86_64's one is defined in arch/x86/mm/numa_64.c.
> They depend on
On Sat, Nov 24, 2007 at 07:44:13PM +0200, James Bottomley wrote:
> Probing intermittent failures in Domain Validation, even with the fixes
> applied leads me to the conclusion that there are further problems with
> this commit:
>
> commit fc5eb4facedbd6d7117905e775cee1975f894e79
> Author: Hannes
> Why is it defined in configuration system instead of some *.h file?
That seems to be existing practice for this sort of thing.
I just followed what I saw.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
Any comments are welcome.
arch/powerpc/platforms/celleb/pci.c | 23 ---
1 files
At Mon, 19 Nov 2007 17:53:45 -0800,
Joe Perches wrote:
>
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Applied to ALSA tree. Thanks.
Takashi
> ---
> sound/isa/sc6000.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sound/isa/sc6000.c
On Sun, 11 Nov 2007 19:49:08 +0100 Udo van den Heuvel <[EMAIL PROTECTED]> wrote:
> Any reason why the second rng on the VIA C7 CPU is not enabled?
>
> Kind regards,
> Udo
>
>
> [via-rng.patch text/plain (634B)]
> --- old/drivers/char/hw_random/via-rng.c 2007-11-11 19:39:49.0
>
these utilities implemented in lib/hexdump.c are more handy, please use this.
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
there are still much other private hexdump implementations in the source,
which reinvent the wheel, we can find them through:
$
these utilities implemented in lib/hexdump.c are more handy, please use this.
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
crypto/tcrypt.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/crypto/tcrypt.c
On Sat, 24 Nov 2007 19:04:34 +0100
Gabriel C <[EMAIL PROTECTED]> wrote:
> >> It seems OK here from a quick test (i386, ext3-on-IDE).
> >>
> >> Maybe device driver/block breakage?
>
> Try revert
>
>
> Except C doesn't have namespaces and this mechanism doesn't create them. So
> this is just complete and utter makework; as I said before, noone's going to
> confuse all those udp_* functions if they're not in the udp namespace.
I don't understand why you're so opposed to organizing the
In a desperate attempt to screw up /proc one more time, I added some
proc fixes, wrote test module which creates and removes simple proc
file, then ran a) modprobe/rmmod loop, b) cat /proc/foo/bar loop,
c) LTP loop. So far so good -- survived overnight run.
While rebooting into new kernel, kernel
> > I agree that we shouldn't make things too hard for out-of-tree
> > modules, but I disagree with your first statement: there clearly is a
> > large class of symbols that are used by multiple modules but which are
> > not generically useful -- they are only useful by a certain small class
>
hi,
I have added some code to netif_receive_skb function.As linux kernel
is multhreaded , so there is no gaurantee than mine code is completely
executed without being disturbed by any other process .Timer interrupt
handler is an example of code which might interrupt execution of mine
code.
I
Andrew Morton wrote:
> (cc's lovingly restored. Please do not do that)
Thanks! I'm replying off list.
> On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> > Jens Axboe wrote:
> > > On Sun, Nov 25 2007, Adrian Bunk wrote:
> > > > Is there any technical reason why we need 4
Thanks for the response Mikael.
Is your 486 running a IDE disk on a normal interface or via USB? I wonder
if the NSLU2 only having I/O via USB might be significant. Also, this is a
2.6 kernel and I've seen spurious reports across the internet about similar
oom-killer problems since about
> Isn't there a way we can make this work for any upstream HT
> bridge, rather than only for specific NVIDIA chipsets?
The lines Peer indicates below will work for any vendor's bridge device
that implements an HT MSI mapping and is an upstream bridge of the
endpoint requesting MSI.
On some
The device which has the root fs is a READ-ONLY device. There is no
way for it to change between getting detached and reattached to the
computer which is suspended. In such a case there is no possibility of
hibernation because there is nothing to write back to.
I understand that this is currently
(cc's lovingly restored. Please do not do that)
On Mon, 26 Nov 2007 07:57:00 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> Jens Axboe wrote:
> > On Sun, Nov 25 2007, Adrian Bunk wrote:
> > > Is there any technical reason why we need 4 different schedulers at all?
> >
> > Until we have the
Jens Axboe wrote:
> On Sun, Nov 25 2007, Adrian Bunk wrote:
> > Is there any technical reason why we need 4 different schedulers at all?
>
> Until we have the perfect scheduler :-)
>
> With some hard work and testing, we should be able to get rid of 'as'.
> It still beats cfq for some of the
The current load balancing scheme isn't good for group fairness.
For ex: on a 8-cpu system, I created 3 groups as under:
a = 8 tasks (cpu.shares = 1024)
b = 4 tasks (cpu.shares = 1024)
c = 3 tasks (cpu.shares = 1024)
a, b and c are task groups that have equal weight.
This patch changes how the cpu load exerted by fair_sched_class tasks
is calculated. Load exerted by fair_sched_class tasks on a cpu is now a
summation of the group weights, rather than summation of task weights.
Weight exerted by a group on a cpu is dependent on the shares allocated
to it.
This
On Sun, 25 Nov 2007 16:12:57 +0100 Wagner Ferenc <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am I totally of the limit with the attached patch against
> drivers/net/bonding/bond_sysfs.c? I'd like to receive some comments,
> as I'm not a kernel developer.
Plese alwayts cc [EMAIL PROTECTED] on
This patch changes how the cpu load exerted by fair_sched_class tasks
is calculated. Load exerted by fair_sched_class tasks on a cpu is now a
summation of the group weights, rather than summation of task weights.
Weight exerted by a group on a cpu is dependent on the shares allocated to it.
This
Minor bug fixes for group scheduler:
- Use a mutex to serialize add/remove of task groups and also when
changing shares of a task group. Use the same mutex when printing cfs_rq
stats for various task groups.
- Use list_for_each_entry_rcu in for_each_leaf_cfs_rq macro (when walking task
Minor cleanups:
- Fix coding style
- remove obsolete comment
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 21 +++--
1 files changed, 3 insertions(+), 18 deletions(-)
Index: current/kernel/sched.c
Here's V3 of the group scheduler related patches, which is mainly addressing
improved fairness of cpu bandwidth allocation for task groups.
Patch 1/4 -> coding style cleanup
Patch 2/4 -> Minor group scheduling related bug fixes
Patch 3/4 (v1) -> Modifies how cpu load is calculated,
On Mon, Nov 26, 2007 at 12:03:29AM +0100, Kristoffer Ericson wrote:
> 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 since they thought they would loose their extra
> ram (only
I think the following lines are suitable for other bridges besides
nvidia's, :) :
===
+ if (pci_enable_msi_ht_cap(dev) != 0) {
+ return 0;
+ } else {
+ /* Get upstream bridge device handle */
+
+
Hi Andrew,
> Perhaps export it from within a powerpc-specific C file (along with
> suitable comment) to prevent people from generally relying upon the
> export?
Even better, I'll export it from a Cell-specific C file. I'll follow
this up in my own spufs series for .25.
Cheers,
Jeremy
-
Samuel Ortiz wrote:
Hi Richard,
On Sat, Nov 24, 2007 at 09:44:05PM +0100, Richard Knutsson wrote:
Make a single va_start() -> va_end() path + fixing:
Ok, this should be 2 separate patches then.
Thought about it, but they were so simple, I believed they would better
be merged...
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> Exactly. But *he* doesn't need to check that checksum, given that he already
> got the packet, since he has an upper-level checksum. He is not saying that
> his reasoning applies to everyone, just that it applies to him. He is not
> talking about
Hello,
I have a ASUS A6T with nforce4 and realtek RTL8111/8168B
ethernet. I am testing kernel 2.6.24-rc3-git1 on this
notebook and I have noticed strange behaviour with irq.
I pass hpet=force and acpi_use_timer_override to enable
apic, otherwise timer cpu interrupt is in old XT-PIC mode.
Robert Hancock wrote:
> We need to run any DMA command with result taskfile requested in ADMA mode
> when the port is in ADMA mode, otherwise it may try to use the legacy DMA
> engine
> in ADMA mode which is not allowed. Enforce this with BUG_ON() since data
> corruption could potentially result
Hi Richard,
On Sat, Nov 24, 2007 at 09:44:05PM +0100, Richard Knutsson wrote:
> Make a single va_start() -> va_end() path + fixing:
Ok, this should be 2 separate patches then.
The warning fixes are all good, but I fail to see the point of the va_end()
one. That doesn't seem to bring any sort of
Index: 2.6.x-xfs-new/fs/xfs/xfs_log.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/xfs_log.c 2007-11-22 10:47:21.945395328 +1100
+++ 2.6.x-xfs-new/fs/xfs/xfs_log.c 2007-11-22 10:53:11.556186722 +1100
@@ -1443,6 +1443,8 @@ xlog_sync(xlog_t
On Sun, Nov 25, 2007 at 02:08:02PM -0800, Roland McGrath wrote:
>
> This adds the (internal) Kconfig macro CONFIG_X86_DEBUGCTLMSR,
> to be defined when configuring to support only hardware that
> definitely supports MSR_IA32_DEBUGCTLMSR with the BTF flag.
>
> The Intel documentation says
(Dropped Rafael from CC)
On Sunday 25 November 2007, Bartlomiej Zolnierkiewicz wrote:
> So either something went very very wrong or the oops itself is incorrect.
>
> Please put BUG() before the put_cmd640_reg() above so the next time
> BUG happens we will know which one is it.
I've spent quite a
Hi Frank
I was wondering if you had a git tree somewhere I could pull.
Thanks
Mike
On 11/11/2007, Frank Seidel <[EMAIL PROTECTED]> wrote:
> Hello,
>
> this one also holds the - little reworked and optimized -
> cleanup of the read/write_mem32 functions.
>
> Comments and any feedback is more
On Monday 26 November 2007 07:27:03 Roland Dreier wrote:
> > This patch allows to export symbols only for specific modules by
> > introducing symbol name spaces. A module name space has a white
> > list of modules that are allowed to import symbols for it; all others
> > can't use the symbols.
On Monday 26 November 2007 07:29:39 Roland Dreier wrote:
> > Yes, and if a symbol is already used by multiple modules, it's
> > generically useful. And if so, why restrict it to in-tree modules?
>
> I agree that we shouldn't make things too hard for out-of-tree
> modules, but I disagree with
On Saturday 24 November 2007 23:39:43 Andi Kleen wrote:
> On Sat, Nov 24, 2007 at 03:53:34PM +1100, Rusty Russell wrote:
> > So, you're saying that there's a problem with in-tree modules using
> > symbols they shouldn't? Can you give an example?
[ Note: no response to this ]
> > If people
On Sunday 25 November 2007 10:59, Jeroen wrote:
> On Nov 25, 2007 7:36 PM, Robert Hancock <[EMAIL PROTECTED]> wrote:
> > Are you sure forcedeth even supports that feature? I haven't seen any
> > code for it, and certainly it should never be enabled by default..
>
> The windows driver does. I have
On Sun, 2007-11-25 at 15:58 +0100, Miguel Botón wrote:
> This patch removes a redundant declaration of 'iwl3945_priv' and
> 'iwl4965_priv' structs.
>
> Signed-off-by: Miguel Boton <[EMAIL PROTECTED]>
ACK.
Thanks,
-yi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sunday 25 November 2007 14:08, Roland McGrath wrote:
> This adds the (internal) Kconfig macro CONFIG_X86_DEBUGCTLMSR,
> to be defined when configuring to support only hardware that
> definitely supports MSR_IA32_DEBUGCTLMSR with the BTF flag.
>
> The Intel documentation says "P6 family" and
> mc68020+ No No
> (mc68000/010 No 2) (not for Linux)
Actually ucLinux has been persuaded to run on m68000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
Is there a simple way (via a kernel boot option or config setting or -
if really necessary - a patch or something like that) to set the
personality for the init process? I'm running an x86_64 kernel on a
system whose userland is almost entirely 32-bits (but needs an
occasional 64-bit process
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
> > On Monday, 26 of November 2007, Adrian Bunk wrote:
> > > On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian
The watchdog is "off" by default, meaning that you have to have
something actually start resetting the watchdog before it will start
running. That's why you are seeing this behavior.
There is a start_now option that will start the watchdog when it is
loaded, but then it will reset the system
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 12:28:17AM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian
On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > >...
> > > > I don't care whether that's done
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> >...
> > > I don't care whether that's done with Bugzilla, some email based bug
> > > tracker like the Debian bug
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least
On Mon, Nov 26, 2007 at 12:28:17AM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > > On Sun, Nov 25, 2007 at 10:28:06PM +0100,
On Mon, Nov 26, 2007 at 10:17:24AM +1100, Nick Piggin wrote:
> On Thursday 22 November 2007 11:32, David Chinner wrote:
> > Introduce radix_tree_gang_lookup_range()
> >
> > The inode clustering in XFS requires a gang lookup on the radix tree to
> > find all the inodes in the cluster. The gang
On Sun, 25 Nov 2007 20:36:04 +0100
Mathias Kretschmer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this is a x86_64 kernel with 4GB of RAM. incident happened when
> compiling cdrecord (or some variant of it :) in a 32-bit chroot jail
> during the 'configure' process.
>
> alpha / # uname -a
> Linux
On Sun, 25 Nov 2007 17:56:54 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Is there any technical reason why we need 4 different schedulers at
> all?
>
there is at least one technical reason to need more than one: certain
types of storage (both big EMC boxes as well as solid state disks)
don't
On Sat, Nov 17, 2007 at 07:55:58PM +0900, Akinobu Mita wrote:
> Use kasprintf instead of kmalloc()-strcpy()-strcat().
Applied to battery-2.6.git, thanks.
> Cc: Anton Vorontsov <[EMAIL PROTECTED]>
> Cc: David Woodhouse <[EMAIL PROTECTED]>
> Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
>
> ---
On Mon, Nov 05, 2007 at 06:07:45PM +0100, Adrian Bunk wrote:
> Every file should include the headers containing the prototypes for
> its global functions.
Applied to battery-2.6.git, thanks.
p.s.
Sorry for the delay, I've not been Cc'ed, so I've found out about
that patch by pure chance (through
On Thursday 22 November 2007 11:32, David Chinner wrote:
> Introduce radix_tree_gang_lookup_range()
>
> The inode clustering in XFS requires a gang lookup on the radix tree to
> find all the inodes in the cluster. The gang lookup has to set the
> maximum items to that of a fully populated cluster
On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
>...
> > I don't care whether that's done with Bugzilla, some email based bug
> > tracker like the Debian bug tracker, someone putting emails manually
> > into some bug tracker
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian
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
We need to run any DMA command with result taskfile requested in ADMA mode
when the port is in ADMA mode, otherwise it may try to use the legacy DMA engine
in ADMA mode which is not allowed. Enforce this with BUG_ON() since data
corruption could potentially result if this happened. Also, fail any
> Why should arch_has_single_step be a function-like macro? I can't thing
> of a case were this wouln't be a compile-time constant. And given that
> this is hopefully a transitionary ifdef because eventually all architectures
> would use the generic code I'd prefer ifdefs in the code that
On Sun, 25 Nov 2007 15:02:15 -0700, Josh Goldsmith wrote:
> I have a Linksys NSLU2 running 2.6.21 (I can replicate the problem on
> 2.6.23 but it isn't fully supported on SlugOS). It is a armv5teb device
> with 32MB of RAM, 400+ MB swap on its 160GB USB2 root disk. The machine is
> used as
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 10:51:14PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
[--snip--]
> > >
> > > How should a newbie find
On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > >..
> > > > First of all, Bugzilla is a quite
> Could we by any chance just force every architecture using generic code
> to implement PTRACE_SINGLESTEP and PTRACE_SYSEMU? This will lead to
> both far less messy code and a more consistant user interface.
I'd like to look into that later after most arch's have moved to using the
generic code
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
[--snip--]
> > Even worse:
> > Different people have
On Sun, Nov 25, 2007 at 01:55:07PM -0800, Roland McGrath wrote:
> 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
On Sun, Nov 25, 2007 at 02:01:09PM -0800, Roland McGrath wrote:
> 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
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> >..
> > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > source world [1], so many users
Wires up the new timerfd API to the x86 family.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- 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
Remove the broken status to CONFIG_TIMERFD.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
init/Kconfig |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6.mod/init/Kconfig
===
---
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 <[EMAIL PROTECTED]>
- Davide
---
include/linux/hrtimer.h |7 +++
1
This is the new timerfd API as it is implemented by the following patch:
int timerfd_create(int clockid, int flags);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct
This adds the PTRACE_SINGLEBLOCK request on x86, matching the ia64 feature.
The implementation comes from the generic ptrace code and relies on the
low-level machine support provided by arch_has_block_step() et al.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/ptrace32.c
This implements user-mode step-until-branch on x86 using the BTF bit
in MSR_IA32_DEBUGCTLMSR. It's just like single-step, only less so.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/step.c | 64 +--
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 <[EMAIL PROTECTED]>
---
arch/x86/kernel/process_32.c |6 +-
arch/x86/kernel/process_64.c |3 +++
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
This adds constant macros for a few of the bits in MSR_IA32_DEBUGCTLMSR.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
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
This adds the (internal) Kconfig macro CONFIG_X86_DEBUGCTLMSR,
to be defined when configuring to support only hardware that
definitely supports MSR_IA32_DEBUGCTLMSR with the BTF flag.
The Intel documentation says "P6 family" and later processors all have it.
I think the Kconfig dependencies are
This defines the new macro arch_has_block_step() in linux/ptrace.h, a
default for when asm/ptrace.h does not define it. This is the analog
of arch_has_single_step() for step-until-branch on machines that have
it. It declares the new user_enable_block_step function, which goes
with the existing
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 <[EMAIL PROTECTED]>
---
kernel/ptrace.c | 15 ++-
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
This cleans up the 32-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 match the
new 64-bit entry points for parity, but they don't need to be global.
Signed-off-by: Roland
qla2x00_remove_one() mustn't be __devexit since it's called from
qla2xxx_pci_error_detected().
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: vmlinux.o(.text+0x2a4462): Section mismatch: reference to
.exit.text:qla2x00_remove_one (between
This cleans up the ia32 compat ptrace code to use shared code from
native ptrace for the implementation guts of debug register access.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/ptrace32.c | 63 ++
1 files changed, 8
This patch removes a few remainders of the VID_HARDWARE_* removal.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/DocBook/videobook.tmpl |9 -
drivers/media/video/usbvision/usbvision.h |4
2 files changed, 13 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 <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_64.c | 60 --
1 files changed, 12
This defines the new standard arch_has_single_step macro. It makes the
existing set_single_step and clear_single_step entry points global, and
renames them to the new standard names user_enable_single_step and
user_disable_single_step, respectively.
Signed-off-by: Roland McGrath <[EMAIL
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 <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_32.c | 68 ++
1 files changed, 16
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 46 --
1 files changed, 0
This removes the handling for PTRACE_CONT et al from the 64-bit
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_64.c | 45 ---
1 files changed, 0
Hi,
I have a Linksys NSLU2 running 2.6.21 (I can replicate the problem on
2.6.23 but it isn't fully supported on SlugOS). It is a armv5teb device
with 32MB of RAM, 400+ MB swap on its 160GB USB2 root disk. The machine is
used as a fileserver and to build packages for other ARM devices. It
This removes the handling for PTRACE_CONT et al from the 32-bit
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_32.c | 57 ---
1 files changed, 0
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
This removes the single-step code from ptrace_32.c and uses the step.c code
shared with the 64-bit kernel. The two versions of the code were nearly
identical already, so the shared code has only a couple of simple #ifdef's.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
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
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 <[EMAIL PROTECTED]>
---
arch/x86/kernel/Makefile_64 |2 +
arch/x86/kernel/ptrace_64.c
1 - 100 of 334 matches
Mail list logo
